Illumio Segmentation (formerly Illumio Core) for Kubernetes

You can map existing Kubernetes labels to desired Illumio labels by adding a Kubernetes Custom Resource Definition (CRD) label map to your illumio-values.yaml file.

Kubelink Pod and CVEN Pods have priorityClassName specified by default. This can be disabled by setting priorityClasses.enabled to false. Default values of priorityClassName can be changed by setting kubelink and cven values.

Starting from C-VEN 22.5, NodePort ingress traffic is enforced by default. To allow NodePort traffic, additional policy rules are needed. If this behavior is undesired, it can be controlled by setting enforceNodePortTraffic: never.

Default values:

enforceNodePortTraffic: always

There is an option to specify Common Labels and Common Annotations in illumio-values.yaml:

commonLabels:  {  }  # Labels applied to all deployed objects
commonAnnotations:  {  }  # Annotations applied to all deployed objects

If you are using a private PKI to sign the PCE certificate, make sure you add to illumio-values.yaml the references to the root CA certificate that signed the PCE certificate, as shown below:

extraVolumeMounts:
  - name: root-ca
    mountPath: /etc/pki/tls/ilo_certs/
    readOnly:  false  
extraVolumes:
  - name: root-ca
    configMap:
      name: root-ca-config

If the infrastructure requires Kubelink to run on the control-plane node, add the below configuration to illumio-values.yaml (the selector label or name may differ). Keep in mind that this only applies to Kubelink deployment.

nodeSelector:
   node-role.kubernetes.io/control-plane:  ""

Kubelink deployment also supports two more settings:

ignore_cert:  true  
verbosity  :  0

Illumio Core for Kubernetes and Openshift provides an option to specify default image pull policy for each of its components.

kubelink:
  imagePullPolicy:  "Always"
cven:
  imagePullPolicy:  "Always"

Resources limits and requests are defined as chart values for Kubelink Deployment and CVEN DaemonSet. Values for both components can be changed in illumio-values.yaml, and each resources section is used as a whole for the corresponding container, effectively replacing the default resources definition.

See Resource Allocation Guidelines for deployment sizes.

kubelink:
  resources:
    limits:
      memory: 500Mi
    requests:
      memory: 200Mi
      cpu: 200m

cven:
  resources:
    limits:
      memory: 300Mi
  requests:
      memory: 100Mi
      cpu: 250m

storage:
  resources:
    limits:
      memory: 500Mi
    requests:
      memory: 200Mi
      cpu: 100m

Illumio Core for Kubernetes & OpenShift provides tools for collecting and visualization of runtime metrics since IC4K chart version 4.4. The chart contains InfluxDB as a dependency. To enable metrics use:

metrics:
  enabled: true 

Please refer to https://github.com/bitnami/charts/tree/main/bitnami/influxdb/ for a complete list of available parameters. To set a value in the illumio-values.yaml for InfluxDB subchart the influxdb section must be used.

Use the standard command, secrets will be generated.

$ helm install illumio -f illumio-values.yaml oci://quay.io/illumio/illumio --version  5.3.0 --namespace illumio-system --create  -namespace

To upgrade Illumio Core for Kubernetes & OpenShift deployed with the previous chart version or without metrics enabled, the user has to generate secrets for the version with enabled metrics.

export  ADMIN_USER_PASSWORD  =  `LC_ALL=LC tr -dc A-Za-z0-9 </dev/urandom | head -c 20 ; echo`  

export  ADMIN_USER_TOKEN  =  `LC_ALL=LC tr -dc A-Za-z0-9 </dev/urandom | head -c 20 ; echo`

helm upgrade illumio -f illumio-values.yaml oci://quay.io/illumio/illumio --version  5.3.0 --namespace illumio-system --set influxdb.auth.admin.password  =  $ADMIN_USER_PASSWORD  --set influxdb.auth.admin.token  =  $ADMIN_USER_TOKEN

To upgrade Illumio Core for Kubernetes & OpenShift deployed with enabled metrics, the user has to pass existing secrets.

export  ADMIN_USER_PASSWORD  =  $(kubectl get secret --namespace illumio-system illumio-influxdb -o jsonpath=  "{.data.admin-user-password}"  | base64 -d)  

export  ADMIN_USER_TOKEN  =  $(kubectl get secret --namespace illumio-system illumio-influxdb -o jsonpath=  "{.data.admin-user-token}"  | base64 -d)

helm upgrade illumio -f illumio-values.yaml oci://quay.io/illumio/illumio --version  5.3.0 --namespace illumio-system --set influxdb.auth.admin.password  =  $ADMIN_USER_PASSWORD  --set influxdb.auth.admin.token  =  $ADMIN_USER_TOKEN

The InfluxDB deployed with default options will create a persistent volume with a capacity 8Gi and use the default storage class from the cluster. The current Illumio metrics data size for 1 day is approximately 55Mi, and the retention policy for the Illumio bucket is set to 30 days. 4Gi capacity should be enough room for Illumio metrics. Example setting:

influxdb:
  persistence:
    size: 4Gi
    storageClass: kops-csi-1-21

Setting for disabling the metrics persistence:

influxdb:
  persistence:
    enabled:  false

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

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

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

To assist the Illumio Support team with more details for troubleshooting, Kubelink 5.2.0 provides a support bundle that collects up to 2 GB of logs, metrics, and other data inside its pod. Future versions will add the option to upload these support bundles to the PCE. Currently, you must copy this support bundle by running the script /support_bundle.sh inside the Kubelink pod. The script generates debug data, creates a gzipped tar archive using stdout as output, and encodes this data using Base64.

Use the following command to generate and transfer the Kubelink support bundle from its pod:

kubectl -n illumio-system exec deploy/illumio-kubelink -- /support_bundle.sh | base64 -d > kubelink_support.tgz

Kubelink reports Kubernetes workloads with its labels and annotations. Starting from Kubernetes Operator 5.4.0, only Illumio annotations are reported. To include other annotation keys, use userAllowedAnnotations list:

userAllowedAnnotations:
  - "deployment.kubernetes.io/revision"  

Starting from Kubernetes Operator 5.4.0, Kubelink does not create a Kubernetes Workload on PCE if the workload is in the host network. Pods of these workloads don't have separate network namespaces. Policy for these workloads must be part of the policy for Nodes. This was always the case, legacy non-CLAS mode works the same way.

This optimization can reduce the size of the policy sent from PCE. Instead of sending policy for each Kubernetes workload, PCE groups policies using Kubernetes Workload PCE labels. Kubernetes Workloads with a unique set of PCE labels will not benefit from this optimization.

policyLabelSetEnable: true