Default-deny Kubernetes egress needs a DNS exception
NetworkPolicy is a useful Kubernetes control for reducing lateral movement and unwanted outbound traffic. It is also easy to configure in a way that looks complete while failing in operation. A default-deny egress policy blocks DNS as well as application traffic. Workloads then fail to resolve service names, and teams sometimes react by permitting all egress. The policy needs an explicit design for discovery, application destinations, and health checks.
Kubernetes network policy rules are additive within the selected scope. A policy with an empty pod selector can establish a default-deny baseline, while separate policies allow selected traffic. The model does not provide a universal explicit deny rule, and policy support depends on the network plugin. Confirm that the cluster's implementation enforces the resources and that the selected pods are actually covered.
Permit only the DNS path
If the workload needs cluster DNS, add a small egress rule for UDP and TCP port 53 to the namespace and pods that run the DNS service. Select the namespace by label rather than assuming its name. Verify the cluster's DNS service and endpoint behavior in a test cluster. If the environment permits external DNS, decide separately whether that path is needed. A cluster-only resolver should not become an excuse to allow DNS to any internet address.
The DNS policy does not automatically grant permission to reach the addresses returned by DNS. A service name may resolve successfully and the subsequent connection may still be denied. Build the allow list from the application's actual destinations: service names, namespaces, and explicitly approved external CIDRs or egress gateways. For domain-based external access, use the network plugin's supported mechanism and test what happens when DNS changes or an IP is reused.
Include the rest of the pod lifecycle
Startup probes, readiness probes, metrics scrapers, log shippers, and package mirrors can depend on routes that the application itself does not use. If they run inside the same pod network, include or intentionally deny their paths. A policy that blocks a readiness probe may remove every pod from service even though the application is healthy.
Node-local health checks may originate outside the pod network and need separate consideration from pod-to-pod policy. The exact behavior depends on the CNI plugin. Test with the cluster's actual implementation rather than assuming that a policy example from another distribution applies.
Use a concrete test matrix
For one non-production namespace, record the following observations:
| Test | Expected result |
|---|---|
| Cluster service name resolution | allowed |
| Connection to approved service | allowed |
| Connection to an unlisted namespace | denied |
| Connection to a public IP | denied |
| Direct DNS to an unapproved server | denied |
| Readiness probe | succeeds |
| Metrics scrape | matches the declared path |
Then inspect the pod's network policy selection and the CNI's diagnostics. A policy resource can exist while the pod label no longer matches it, and a namespace label change can silently remove an allow rule. Treat label ownership as part of the control.
Monitor policy drift
Store the policy manifests in version control and run an admission or configuration check that detects workloads without the expected default-deny baseline. Alert on namespace label changes that affect DNS or shared services. Review broad CIDR rules regularly, especially rules that permit all private ranges or all internet IPv4.
When troubleshooting, do not disable the default policy and leave it disabled after the incident. Create a temporary exceptions branch or a narrowly scoped test policy, capture the evidence, and restore the baseline. If the application needs a new destination, add the smallest rule and document its owner and reason.
Default deny is a starting point. A working policy explains how the pod discovers services, which destinations it may reach, which probes and collectors are part of its lifecycle, and how the cluster proves the rules are enforced. DNS is usually the first exception, not the last.
Top comments (0)