Egress NetworkPolicy: Deny, Then Allow DNS
Lock a workload's outbound traffic down: default-deny egress, then re-open exactly what it needs — DNS on port 53 (both UDP and TCP) and one database dependency. Forgetting DNS is the classic egress mistake.
Your mission
Most people meet NetworkPolicy from the ingress side — who may talk to a Pod. The other half is egress: where a Pod may talk out. Egress control is what stops a compromised container from phoning home, reaching the cloud metadata endpoint, or scanning the rest of your estate. It is squarely on the CKS and CKA maps, and it has one famous trap.
The pattern is the same two steps as ingress. First a default-deny egress: a policy that selects every Pod and allows nothing out, so the namespace starts closed. Then you re-open exactly what a workload needs — and nothing more.
Here is the trap, and it catches almost everyone the first time. The moment you
default-deny egress, DNS stops working. Every getaddrinfo, every
curl example.com, every service lookup goes to the cluster DNS server first —
and that is egress. So the first thing your allow rule must restore is DNS itself:
UDP and TCP on port 53. Miss it and your Pods can't resolve a thing; the
symptoms look like everything is broken, not just the network.
In this lab you deny all egress, then re-open DNS plus one real dependency — a
database on 5432 — for a workload labelled app=web.
Useful aliases
In your terminal, k is aliased to kubectl and completion is configured. The
jumpbox also has k9s, jq and yq installed.