Kubernetes NetworkPolicy Rule Evaluation

Kubernetes NetworkPolicy Rule Evaluation describes the precise logical process a CNI plugin's policy enforcement agent follows when deciding whether to permit or drop a given packet, given the full set of NetworkPolicy objects currently selecting the pod involved in that connection.

Evaluation Trigger Point

Per-Connection Decision Making

Rule evaluation occurs at connection establishment, when a new flow is first observed at a pod's network interface, rather than being recomputed independently for every packet. Once a connection is permitted, subsequent packets belonging to that same tracked flow are generally allowed to pass without re-evaluating the full rule set, relying on connection tracking rather than repeated policy lookups.

Direction-Specific Evaluation

Because ingress and egress are isolated independently, a single connection between two pods is actually evaluated twice from a policy perspective: once against the egress rules of the source pod, and once against the ingress rules of the destination pod. Both evaluations must independently permit the traffic for the connection to succeed.

Rule Matching Logic

Allow-List Union Across Policies

For a given isolated pod and direction, every applicable NetworkPolicy's rules are collected into a single logical union. A connection is permitted if it matches any individual rule from any individual policy; there is no precedence, priority, or ordering between policies, since the standard NetworkPolicy API has no concept of rule priority.

Rule Component Matching

Each individual rule specifies a combination of allowed peers, expressed through pod selectors, namespace selectors, or IP block CIDR ranges, and optionally a set of allowed ports and protocols. A connection matches a rule only if both the peer and the port and protocol combination satisfy that rule's constraints; a rule with no port restriction is treated as allowing all ports to the matched peers.

Selector Combination Semantics

AND Within a Peer Entry, OR Across Entries

Within a single peer entry that specifies both a pod selector and a namespace selector, the two conditions are combined with logical AND, meaning the peer must satisfy both simultaneously. Across multiple peer entries within the same rule's peer list, the conditions are combined with logical OR, meaning matching any listed entry is sufficient.

IP Block Exceptions

When a rule uses an IP block, it can specify a CIDR range to allow along with an optional list of narrower CIDR ranges to explicitly except from that allowance, giving fine-grained control such as allowing an entire subnet except for a specific reserved address range within it.

Default Behavior in the Absence of a Match

Implicit Deny

If a pod is isolated for a direction and a given connection attempt matches no rule from any applicable policy, the connection is dropped. There is no explicit deny action to configure; the absence of a matching allow rule is itself the deny outcome, which is why understanding rule evaluation requires reasoning about what is not covered by any rule as much as what is.

Practical Evaluation Nuances

Named Ports

Rules can reference a named port defined on the target pod's container spec rather than a numeric port, in which case evaluation resolves the name to the actual port number the pod is currently using, which allows a policy to remain correct even if the underlying numeric port changes across pod versions, as long as the name stays consistent.

Protocol Scoping

Rules can be scoped to a specific protocol, most commonly TCP, UDP, or SCTP, and evaluation treats a rule with no listed protocol restriction as covering all supported protocols, meaning a rule intended only for TCP traffic must explicitly declare that scope to avoid inadvertently permitting UDP traffic on the same port range as well.