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
HighAddress
SecurityCompliance Standards
- CIS EKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
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):
- EKS (AWS CLI):
- On any machine with access to your cloud account, determine the CNI / network plugin and any network policy support flags:
-
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
networkPolicydisabled or a CNI that does not enforce NetworkPolicy, record this as a gap to be remediated.
- From step 1, determine if the chosen CNI supports Kubernetes
-
Review existing NetworkPolicy usage in the cluster
- On any machine with kubectl access:
- If no
NetworkPolicyobjects exist, or they are only present in a few namespaces, note that most workloads are not isolated and rely on default “allow all” behavior.
- On any machine with kubectl access:
-
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
networkPluginandnetworkPolicyset to values that support NetworkPolicy (e.g.,azure/calico), viaaz aks create/az aks updateor 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.
- Adjust cloud provider configuration or IaC (do not use kubectl) to enable a NetworkPolicy-capable engine, following provider guidance:
-
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.
-
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.
- From any machine with kubectl access:
Using kubectl
Using kubectl
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.
Automation
Automation
- Namespaces listed with
0NetworkPolicies: those namespaces likely allow all traffic and must be manually reviewed; add default-deny and explicit allow policies where appropriate. - No pods in
kube-systemmatching 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.

