Skip to main content

More Info:

Without a CNI plugin that supports NetworkPolicies, traffic between pods cannot be restricted. Use a plugin that enforces network policy.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. 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.
  2. Check whether NetworkPolicy objects are being used
    • Run on: any machine with kubectl access
    • Commands:
    • If no NetworkPolicy resources 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.
  3. 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):
  4. Apply a restrictive NetworkPolicy and observe behavior
    • Run on: any machine with kubectl access
    • Create a policy that only allows traffic to np-allowed from pods with label access=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.
  5. 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 NetworkPolicy and 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) NetworkPolicy objects.
  6. 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:
      • NetworkPolicy objects exist (if you use them), and
      • Connectivity tests change as expected when policies are applied, demonstrating that the CNI now enforces network policies.
What to look for
  • Pods/DaemonSets named like:
    • calico-node, calico-typha, tigera-operator → Calico (supports NetworkPolicy)
    • cilium, cilium-agent → Cilium (supports NetworkPolicy)
    • kube-flannel-ds or flannel-* → 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-proxy and no obvious CNI pods, or see a home‑grown/unknown CNI without clear documentation, treat this as “unknown/likely not supporting NetworkPolicy” until verified.

What to look for
  • 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 NetworkPolicy objects 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.

What to look for
  • 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.

What indicates a problem
  • 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-all NetworkPolicy (step 4e):
    • If the wget in step 4f still succeeds consistently and you are sure:
      • The deny-all policy is applied (check with kubectl 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).
    • If the wget fails or hangs until timeout, this suggests NetworkPolicies are being enforced.
Clean up the test objects when done:

How to interpret
  • 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.
How to interpret output (what indicates a problem):
  • 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-namespaces shows 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.