Illumio Segmentation for Containers

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.