CNI enforcement validity — the policy engine check

NetworkPolicy is an API object; enforcement belongs entirely to the CNI. On Flannel every policy in the cluster is inert and the API server accepts all of them without complaint, and even on Calico or Cilium a policy agent crash-looping on one node leaves that node unenforced while the rest of the cluster behaves. This lesson covers checking the policy engine rather than the policy, per CNI, and confirming enforcement with a connectivity test rather than an assumption.

The CNI’s policy engine

Different CNIs have different policy engines:

• Calico. Uses Felix (the policy engine) and the Typha (the API cache). The policy is enforced via iptables or eBPF.
• Cilium. Uses eBPF for policy enforcement. The policy is compiled into eBPF programs.
• Flannel. Does not enforce NetworkPolicy. Flannel is a pure L3 network.

flowchart LR
    A[NetworkPolicy] --> B[kube-apiserver]
    B --> C[CNI policy engine]
    C --> D[Node-level rules]
    D --> E[Enforced traffic]

The CNI’s policy engine is the cluster’s policy enforcement.

The diagnostic

The canonical diagnostic:

# Substitute your own values before running:
NS=production

# Calico
kubectl get pods -n calico-system -o wide
kubectl logs -n calico-system -l k8s-app=calico-node --tail=200
calicoctl get policy -n "$NS"
calicoctl get networkpolicy -n "$NS"

# Cilium
kubectl get pods -n kube-system -l k8s-app=cilium -o wide
kubectl logs -n kube-system -l k8s-app=cilium --tail=200
cilium policy get

# Flannel
kubectl get pods -n kube-system -l app=flannel -o wide

The diagnostic is CNI-specific.

The connectivity test

The connectivity test is the canonical verification:

# Substitute your own values before running:
SOURCE_POD=web-5f9c7d8b6c-2xk9p
TARGET_IP=192.0.2.25
TARGET_PORT=8080
TARGET_SERVICE=billing
NS=production

# From a source Pod to a target Pod
kubectl exec -it "$SOURCE_POD" -- curl -v "$TARGET_IP:$TARGET_PORT"

# From a source Pod to a target Service
kubectl exec -it "$SOURCE_POD" -- curl -v "$TARGET_SERVICE.$NS.svc.cluster.local"

# DNS resolution
kubectl exec -it "$SOURCE_POD" -- nslookup "$TARGET_SERVICE.$NS.svc.cluster.local"

The connectivity test is the canonical verification.

The policy audit

The policy audit verifies that the policy is being applied:

# Substitute your own values before running:
NS=production
POLICY=allow-billing-ingress

# Calico
calicoctl get policy -n "$NS" -o yaml

# Cilium
cilium policy get

# Generic
kubectl describe networkpolicy "$POLICY" -n "$NS"

The policy audit is the canonical verification.

Common failures

• CNI does not enforce policy. The CNI is Flannel (which does not enforce) or the policy engine is disabled.
• CNI policy engine failing. The CNI’s policy engine is in CrashLoopBackOff.
• Policy not applied. The policy is in the cluster but the CNI is not applying it.

flowchart TD
    A[NetworkPolicy not enforced] --> B{CNI enforces policy?}
    B -->|No| C[Switch CNI or enable policy]
    B -->|Yes| D{CNI policy engine healthy?}
    D---|No| E[Fix the CNI policy engine]
    D---|Yes| F{Policy applied?}
    F -->|No| G[Restart the policy engine]
    F -->|Yes| H[Unknown]

The remediation

The remediation depends on the cause:

# Option 1: Restart the CNI policy engine
# Calico
kubectl rollout restart daemonset/calico-node -n calico-system

# Cilium
kubectl rollout restart daemonset/cilium -n kube-system

# Option 2: Enable the policy engine
# (CNI-specific configuration)

# Option 3: Switch to a CNI that enforces policy
# (e.g., from Flannel to Calico or Cilium)

The remediation is the CNI’s recovery.

Production discipline

The CNI’s policy engine is the cluster’s network hypothesis. The discipline is to walk the canonical flow extended with the CNI’s policy engine, identify the failure mode, apply the remediation. The network is the cluster’s connectivity; the remediation is the CNI’s recovery.

• Verify the CNI enforces policy. The CNI is the enforcement layer.
• Check the CNI’s policy engine health. The engine is the cluster’s policy enforcement.
• Audit the policy. The policy is the cluster’s network posture.

Quiz