NetworkPolicies that declare no ingress or egress rules

An empty policy is a deny-all policy

A NetworkPolicy lists allowed connections, and everything it selects but does not allow is blocked. According to the network policies page, a pod becomes isolated for ingress once any policy selecting it includes Ingress in policyTypes, and isolated for egress the same way. From then on only connections allowed by some policy’s rules get through, apart from inbound traffic from the pod’s own node. If policyTypes is omitted, Ingress is always set, and Egress only when the policy has egress rules.

A policy with no rules at all therefore cuts selected pods off in whichever direction it names. Sometimes that is exactly the goal: the documentation’s own default-deny example is a policy with an empty podSelector and policyTypes: [Ingress]. Other times it is a stub committed before its rules were written, or a selector broader than intended, and pods lose traffic without an obvious cause.

Listing policies with no rules

kubectl get networkpolicies -A -o json | jq -r '
  .items[]
  | select(((.spec.ingress // []) | length) == 0 and ((.spec.egress // []) | length) == 0)
  | "\(.metadata.namespace)/\(.metadata.name) podSelector=\(.spec.podSelector | tojson) policyTypes=\(.spec.policyTypes // [] | join(","))"'

kubectl describe networkpolicy <name> -n <namespace> shows which pods it selects and in which directions it isolates them.

Rule counts, both zero

ZopNight reads how many ingress rules and how many egress rules each NetworkPolicy declares, and fires only when both counts are available and add up to zero. A policy with a single rule in either direction is out of scope. The check does not evaluate the selector, the namespace’s other policies, or whether the traffic is actually needed.

When an empty policy is harmless

Policies only take effect when the cluster’s network plugin enforces NetworkPolicy; creating one without such a controller has no effect, so an empty policy on a non-enforcing cluster changes nothing today but will start blocking the day enforcement is switched on. Deliberate default-deny policies are the main expected match, as the false-positive line notes.

A low-severity security review item

No saving is attached. The concern runs both ways: an accidental empty policy causes silent outages, while an intentional one deserves a comment in the manifest so reviewers can tell.

Resolving the finding

1. Read the policy’s podSelector and policyTypes to see what it isolates.
2. If it is a deliberate default-deny, check that allow policies exist for the traffic the pods need, and annotate the policy with its purpose.
3. If it is an unfinished stub, add the intended ingress or egress rules.
4. If it was created by mistake, remove it with kubectl delete networkpolicy <name> -n <namespace>.