Illumio Core 25.2.10 Install, Configure, Upgrade (On-Prem)

C-VEN on server hosting containers and Enforced policy state limitation

If a C-VEN on a server hosting containers is paired directly into the Enforced policy state, other nodes may lose connectivity with the master node until policy is synchronized across all the nodes.

Pods running on host network stack limitation

Pods which run on the host network stack (inherit the host IP address) are not reported to the PCE. Any rules written for the host will also be inherited by any hostNetworked Pods on the host.

Kubernetes stateless rules limitation

The use of stateless rules is not recommended because Kubernetes uses NAT tables, which depend on traffic being tracked and stateful.

Kubernetes service ports and pod firewall in Non-CLAS limitation

If a Kubernetes service has both port 1234/TCP and port 2345/UDP configured, a rule configured with the Pod as source and the virtual service as Provider will open up both ports 1234/TCP and 2345/TCP, and 1234/UDP and 2345/UDP on the Pod's firewall (outbound rule).

In case of a Kubernetes service configured with a port and targetPort statement in the manifest file as shown in the example below:

apiVersion: v1
kind: Service
metadata:
  name: web-frontend-svc
  namespace: app1
  labels:
    app: app1
    tier: web-frontend
  annotations:
    com.illumio.role: Web
spec:
  type: ClusterIP
  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP
  - port: 8081
    targetPort: 81
    protocol: UDP
  selector:
    app: app1
    tier: web-frontend

This configuration is supported with Illumio Core. In this case, only the port number associated to the port statement will show this issue, the port number associated to the targetPort statement will not show this issue and will use the protocol specified in the Service yaml file.

NodePort services in OpenShift with OVN limitation

NodePort services in OpenShift with OVN are not enforceable at the service or node level by Illumio; policy is enforced only on the destination workloads.

In OpenShift clusters using OVN CNI, NodePort traffic routes through a virtualized network infrastructure comprising OVS routers, switches, and load balancers. Unlike traditional CNIs like Calico, where traffic passes through the host’s IP stack and is subject to DNAT and filtering, OVN handles NodePort traffic at the virtual network layer. This means traffic reaches the target pod without traversing the host workload’s IP stack, complicating visibility and enforcement.

Because NodePort traffic in OVN bypasses the host IP stack, Illumio cannot natively observe or enforce policies on it. The only observable point is at the pod level, where traffic appears to originate from the Gateway router IP (e.g., 100.64.x.x), obscuring the original source. This lack of visibility makes it difficult to apply precise security rules, as policies must allow traffic from all Gateway router IPs, potentially exposing the pod to unintended sources.

NodePort namespace traffic enforcement and container hosts limitation

NodePort namespace traffic does not get enforced unless container hosts are enforced, even with full enforcement enabled.

The container hosts control what accesses the namespace. If you want to use NodePort and want to enforce NodePort traffic, you must enforce container hosts traffic, first.

Traffic Visibility with Overlapping Cluster IP Ranges

Description: In Kubernetes environments where multiple clusters use overlapping IP address ranges, identical IPs may appear across different clusters. Traffic is evaluated at the point of observation using contextual signals available at collection time. This approach aligns effectively with typical intra-cluster communication.

Current Behavior: To deliver the most accurate visibility possible, traffic is associated with workloads using the cluster context where the IP is observed. This contextual mapping leverages available telemetry and correlation signals. It works reliably for the majority of intra-cluster scenarios and ensures consistent policy and visualization behavior.

Outcome: When traffic flows between clusters sharing overlapping CIDRs, attribution is based on the local cluster context at the observation point. As a result, inter-cluster traffic visibility appears within the observed cluster context. Environments with unique, non-overlapping subnets provide fully deterministic traffic attribution across clusters.

CLAS Object Limits and Object Limit Formulas

The following CLAS-related default object limits prevent overloading a PCE with too many policy objects:

The following Object Limit Formulas determine when to throw the Object limit hard limit reached error. See PCE Default Object Limits for more details.

total_service_bindings = (Total Number of NodePorts + LoadBalancers) * ( total number of nodes + 1)

total_kubernetes_workloads = Total number of specific Services (ClusterIP + NodePort + LoadBalancer) + Deployments + DaemonSets + Jobs + Pods without owner

Cilium and kube-proxy-replacement mode

When Cilium runs with kube-proxy-replacement=true, enforcement for NodePort and LoadBalancer services are not supported.