Kubernetes NetworkPolicy Isolation

Kubernetes NetworkPolicy Isolation refers to the specific mechanism by which the presence of a NetworkPolicy selecting a pod changes that pod from an unrestricted network participant into one whose traffic is governed by explicit rule evaluation, and the precise semantics that determine what "isolated" means for ingress versus egress traffic.

The Isolation Trigger

Selector Match Activates Isolation

A pod becomes isolated for a given traffic direction, ingress or egress, the moment at least one NetworkPolicy in its namespace selects it and specifies a policy type covering that direction. Before any such policy exists, the pod remains fully open in that direction; isolation is not a property configured directly on a pod but an emergent effect of policy selection.

Independent Ingress and Egress Isolation

Ingress and egress isolation are triggered independently. A pod can be selected by a policy that only declares ingress rules, in which case its egress traffic remains completely unrestricted even though its incoming traffic is now filtered, and vice versa. Understanding this independence is essential to avoid the common mistake of assuming one policy type implicitly restricts the other.

Rule Evaluation Semantics

Additive Rule Combination

When multiple NetworkPolicy objects select the same pod for the same direction, their rules are combined additively: traffic is permitted if it matches at least one rule from any applicable policy. There is no explicit deny rule type in the standard NetworkPolicy API; isolation is achieved purely by omission, meaning traffic not matched by any allow rule is implicitly dropped.

Empty Rule List as Full Isolation

A NetworkPolicy that selects a pod and declares a policy type but includes no rule entries at all for that direction results in complete isolation for that direction, permitting no traffic whatsoever. This is the mechanism underlying default-deny policy patterns.

Ingress Isolation Details

Source Matching Granularity

Ingress rules can restrict allowed traffic sources by pod selector, namespace selector, or IP block, and these can be combined to express constraints such as "only pods with a specific label, within a specific namespace." Isolation applies at the granularity of the destination pod and port combination specified in each rule.

Port-Scoped Isolation

Ingress rules can further restrict allowed traffic to specific ports and protocols, meaning a pod can be isolated such that only traffic to its application port is permitted while all other ports on that same pod remain closed, even from otherwise permitted sources.

Egress Isolation Details

Destination Matching Granularity

Egress rules mirror ingress rules but describe permitted destinations rather than sources, again combinable across pod selectors, namespace selectors, and IP blocks, allowing precise scoping of which external or internal destinations an isolated pod's outbound traffic may reach.

DNS as a Practical Exception Case

Because nearly every workload depends on DNS resolution, egress isolation in practice almost always requires an explicit allow rule permitting traffic to the cluster's DNS service, since DNS traffic is not automatically exempted from egress isolation despite being a near-universal dependency.

Namespace-Level Isolation Boundaries

Cross-Namespace Traffic Requires Explicit Rules

Because NetworkPolicy objects are namespace-scoped and pod isolation only considers policies within the pod's own namespace, allowing traffic from pods in a different namespace requires an explicit namespace selector in the ingress or egress rule; isolation does not implicitly distinguish same-namespace from cross-namespace traffic unless a rule is written to do so.

Interaction With Pod Lifecycle

Isolation State Follows Label Changes

Because isolation is determined by selector matching rather than a static assignment, a pod's isolation status can change dynamically if its labels are modified such that it starts or stops matching a NetworkPolicy's selector, meaning isolation state must be understood as a continuously evaluated condition rather than a fixed attribute set at pod creation time.