Kubernetes Network Policy Viewer

They are allow-only, with no deny

There is no deny rule. A policy can only permit traffic, so you never reason about precedence or ordering the way you would with a firewall or with IAM. What you reason about instead is the union of everything permitted, which sounds simpler and is harder, because no single document contains the answer.

Selecting a pod flips it from allow-all to deny-all

This is the property that surprises people. By default a pod accepts everything. The moment any policy selects it for a direction, that pod is denied everything in that direction except what policies explicitly allow. So adding one policy to permit one connection silently forbids every other connection that pod was making.

before any policy    pod accepts everything

add a policy allowing ingress from the gateway
                     pod now accepts ONLY the gateway
                     the metrics scraper is now blocked,
                     and nothing in the policy mentions it

And they are additive across every policy

Several policies can select the same pod, and the effect is the union of all their allowances. This is why reading one policy tells you nothing definitive: another document elsewhere in the namespace may permit the traffic you think is blocked. It also means you cannot revoke access by editing one policy: you have to find every policy that grants it.

Default-deny egress breaks DNS first

kube-dns lives in another namespace and answers on UDP 53. A default-deny egress policy blocks it like anything else, so every name lookup fails. The application then reports connection errors for hosts it can no longer resolve, which reads as the network being entirely broken rather than one port being blocked. Any default-deny egress policy needs a companion rule allowing 53 to kube-system.

egress:
  - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
    ports:
      - protocol: UDP
        port: 53
      - protocol: TCP
        port: 53

And none of it works without a CNI that enforces it

NetworkPolicy is an API, not an implementation. The API server stores your policy whatever the cluster is running, and if the CNI plugin does not implement enforcement, nothing happens, no error, no warning, no traffic blocked. Calico, Cilium, Weave and Antrea enforce it; the AWS VPC CNI does not on its own, and flannel does not at all. Confirm enforcement before trusting any of this.