The mechanism
NetworkPolicy describes allowed traffic for selected Pods. Enforcement requires a network implementation that supports the relevant policy behavior. An accepted NetworkPolicy object on an unsupported data plane can create a false sense of isolation.
Policies are additive within a direction. Once a Pod is isolated for ingress or egress, allowed connections are the union of applicable rules for that direction. A connection between two Pods must satisfy source egress and destination ingress when those directions are isolated.
Namespace labels, Pod selectors and ports all matter. YAML nesting can express a different relationship than intended, such as combining namespace and Pod conditions in one peer versus listing alternatives. Review the semantic set of allowed peers, not just the document’s visual shape.
Worked example
This offline default-deny example selects all Pods in the lab namespace for both directions. It is not applied: applying it could interrupt DNS and application traffic. It teaches isolation selection before any allow rules are added.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
namespace: handbook-lab
spec:
podSelector: {}
policyTypes: [Ingress, Egress]Practice: predict, inspect, explain
Offline exercise. Draw frontend-to-API and API-to-DNS flows. Add proposed allow rules on paper and evaluate both directions of each connection. Then add a second broad allow policy and explain why it can widen access despite the default-deny object remaining present.
Expected observation: policy ordering does not create an ordinary firewall-style last-match deny. The effective allowed set is additive. Real acceptance testing needs positive and negative traffic checks in an approved disposable cluster with verified enforcement support; this handbook performs no policy mutation.
Troubleshooting and trade-offs
If denied traffic still works, first confirm plugin enforcement and selection. If DNS stops working, inspect the actual DNS path and policy needs rather than allowing all egress. If a selector seems ineffective, verify namespace and Pod labels. Do not infer application-layer authentication or hostname filtering from basic NetworkPolicy semantics.
Interview practice
Can a deny policy override a broad allow policy?
Ordinary NetworkPolicy rules are additive. A broad applicable allow can permit traffic; a separate default-deny object does not subtract that allowance.
What must permit a Pod-to-Pod connection?
The source’s egress policy and destination’s ingress policy, when each direction is isolated, plus a functioning network and listener.
Completion check
Evaluate three flows and state the external prerequisite that makes the policy enforceable.
Sources and version notes
Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.
- Official documentation: Network policies
- Official documentation: Dns pod service
- Official documentation: Overview
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.