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
The CLAS architecture requires mandatory infrastructure rules to be in place for the cluster to work properly. Do not upgrade to the CLAS mode, or move the cluster to Full Enforcement until the following infrastructure rules are configured:
Node -> Service CIDR IP list (9000/TCP)
Any (0.0.0.0/0 and ::0) -> Node (2379-2380/TCP, 2379-2380/UDP)
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.
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, ClusterIP ports are now represented as Kubernetes Workloads when viewing traffic, rather than as Virtual Services, as previously.
If you want to migrate from a legacy (non-CLAS) to a CLAS environment, ensure that all rules applicable to ClusterIP Services are changed to "Use Workloads" at a specific point during the CLAS upgrade process. For complete details, see Upgrade to CLAS Architecture.
Because Services are now Kubernetes Workloads, the "All Workloads" flag in a rule will include all Services. Do not use "All Workloads" as a Destination in a rule. Use a more specific label instead that targets the Service.
All rules that include a label of at least one ClusterIP service will have specified ports internally replaced. However - this is not reflected in PCE UI, where the rule still displays ports.
NodePort and LoadBalancer services remain shown as Virtual Services in the PCE. However, the ClusterIP part of a NodePort or LoadBalancer service now exists as a Kubernetes Workload and is linked with 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.