Why does a default-deny egress NetworkPolicy break every Kubernetes service call?

Apply this one policy, and every service call in shop starts failing. The empty podSelector selects every Pod in the namespace, and policyTypes lists Egress with no rules, so nothing may leave. That's true even though we separately allowed the frontend to reach backend. Something else is being blocked first.

Before the policy, a call to backend is really two connections. First, the frontend asks CoreDNS on port 53 to resolve the name, and gets back 10.96.0.12. Only then does it open HTTP to the backend on 8080 and receive a 200 OK. Notice that the DNS lookup is itself egress traffic, leaving the frontend Pod toward kube-system.

Now the policy is on. Frontend sends its lookup to CoreDNS on port 53, but no egress rule matches that traffic, so it's dropped silently. No rejection comes back. The retry fails the same way, and the lookup times out. Backend never gets a single packet, even though we allowed port 8080. To the application, it just looks like a connectivity failure.

Here's the rule. Once any policy selects a Pod for egress, everything not explicitly allowed in that direction is denied. DNS included.

The allow-backend rule is narrow. It lets the frontend reach backend Pods on port 8080, and nothing else. CoreDNS on port 53 is a different destination, in another namespace, so that rule never matches it. Policies only add up as a union of allowed destinations. DNS needs its own rule.

This policy lets every Pod in shop reach CoreDNS on port 53. Notice namespaceSelector and podSelector sit in one list item, so they combine as AND: kube-system and k8s-app kube-dns. We include TCP because large responses fall back to it. Check those labels on your own cluster.

With both rules in place, the original flow works again. Frontend asks CoreDNS to resolve backend on port 53, and gets 10.96.0.12 back. Then it opens the HTTP connection to Backend on 8080 and receives a 200 OK. Two connections, each with its own allow rule. And default-deny still blocks everything else, so you haven't given up the security.

Test from inside the frontend Pod, and test in two steps. nslookup isolates DNS. wget by name exercises both lookup and connection, and a bad address error points straight at DNS. If the image has no tools, kubectl debug attaches a busybox container. These outputs are illustrative.

One caveat. The API server accepts a NetworkPolicy no matter what, so applying it proves nothing. On an enforcing CNI, the DNS query gets stopped. On a non-enforcing one, the same YAML is simply ignored and traffic flows. Enforcement belongs to the plugin, so check what yours supports.

Every Service call starts with a DNS call, so allow both. Default-deny egress blocks port 53 too, so open UDP and TCP to kube-dns, and make sure your CNI enforces policy. Next time, run nslookup before blaming the backend rule.