EKS clusters where the VPC CNI is not enforcing Kubernetes network policies

NetworkPolicy objects do nothing on their own

Kubernetes is open by default. The Network Policies page states that pods are non-isolated for ingress and egress unless a policy selects them, and that creating a NetworkPolicy without a controller that implements it has no effect. On EKS the Amazon VPC CNI can act as that controller, but only when its network policy support is turned on. A team can write careful policies and still have a flat network where a compromised pod can reach the database.

Checking the add-on configuration

aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni \
  --query 'addon.[addonVersion,configurationValues]' --output text

Look for "enableNetworkPolicy": "true" in the configuration values. Also check whether a third-party engine is installed:

kubectl get daemonsets -n kube-system
kubectl get pods -A | grep -Ei 'calico|cilium'

When ZopNight reports it

ZopNight reads the network policy setting from the vpc-cni managed add-on’s configuration. The finding fires when that setting is false, and also when the cluster has no vpc-cni managed add-on at all, for example one running a self-managed CNI. A tag named network_policy on the cluster is ignored.

Clusters left out, and the Calico or Cilium case

If the add-on configuration could not be read, ZopNight does not assume the worst and stays silent.

AWS’s guidance for clusters that already use a third-party policy engine is that only one solution should manage the same policies. Clusters running Calico or Cilium therefore keep enableNetworkPolicy off on the VPC CNI and would always look non-compliant here. ZopNight cannot detect those engines and has no setting today to exclude such a cluster, so dismiss the finding with that reason recorded.

Exposure, not cost

The finding reports $0. The risk is lateral movement: with no enforcement, one compromised workload can talk to every other workload and service in the cluster.

Turning on enforcement

1. Enable policy support on the add-on, as shown in the EKS network policy guide: aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'.
2. Or run Calico or Cilium as the enforcer, leave the VPC CNI setting off, and dismiss the finding in ZopNight with that reason.
3. Add a default-deny NetworkPolicy to each namespace, then allow the paths each service needs.
4. Re-run discovery so ZopNight sees the new setting.