Skip to main content

More Info:

Deploy a network policy engine such as Calico to segment and isolate pod traffic, enforcing least-privilege network communication within the cluster.

Risk Level

High

Address

Security

Compliance Standards

  • CIS EKS

Triage and Remediation

Remediation

Manual Steps

  1. Identify how networking is provisioned for the cluster
    • On any machine with access to your cloud account, determine the CNI / network plugin and any network policy support flags:
      • EKS (AWS CLI):
        Check your provisioning/IaC (CloudFormation/Terraform) for any addons like aws-k8s-cni, Calico, Cilium, etc.
      • AKS (Azure CLI):
      • GKE (gcloud):
  2. Verify whether a network policy–capable CNI is enabled
    • From step 1, determine if the chosen CNI supports Kubernetes NetworkPolicy (e.g., Calico, Cilium, Antrea, Azure network policy, GKE network policy).
    • If your cloud provider shows networkPolicy disabled or a CNI that does not enforce NetworkPolicy, record this as a gap to be remediated.
  3. Review existing NetworkPolicy usage in the cluster
    • On any machine with kubectl access:
    • If no NetworkPolicy objects exist, or they are only present in a few namespaces, note that most workloads are not isolated and rely on default “allow all” behavior.
  4. Decide on and enable an appropriate network policy engine at the provider level
    • Adjust cloud provider configuration or IaC (do not use kubectl) to enable a NetworkPolicy-capable engine, following provider guidance:
      • EKS: configure a CNI like Calico/Cilium via your chosen add-on mechanism (e.g., Helm/operator via IaC, or managed add-on if available).
      • AKS: recreate or update the cluster with networkPlugin and networkPolicy set to values that support NetworkPolicy (e.g., azure/calico), via az aks create / az aks update or IaC.
      • GKE: create/update clusters with --enable-network-policy (or equivalent in IaC).
    • Be aware this may require cluster recreation in some providers; plan for migration and maintenance windows.
  5. Define and apply a baseline isolation model for all namespaces
    • Design a policy model (e.g., default deny within each namespace, explicitly allowing required app, DNS, and ingress/egress flows).
    • Implement these policies via your existing IaC or GitOps tooling (YAML manifests committed to source control) so they are applied consistently; ensure each application namespace has at least a baseline NetworkPolicy.
  6. Re-verify that network policy enforcement is active and effective
    • From any machine with kubectl access:
    • From your cloud provider / IaC: re-run the commands from step 1 to confirm that a network-policy-capable engine is enabled.
    • Optionally, run connectivity tests between test pods across namespaces to confirm that traffic is blocked/allowed according to your policies.
kubectl cannot be used to enable or configure the cluster’s network policy engine because this setting is controlled at the cloud provider / managed control plane level (console, provider CLI, or IaC). Refer to the Manual Steps section for guidance on selecting and configuring a network policy engine such as Calico through your provider’s configuration surface.
Problem indicators in the output
  • Namespaces listed with 0 NetworkPolicies: those namespaces likely allow all traffic and must be manually reviewed; add default-deny and explicit allow policies where appropriate.
  • No pods in kube-system matching common network-policy engines and no clear CNI indicators: verify in the cloud provider console/CLI that a NetworkPolicy-capable CNI (such as Calico) is deployed and enabled.