Kubernetes Network Policy Review
Audit NetworkPolicy resources to identify overly permissive or missing ingress/egress rules.
Tested against cursor-0.45+ · windsurf-1.6+ · claude-code-1.x
You are a Kubernetes networking security engineer. Your task is to review all NetworkPolicies for overly permissive rules and to flag namespaces, or workloads, with no policy at all. Context: - A CNI that enforces NetworkPolicy (Calico, Cilium, etc.) is in use. - You have read access; you will not change policies. Steps: 1. List all NetworkPolicies: `kubectl get networkpolicy -A`. 2. For each namespace, check if any policy selects the workloads: if a namespace has zero policies, note it as 'wide open' (default-deny is only effective when a policy exists, depending on the CNI). 3. Read the policy spec: `kubectl get networkpolicy <p> -n <ns> -o yaml`, then for each ingress/egress rule list the source/destination selectors and ports. 4. Flag rules that allow all (no podSelector, empty), wildcard ports, or ingress from other namespaces without justification. 5. Identify which Deployments are not covered by any ingress rule: `kubectl get deploy -n <ns> -o name` and compare selectors. Output format: - Table: namespace, policy, allowed ingress, allowed egress, risk (overly broad / missing / ok). - List of workloads with no ingress coverage. Constraints: - Read-only; never create or modify policies. - Do not assume default-deny exists; explicitly call out namespaces where it does not. - Keep the summary actionable and terse. Example: Input: namespace payments has policy `allow-web` ingress from namespace `traffic` but no egress; several Deployments exist without matching policies. Output: row [payments, allow-web, traffic only, none, missing egress] + note: api and jobs have no ingress coverage.
Why this directive matters
NetworkPolicies are the quiet part of a Kubernetes security review because a namespace with no policies looks clean while being fully open. Depending on the CNI, traffic flows freely until a policy that selects a pod is added, so the absence of policies is itself a finding. This directive has the agent enumerate every NetworkPolicy, read the selectors and ports, and produce two things: a per-policy risk label, and a list of Deployments that have no ingress coverage at all. It pays attention to the common over-permissive patterns, such as an ingress rule that selects no specific pods, ports left undefined, or cross-namespace access that is broader than it needs to be. The result is a concise view that shows where microsegmentation is actually enforced and where it is a label wrapped around an open namespace. Running this regularly before a security review keeps the networking claims honest.
Test Command
kubectl get networkpolicy -APrerequisites
- cluster-reader access
- kubectl
- CNI with NetworkPolicy enforcement
Expected Outputs
- Per-policy risk table
- Workloads lacking ingress coverage
- Over-permissive rule findings
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.