More Info:
Without a CNI plugin that supports NetworkPolicies, traffic between pods cannot be restricted. Use a plugin that enforces network policy.Risk Level
HighAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify the current CNI plugin and its capabilities
- Run on: any machine with kubectl access
- Commands:
- From these outputs, determine which CNI is installed and consult its official documentation to verify whether it implements Kubernetes
NetworkPolicy.
-
Check whether NetworkPolicy objects are being used
- Run on: any machine with kubectl access
- Commands:
- If no
NetworkPolicyresources exist, document that policies are not in use and decide whether you want to start using them. If they exist, proceed to validate that they are enforced.
-
Functionally test whether NetworkPolicies are enforced
- Run on: any machine with kubectl access
- Create a test namespace and pods:
- Verify baseline connectivity (should be allowed before any policy):
-
Apply a restrictive NetworkPolicy and observe behavior
- Run on: any machine with kubectl access
- Create a policy that only allows traffic to
np-allowedfrom pods with labelaccess=granted: - Label the client incorrectly and test (should be blocked if NetworkPolicy is enforced):
- Then label it correctly and test again (should succeed if enforced):
- If connectivity is unaffected by the policy, your current CNI is not enforcing
NetworkPolicy.
-
Decide and plan remediation if NetworkPolicies are not enforced
- If the CNI does not support
NetworkPolicy, or the tests above show no enforcement:- Document the current CNI and its limitations.
- Select a CNI that supports Kubernetes
NetworkPolicyand is compatible with your environment (for example, Calico, Cilium, Weave Net, Kube-router; verify support in their documentation). - Plan a migration window, including:
- Reading the chosen CNI’s install/migration guide for your Kubernetes distribution.
- Capturing current CNI manifests in
kube-system: - Assessing impact on existing workloads and any current (even if non‑enforced)
NetworkPolicyobjects.
- If the CNI does not support
-
Clean up test resources and re-verify after any CNI change
- Run on: any machine with kubectl access
- Clean up test namespace:
- After migrating to a CNI that supports
NetworkPolicy, repeat steps 2–4 to confirm that:NetworkPolicyobjects exist (if you use them), and- Connectivity tests change as expected when policies are applied, demonstrating that the CNI now enforces network policies.
Using kubectl
Using kubectl
- Pods/DaemonSets named like:
calico-node,calico-typha,tigera-operator→ Calico (supports NetworkPolicy)cilium,cilium-agent→ Cilium (supports NetworkPolicy)kube-flannel-dsorflannel-*→ Flannel (basic Flannel does NOT enforce NetworkPolicy)weave-net→ Weave Net (supports NetworkPolicy)kube-router→ kube-router (supports NetworkPolicy)antrea-agent→ Antrea (supports NetworkPolicy)- Cloud CNIs (
amazon-vpc-cni-*,azure-cni-*,gke-*,ovn-kubernetes, etc.) → check their docs for NetworkPolicy support.
- If you see only
kube-proxyand no obvious CNI pods, or see a home‑grown/unknown CNI without clear documentation, treat this as “unknown/likely not supporting NetworkPolicy” until verified.
- If no NetworkPolicy objects exist but:
- Security requirements expect pod‑to‑pod isolation, and
- The CNI supports NetworkPolicy
→ This is a policy design gap, not a CNI capability problem.
- If many
NetworkPolicyobjects exist, but the CNI is known not to support them (e.g., plain Flannel):- This indicates a serious problem: policies are being defined but are not enforced at all.
- Confirm these are Kubernetes
kind: NetworkPolicy(not a CRD from some other system). - If the CNI is known not to support NetworkPolicy, any such spec is effectively documentation only, not enforced.
- If the initial connection (step 4d) fails unexpectedly → there may already be other policies or other controls in place; interpret with caution.
- Key check: after applying the
deny-allNetworkPolicy (step 4e):- If the wget in step 4f still succeeds consistently and you are sure:
- The
deny-allpolicy is applied (check withkubectl get networkpolicy -n np-test deny-all -o yaml), and - There are no other NetworkPolicies allowing this traffic
→ This strongly suggests the CNI does not enforce Kubernetes NetworkPolicy (or is misconfigured).
- The
- If the wget fails or hangs until timeout, this suggests NetworkPolicies are being enforced.
- If the wget in step 4f still succeeds consistently and you are sure:
- If the CNI identified above is one that does not support NetworkPolicy (e.g., plain Flannel) and there is a requirement to restrict pod‑to‑pod traffic using Kubernetes
NetworkPolicy, this finding is not remediated and you must:- Migrate to a CNI that supports NetworkPolicies, or
- Implement alternative network controls outside Kubernetes.
Automation
Automation
- No CNI DaemonSet or plugin is detected, or only a plugin known not to support NetworkPolicies is present (for example, basic Flannel without policy extensions).
- NetworkPolicy objects exist (
kubectl get networkpolicies --all-namespacesshows entries), but the detected CNI plugin’s documentation does not explicitly state support for Kubernetes NetworkPolicy. - Operators cannot identify any CNI plugin at all or cannot confirm from documentation that it enforces NetworkPolicies.

