# NetworkPolicy Has No Rules

> Flags NetworkPolicies with no ingress or egress rules, which deny all traffic to or from the pods they select.

Source: https://zop.dev/integrations/kubernetes/recommendations/networkpolicy-has-no-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](https://kubernetes.io/docs/concepts/services-networking/network-policies/),
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

```bash
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>`.

**Warning**
Deleting a default-deny policy opens the selected pods to all traffic in that direction unless another policy isolates them.