Control objective
NetworkPolicy selects Pods and controls allowed ingress and egress connections as implemented by a supporting network plugin. It limits reachability. It does not authenticate a human, authorize a Kubernetes object, or inspect every application action.
Selection and enforcement
Policies select Pods by namespace and labels and describe allowed peers, ports, and directions. A Pod becomes isolated for a direction when a policy selects it for that direction. Effective behavior combines applicable policies and plugin support.
Identity relationship
Pod labels and namespaces are orchestration metadata, not cryptographic workload identity. Combine reachability limits with ServiceAccount, workload identity, TLS service identity, gateway policy, Kubernetes authorization, and application permissions.
Failure and residual risk
No supporting plugin means policies have no effect. Selectors can miss Pods. Host networking, nodes, control-plane traffic, DNS, metadata services, and plugin-specific behavior can create gaps. An allowed connection can carry unauthorized actions.
Pomerium boundary
Pomerium can protect named routes to Kubernetes services. NetworkPolicy can restrict which Pods reach Pomerium or upstream services. Operators own plugin support, selectors, default isolation, DNS and control-plane flows, and application authorization.
Evaluation checklist
- Does the cluster network plugin enforce NetworkPolicy?
- Which Pods are isolated for ingress and egress?
- Which namespaces, labels, IP blocks, ports, DNS, and control paths are allowed?
- What identity and authorization controls apply after connection succeeds?
- Do host, node, metadata, and direct-service paths bypass the policy?
