Skip to main content

Illumio Segmentation for Containers

Rules and Traffic Considerations with CLAS

In Container Local Actor Store (CLAS) deployments, be sure to take into account the following special traffic and policy rules considerations that differ from legacy non-CLAS environments that are described in other sections of this chapter.

Mandatory rules for namespace enforcement

The following rules must be set on the PCE to ensure the illumio-system namespace is fully enforced (or the custom namespace that is used instead of the default of illumio-system):

  • illumio-kubelink-* → Any; 2379 TCP (pod to arbitrary IP address)

    This rule is necessary for connecting a illumio-kubelink-* pod to a illumio-storage-* pod. All destination IP addresses are allowed, because the IP address of illumio-storage-* pod changes after it is restarted.

  • K8s API → illumio-kubelink; 9001

    This rule is necessary when waitForPolicy is enabled in Helm Chart. See https://quay.io/repository/illumio/illumio for details on waitForPolicy.

  • All pods → illumio-kubelink; 9002

    This rule is necessary when waitForPolicy is enabled in Helm Chart. See https://quay.io/repository/illumio/illumio for details on waitForPolicy.

  • Any → illumio-storage-*; 2379 TCP (arbitrary IP address to pod)

    The same explanation as for the above rule, but the ingress on illumio-storage-* pod is allowed here.

  • Node → illumio-kubelink-*; 8080 TCP, 8081 TCP, 9000 TCP (node to pod)

    This rule is needed for successfully connecting C-VEN pods to illumio-kubelink-* pods.

  • illumio-kubelink-* → PCE FQDN; 8443 TCP (pod to FQDN IP list)

    The illumio-kubelink-* pod must be able to connect to PCE. Use the FQDN IP list, which contains the URL of the PCE, to do this. The outgoing connections using the DNS port are always allowed by an implicit rule installed on C-VEN pods Therefore you need not list any rules for DNS.

  • illumio-kubelink-* → Kuberenetes API; 443 TCP (for example, pod to IP list of all possible ClusterIPs of Kubernetes Services)

    This rule ensures the illumio-kubelink-* pod can connect to the Kubernetes API, which is required.

ClusterIP Rules

In the CLAS environment, the PCE represents ClusterIP ports as Kubernetes Workloads when you view traffic. The PCE previously represented them as Virtual Services.

If you want to migrate from a legacy (non-CLAS) environment to a CLAS environment, change all rules that apply to ClusterIP Services to Use Workloads at the appropriate point during the CLAS upgrade process. See Upgrade to CLAS Architecture.

Because the CLAS environment represents Services as Kubernetes Workloads, the All Workloads option in a rule includes all Services. Do not use All Workloads as a destination. Use a specific label that targets the Service. Specific labels also help prevent the rule from allowing traffic to unintended backend workloads or ports.

For rules that include a label associated with a ClusterIP Service, Kubelink internally maps the rule to the backend workload ports. Kubelink performs this mapping outside the PCE, so the PCE does not display it. The rule continues to display the configured ports, but Kubelink enforces the rule against the actual backend workload port. As a result, the rule can allow traffic to a backend workload even when the configured port does not match the ClusterIP Service port.

This behavior applies when the rule specifies the ClusterIP Service as the destination. For example, suppose a ClusterIP Service exposes a backend workload on port 10000. A rule that allows traffic to port 8889 can still allow traffic to port 10000 when the destination label matches the Service. Kubelink implicitly includes the ClusterIP Service ports and applies the rule to the backend workload port.

When you use All Workloads as the source, or as both the source and destination, the rule can allow traffic more broadly than intended. Use specific labels for both sides of the rule whenever possible.

The PCE can display different results for this traffic:

  • The Reported view shows the traffic as Allowed.

  • The Draft view shows the same traffic as Blocked – No Rule.

The Draft view shows Blocked – No Rule because Kubelink performs the internal port mapping outside the PCE. The PCE cannot display the mapping in the Draft view.

NodePort and LoadBalancer Services remain displayed as Virtual Services in the PCE. However, Kubelink represents the ClusterIP part of a NodePort or LoadBalancer Service as a Kubernetes Workload and links it to the Virtual Service in the PCE.

General Traffic View Changes

The following is a summary of general changes to traffic views in a CLAS-enabled cluster:

  • Kubernetes workloads (for example, Deployments) are now displayed in the UI as Kubernetes Workloads, rather than as Container Workloads. Container Workloads (Pods) are still shown in non-CLAS clusters.

  • ClusterIP Virtual Services are now shown as Kubernetes Workloads.

  • NodePort and LoadBalancer services remain Virtual Services in the PCE.

  • Traffic from other Virtual Services to Kubernetes Workloads is not shown.

  • Traffic between Kubernetes Workloads within a cluster is shown.

CLAS Traffic Limitations

Consider the following differences and limitations in these scenarios when viewing traffic and writing rules in a CLAS environment:

  • Pod to Host

    When a Pod is on a different Node than the target Node, additional traffic is shown occurring from the Pod's Node to the target Node. This traffic cannot be selectively hidden with filters because it behaves similarly to traffic from host to host that should not be hidden. (This behavior occurs only when Calico is used as the CNI.)

  • Pod to ClusterIP

    Additional direct traffic occurs from a source Pod to a source Target, regardless of whether it is destined for the same node or a different target node.

  • Managed Workload to NodePort

    Additional traffic is shown for a Client's direct access to a target Pod, and from a Used Node to a target Pod.

    Additionally, crucial traffic destined for a NodePort is directed to the Node with the NodePort's port.

  • Unmanaged Workload (or Internet) to NodePort

    Additional traffic is shown for a Client's direct access to a target Pod, and from a Used Node to a target Pod.

    Additionally, in the traffic from the Client to the NodePort virtual service, we are missing crucial traffic associated with the NodePort's port.

  • Draft Traffic to Virtual Services

    Traffic in Draft mode, where the destination is a Virtual Service, is marked as Potentially Blocked.