More Info:
Namespaces without NetworkPolicies allow unrestricted pod-to-pod traffic. Define at least one NetworkPolicy in each namespace to control and restrict traffic.Risk Level
HighAddress
SecurityCompliance Standards
- CIS EKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List namespaces that currently have no NetworkPolicies (run on any machine with kubectl access):
-
For each namespace without a NetworkPolicy, review what should be allowed:
- Ingress: which pods/services (by label, namespace, IPs) may talk to pods in this namespace?
- Egress: which external destinations (namespaces, services, CIDRs, ports) are required? Use these answers to decide labels, ports, and CIDR ranges for your policies.
-
(Optional but recommended) Label workloads in a target namespace so policies can select them. For example, in namespace
example-namespace(run on any machine with kubectl access): -
Create a default deny-all ingress and egress NetworkPolicy for each selected namespace, adjusting
namespaceand labels as appropriate (run on any machine with kubectl access). Example forexample-namespace: -
Add specific allow NetworkPolicies where needed so applications continue to function. For example, allow ingress HTTP traffic from same namespace to pods labeled
role=appinexample-namespace(run on any machine with kubectl access):Repeat with additional policies for other required ports, sources, or egress as identified in step 2. -
Verify that every namespace has at least one NetworkPolicy (run on any machine with kubectl access):
Using kubectl
Using kubectl
Automation
Automation

