Skip to main content

Illumio Segmentation for Containers

Using Wait For Policy

With Wait For Policy, CLAS-enabled Kubelink can be configured to delay the start of an application container in a pod until a policy is applied to that container. This synchronizes the benefit of automatic container creation with the protection of policy convergence into the new container.

Wait For Policy replaces the existing local policy convergence controller, also known as a readiness gate. A readiness gate required manually adding the readinessGate condition into the spec of the Kubernetes Workload. Instead, Wait For Policy uses an automatically injected init container, which requires no change to the user application.

How Wait For Policy Works

When Wait For Policy is enabled, Kubelink creates a new MutatingWebhookConfiguration. This webhook injects an Illumio init container into every new pod.

A new pod life cycle consists of the following sequence of actions.

  1. Kubernetes creates a pod.

  2. The pod creation request is intercepted by a mutating webhook.

  3. Kubernetes requests MutatingAdmissionWebhook Controller running in Kubelink.

  4. Controller returns with a new pod patched with an Illumio init container.

  5. Init container starts in the pod, and periodically checks the policy status of the pod using the Kubelink status server.

  6. At the same time, Kubelink is preparing a policy for the new pod, and is sending the policy to the pod's C-VEN.

  7. The C-VEN applies policy to the pod and sends an acknowledgment to Kubelink.

  8. Kubelink reports that the policy is now applied to the init container.

  9. The Init container exits and allows the original container to start.

  10. If a policy is not applied within the configured time (see Enabling Wait For Policy section for Helm Chart waitForPolicy.timeout parameter), the init container exits anyway, and allows the original container to start.

The Illumio init container must be accessible from all namespaces that use Wait for Policy. An easy way to ensure this accessibility is to make the init available from a public repository. However, a private repository can be used if you manage the secret deployment properly, such as by deploying init from the same repository as all other containers or using a secret management tool.

Enabling Wait For Policy

Wait For Policy is disabled by default.

To enable it, change the waitForPolicy: enabled value to true in the Helm Chart illumio-values.yaml file. The following is the default Helm Chart configuration for Wait For Policy:

## Wait for Policy - Illumio delays the start of Pods until policy is applied
waitForPolicy:
  ## @param waitForPolicy.enabled Enable Wait for Policy feature
  enabled: false
  ## @param waitForPolicy.ignoredNamespaces List of namespaces where Illumio 
  ## doesn't delay start of Pods. kube-system and  
  ## illumio-system name are ignored by Kubelink for this feature by default, 
  ## even if not specified in this list.
  ignoredNamespaces:
    - kube-system
    - illumio-system
  ## @param waitForPolicy.timeout How long will pods wait for policy, in seconds
  timeout: 130

Pods starting in namespaces listed in ignoredNamespaces start immediately, without an Illumio init container injected into them. The namespaces kube-system and illumio-system are always ignored by the MutatingAdmissionWebhook Controller running in Kubelink, even if those are not specified in the configuration. The default value of ignoredNamespaces contains kube-system and illumio-system for reference, and can be extended with custom namespaces.

The timeout value is the total allowed run time of the init container. After this time elapses, the init container exits even if the policy is not applied, and allows the original container to start.