Egress from a payment Pod must be denied except DNS and one external payment gateway IP. What NetworkPolicy pattern fits?

Egress NetworkPolicies can isolate outbound traffic for selected Pods and then open only required destinations. For a municipal payment Pod that must reach DNS and one external payment gateway IP—and nothing else—include Egress in policyTypes, allow egress to cluster DNS (CoreDNS/kube-dns on UDP/TCP 53), and allow an ipBlock limited to the payment gateway CIDR. That locked outbound mail slot with two intentional holes is the least-privilege egress pattern for city payment flows and prevents accidental calls to arbitrary internet hosts.

Using only an ingress NetworkPolicy leaves egress unrestricted by that object; it is incorrect to claim egress to the internet is never restricted by NetworkPolicies. Setting the Service type to ExternalName maps a DNS name to an external hostname—it does not automatically block all other egress paths from the Pod. Setting privileged: true does not bypass egress NetworkPolicy enforcement and is an inappropriate privilege escalation for payment workloads.

Exam caveat: forgetting the DNS allow is the classic outage after egress default-deny—Pods lose Service name resolution even when the gateway IP itself would be reachable. Always list Egress in policyTypes when egress rules matter, and keep ipBlock ranges as narrow as the payment vendor permits. Operational check: from the payment Pod, confirm name resolution works, confirm HTTPS/TCP to the gateway IP succeeds, and confirm a random external IP fails. Capture those three probes in the city’s change ticket so reviewers see both the allow list and the denials. kubectl describe networkpolicy should show policyTypes including Egress plus the DNS and ipBlock rules.