More Info:
Amazon EKS provides two ways to implement network policy. You choose a network policy option when you create an EKS cluster. The policy option cant be changed after the cluster is created: Calico Network Policies, an open-source network and network security solution founded by Tigera. Both implementations use Linux IPTables to enforce the specified policies. Policies are translated into sets of allowed and disallowed IP pairs. These pairs are then programmed as IPTable filter rules.Risk Level
LowAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS EKS
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify the cluster’s network plugin / policy engine
- From any machine with AWS CLI access:
- In the AWS console, open EKS → your cluster → Networking → confirm which CNI add-ons are installed (e.g., Amazon VPC CNI only, or Calico, etc.).
- If your cluster does not have a network policy–capable CNI (e.g., Calico), note that this cluster cannot enforce Kubernetes NetworkPolicies and you must either deploy a supported policy engine or plan a new cluster with it enabled.
- From any machine with AWS CLI access:
-
Check whether any Kubernetes NetworkPolicy objects exist
- From any machine with kubectl access:
- If the list is empty but you require intra-cluster segmentation, you currently have no enforced NetworkPolicies even if a policy engine is present.
- From any machine with kubectl access:
-
Review current network segmentation requirements with stakeholders
- Document workloads that:
- Must only talk to specific namespaces/services (e.g., frontend → backend only).
- Must be internet-isolated or restricted to specific egress.
- Decide on a default stance per namespace: default-deny (preferred) vs allow-all.
- This is a business/architecture decision, not something a command can answer.
- Document workloads that:
-
If the cluster lacks a policy engine, plan provider-level remediation
- For existing EKS clusters created without a network policy–capable CNI, the network policy option cannot be switched in-place. Typical options are:
- Create a new EKS cluster with Calico or another supported network policy engine configured via your IaC (e.g., eksctl, Terraform, AWS CDK) or by following the provider’s “Install Calico on EKS” guidance.
- Migrate workloads to the new cluster, then decommission the old cluster.
- Capture this as a change plan (with maintenance windows, testing, and rollback).
- For existing EKS clusters created without a network policy–capable CNI, the network policy option cannot be switched in-place. Typical options are:
-
If a policy engine is present, implement / refine NetworkPolicies
- From any machine with kubectl access, inspect existing policies for a sample namespace:
- Create or adjust NetworkPolicies (using your chosen GitOps/manifest process) to:
- Enforce namespace isolation (e.g., default-deny + explicit allows).
- Restrict ingress/egress based on the requirements from step 3.
- Apply and test connectivity carefully in a non‑production environment first.
- From any machine with kubectl access, inspect existing policies for a sample namespace:
-
Verify effective enforcement after changes
- From any machine with kubectl access, confirm policies are present and accepted:
- Use provider/CNI-specific tools or logs (for Calico, e.g., calicoctl if in use, or pod connectivity tests using
kubectl execandcurl/nc) to validate that blocked connections actually fail and allowed connections succeed, documenting the results as evidence for this control.
- From any machine with kubectl access, confirm policies are present and accepted:
Using kubectl
Using kubectl
kubectl cannot be used to enable or change the EKS cluster’s network policy provider; this is configured only at the cloud provider control-plane level (EKS console/CLI/IaC) when the cluster is created. Refer to the Manual Steps section for guidance on reviewing the current configuration and planning any required changes.
Automation
Automation

