Skip to main content

More Info:

Use network policies to isolate traffic in your cluster network.

Risk Level

Low

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. 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-namespaces output; these currently have no NetworkPolicy.
  2. Decide which namespaces must be isolated and what traffic is allowed
    For each namespace without NetworkPolicies (especially those running workloads, not system namespaces like kube-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.
  3. 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.
  4. 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:
    Adjust selectors, ports, and namespaces to match your design.
  5. 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.
  6. 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:
Review the list and decide which namespaces are in scope (typically all non-terminated namespaces, including kube-system unless you have a documented exception policy).
If some namespaces from the first command do not appear in the 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.
Any line showing 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.
Use this to assess whether existing policies are meaningful (e.g., not just a single allow-all policy) and consistent with your isolation objectives. An “allow all ingress and egress” policy does not provide isolation and should be treated as a potential issue during review.
Run this script on any machine with kubectl access and jq installed.Problematic output indicates:
  • In the summary section: any line containing -> NO NetworkPolicy DEFINED shows 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.

Additional Reading: