NetworkPolicy defines which pods can communicate with which other pods and external endpoints in a Kubernetes cluster. The cluster only enforces it when a compatible network plugin supports policy enforcement. Security teams use it to limit lateral movement, so they should check default-deny rules, namespace scope, and whether unused workloads are left open.
What NetworkPolicy actually controls in a Kubernetes cluster
NetworkPolicy is the Kubernetes object that defines which pods may talk to which other pods and which external endpoints. The policy is declarative, but enforcement is not automatic in every cluster. It only works when the CNI or network plugin implements policy enforcement, so the real control surface is the combination of Kubernetes policy objects and the networking layer that enforces them.
That distinction matters because a NetworkPolicy that exists in YAML but is not enforced by the plugin is only an intent statement. In practice, teams use it to reduce unnecessary east-west traffic, separate namespaces, and narrow which workloads can reach sensitive services.
How policy selection and traffic matching work
NetworkPolicy is scoped to pods through label selectors and namespace selectors. A policy does not attach to a node or to the cluster as a whole, it applies to the set of pods that match its selectors. Once a pod is selected, the rules define allowed ingress, egress, or both, depending on how the policy is written.
Traffic decisions are based on source and destination identity at the Kubernetes networking layer, plus protocol and port when those are specified. That means the policy model is about allowed flows, not about user logins or application-layer authorization. If a workload is not selected by any restrictive policy, it may remain open by default depending on the cluster’s policy posture.
Because policies are label-driven, accuracy depends on label hygiene and namespace design. A label change can widen or narrow access immediately, which makes consistent naming and ownership part of the control, not just an administrative detail.
Why default-deny, namespace scope, and plugin support are the hard parts
The practical security value of NetworkPolicy comes from default-deny thinking. Without a default-deny baseline, teams often end up with partial rules that protect some paths but leave other workloads or namespaces exposed. The same is true for namespace scope: a policy that is too narrow may protect one application tier while leaving adjacent workloads reachable.
Enforcement also depends on the network plugin supporting policy controls. If the cluster networking stack does not enforce NetworkPolicy, the resource may create a false sense of segmentation. For that reason, practitioners should treat policy support as an infrastructure capability that must be verified, not assumed.
When you compare Kubernetes Security Guide material on cluster hardening with NetworkPolicy itself, the useful lesson is that segmentation only works as part of the broader Kubernetes security model, not as a standalone fix.
Risk and Threat Considerations
NetworkPolicy reduces lateral movement inside a cluster, but only when it is enforced consistently and written with a clear deny-by-default posture. The main exposure is overreach in pod connectivity, especially when teams assume namespace boundaries or application intent will be enough on their own.
Failure mechanism: A permissive or unenforced policy allows a compromised pod to reach other pods, services, or external destinations that should have been isolated. Weak labels, incomplete namespace scoping, and a plugin that does not enforce policy all create the same end result, unintended network reachability.
Impact: An attacker who gets code execution in one workload can pivot more easily, discover internal services, and move toward secrets, control planes, or higher-value applications. That turns a single pod compromise into a broader cluster incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | NetworkPolicy governs which pod flows are allowed between workloads. |
| Recommendation — Enforce allowed Kubernetes traffic flows with explicit information-flow rules. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Cluster network policy depends on secure segmentation and controlled network paths. |
| Recommendation — Harden and segment Kubernetes networking to reduce unintended east-west access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions are Managed | Policy enforcement limits which workloads may communicate across trust boundaries. |
| Recommendation — Manage workload communication permissions to restrict unnecessary access paths. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | NetworkPolicy supports least-privilege segmentation inside the cluster. |
| Recommendation — Apply least-privilege segmentation to constrain workload-to-workload trust. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | The subject is network segmentation and control of internal traffic paths. |
| Recommendation — Implement and verify network security controls for cluster traffic segregation. | ||
Practitioner Guidance
What to verify: Confirm that the cluster CNI actually enforces ingress and egress policy before trusting any manifest. Then verify which pods are selected by each rule, because the effective scope is usually broader or narrower than the author intended.
Decision rule: If a workload has not been explicitly reviewed, treat it as exposed until you can prove a default-deny stance and show the exact allowed flows. If a namespace hosts mixed-trust workloads, separate them with policy and label discipline before relying on application-level assumptions.
What practitioners underestimate: The hardest part is not writing a policy, it is proving that the policy matches the real traffic graph over time. New services, sidecars, batch jobs, and external dependencies often create gaps that the original manifest never anticipated.
Practitioner takeaway: NetworkPolicy is only as strong as its enforcement layer and its selectors, so the control should be validated as an operating condition, not treated as a completed configuration change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org