More Info:
Use network policies to isolate traffic in your cluster network.Risk Level
LowAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all namespaces and identify those without any NetworkPolicy
- Run on: any machine with kubectl access
- Compare the namespace list to the NetworkPolicy list. Note any namespaces that do not appear in the
kubectl get networkpolicy --all-namespacesoutput; these currently have no NetworkPolicy.
-
Decide which namespaces must be isolated and what traffic is allowed
For each namespace without NetworkPolicies (especially those running workloads, not system namespaces likekube-system), determine:- Which pods/services must be reachable (from where, and on which ports).
- Whether the default stance should be “deny all” then allow only specific flows, or “allow most” with a few specific denials.
Document these decisions per namespace.
-
Create a baseline “default deny” NetworkPolicy where appropriate
- For each application namespace that should not be wide open, start with a default deny-all ingress policy (and optionally egress):
- Replace
<namespace>with the target namespace name. - Be aware this immediately blocks traffic not explicitly allowed by other NetworkPolicies in that namespace.
-
Add allow-list NetworkPolicies for required traffic
Based on step 2, add policies that explicitly allow necessary flows. Example patterns (adapt and apply per namespace):- Allow intra-namespace traffic:
- Allow traffic from a specific namespace:
- Allow intra-namespace traffic:
-
Review impact and refine policies
- Monitor application behavior and logs for connection failures after changes.
- Iterate on NetworkPolicies by further restricting selectors or adding necessary exceptions using updated manifests and:
- Keep policies in version control and update them via your normal deployment process.
-
Verify that all intended namespaces now have NetworkPolicies
- Run on: any machine with kubectl access
- Confirm every namespace that you intended to protect has at least one NetworkPolicy listed.
- For a detailed check on a specific namespace:
Using kubectl
Using kubectl
NAMESPACE column here, they currently have no NetworkPolicy defined. Those namespaces are candidates for review and likely indicate a problem, unless you have explicitly decided they should be fully open.namespace: 0 indicates that namespace has no NetworkPolicy and therefore all pod-to-pod traffic in and out of that namespace is unrestricted by NetworkPolicy. Each such namespace needs human review to decide whether to introduce NetworkPolicies and, if so, with what rules.Automation
Automation
kubectl access and jq installed.Problematic output indicates:- In the summary section: any line containing
-> NO NetworkPolicy DEFINEDshows a namespace with zero NetworkPolicy objects and should be reviewed. - In the second section: any listed
<namespace>/<pod-name>is a pod not selected by any NetworkPolicy in its namespace and is potentially receiving/sending unrestricted traffic; these pods and their namespaces should be reviewed and appropriate NetworkPolicies designed and applied.

