Kubernetes / Intermediate: rollout, policy, and evidence / Lesson 11

NetworkPolicy and traffic boundaries

Interpret Pod isolation, additive allow rules, and policy-enforcement assumptions without confusing connectivity with application identity.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the model, assumptions, and boundaries of networkpolicy and traffic boundaries.
Interpret both examples and distinguish declared intent from established evidence.
Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.

Require an enforcing implementation

NetworkPolicy objects describe allowed traffic for selected Pods, but enforcement depends on a supporting network implementation. Creating a policy without that support does not establish isolation. Review the installed plugin, version, capabilities, and documented limits. Namespace organization alone does not deny traffic. Standard NetworkPolicy concerns connection-level behavior and is not a replacement for application authorization, TLS identity, or a complete tenant boundary. State which sources, destinations, protocols, and ports should communicate before writing YAML. A successful connection must still be checked against the intended application peer and operation.

Understand selection and isolation

Policies select Pods in their own namespace. Ingress and egress isolation are independent and arise when applicable policies select the Pod for that direction. The first policy selects every Pod in training and isolates both directions with no allow rules. It would block ordinary application and DNS traffic under a conforming supported implementation, so it is illustrative and never applied. A workload can require both its egress permission and the destination’s ingress permission. Adding a policy is a change to reachability and deserves review of health checks, telemetry, DNS, and dependencies, not only business traffic.

yaml Illustrative bidirectional default isolation

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: {name: isolate-training, namespace: training}
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

No allow rules are present. This can block DNS and essential traffic when enforced and must not be applied as a generic production recommendation.

Read union and conjunction correctly

Applicable allow rules are additive; a default-deny policy is not a higher-priority deny that overrides another allow. Within one peer entry, namespaceSelector and podSelector together constrain the same peer by both conditions. Separate entries express alternatives. The second example allows a backend port from web Pods in namespaces with a specific label. It does not allow the backend’s outbound DNS or grant a caller permission to use the API. Selector labels need trustworthy ownership because changing a namespace or Pod label can change who matches the policy.

yaml Illustrative combined peer selection

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: {name: web-to-api, namespace: training}
spec:
  podSelector: {matchLabels: {app: booking-api}}
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector: {matchLabels: {team: frontend}}
          podSelector: {matchLabels: {app: web}}
      ports:
        - {protocol: TCP, port: 8080}

Both selectors belong to one peer entry, so both must match. Other additive policies can widen access; this manifest does not define egress or application authorization.

Account for protocols and topology

DNS may need both UDP and TCP access according to the resolver and response. Provider load balancers, node-originated traffic, host networking, and address translation introduce implementation-specific details. ipBlock interpretation relative to rewritten addresses must be verified against the chosen network stack rather than generalized. Standard policy is not a portable HTTP path filter. Existing connections and policy-change timing also have documented limitations. Keep intended application rules separate from infrastructure exceptions, and avoid a blanket allow-all repair merely because a restrictive change affected an overlooked dependency.

Verify positive and negative paths safely

A policy review should include expected allowed paths, denied paths, DNS, startup, health, and telemetry. Use an authorized isolated test environment and synthetic workloads for enforcement checks. Static parsing cannot prove that a plugin enforced the rule or that a real route is reachable. Preserve the previous reviewed policy and a scoped recovery decision, while considering additive policies already present. This course sends no packet, runs no policy test, contacts no resolver, and applies no object. Its examples explain interpretation so a later authorized verification can test the correct boundary with bounded scope.

Common errors and fixes

A policy exists but traffic is unrestricted

Why it happens: The network implementation does not enforce the expected policy.
How to fix it: Verify supported implementation and actual enforcement in isolation.
Prevent it next time: Record plugin capability as a security assumption.

Separate selector entries broaden access

Why it happens: OR alternatives were mistaken for AND constraints.
How to fix it: Put required joint selectors in one peer entry.
Prevent it next time: Test excluded peers as well as allowed peers.

DNS fails after isolation

Why it happens: Required resolver egress was omitted.
How to fix it: Review the exact bounded resolver policy and protocols.
Prevent it next time: Include infrastructure dependencies in policy tests.

Check your understanding

1. Does a default-deny policy override an allow rule from another applicable policy?

Show worked solution

No. Standard applicable allow rules combine additively. Review the union of effective rules and both traffic directions. Removing one allow may still leave another path, and a deny-looking object is not an ordered firewall rule with universal precedence.

2. Why must a policy test include a caller without the namespace label?