A Kubernetes NetworkPolicy can restrict egress from selected Pods when the cluster networking plugin enforces it. Once egress isolation applies, a workload may lose DNS resolution unless a matching rule permits traffic to the cluster's DNS service. Standard NetworkPolicy matches Pods, namespaces, and IP ranges; it is not a portable policy language for filtering arbitrary domain names.
Make this comfortable
Egress policy and DNS: restrict destinations without breaking name resolution
Operational decision
A claims processor must reach a queue inside the cluster and one approved external document endpoint. Inventory actual destinations and ports before applying deny rules. The fragment is a default-deny egress policy for the claims processor; it intentionally has no allow rules and will break both queue access and DNS until narrow companion policies are added. Apply it first in a disposable namespace, then permit DNS to the labeled DNS Pods on the observed port and the exact internal service path. Handle the external destination with an egress gateway or policy capability supported by the chosen network stack, not an invented DNS selector. Test name lookup, the approved call, and a denied destination from inside the selected Pod. Capture the policy engine's decision signal when available.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: {name: claims-deny-egress, namespace: claims}
spec:
podSelector:
matchLabels: {app: claims-processor}
policyTypes: [Egress]Cost and verification
Egress restrictions add policy maintenance as services and DNS paths change. Excessively broad CIDR allows can create a hidden escape path; overly narrow rules can stop critical callbacks or telemetry. DNS answers may change independently of IP-based policy. Verify enforcement with the installed network plugin and run a negative connectivity test; a policy object accepted by the API server does not prove traffic is blocked. Watch blocked requests during rollout, including startup-time dependency checks.
Common Mistakes
- Do not assume a default-deny egress policy leaves DNS working.
- Do not claim standard NetworkPolicy filters by hostname.
- Do not call a policy effective without testing a blocked path.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Kubernetes NetworkPolicy: permit only required flows
- Kubernetes Service discovery: selectors, endpoints, and DNS
- DNS, TLS, and reverse-proxy failure boundaries
- Observability: join metrics, logs, and traces
Practice and check
Advanced follow-up
devops
operations