Cybersecurity glossary
What is a Kubernetes Network Policy?
Learn what Kubernetes NetworkPolicy is, how CNI plugins enforce pod ingress and egress allowlists, and how to avoid default-allow clusters that let every workload talk.
Definition
A Kubernetes NetworkPolicy is a namespace-scoped API object that selects pods and specifies which ingress and egress connections those pods may accept or initiate, enforced by a compatible CNI plugin rather than by the Kubernetes control plane itself.
Why Kubernetes NetworkPolicy matters
A fresh cluster network is usually a flat Ethernet for pods. Namespace names, RBAC, and even “private” Services do not stop a compromised frontend from scanning a database on another namespace.
Kubernetes NetworkPolicy is the native allowlist for that east-west traffic. Until a compatible CNI enforces it, every pod can talk to every pod—and often to the node and cloud metadata path as well.
How a connection is evaluated
A pod is selected
podSelector (and sometimes namespaceSelector) decide which workloads the policy applies to.
Direction is chosen
Ingress rules cover incoming connections; egress rules cover what the pod may initiate.
Peers and ports are matched
Peers can be pod labels, namespaces, or IP blocks. Ports can be numeric or named.
The CNI programs dataplane rules
iptables, eBPF, or similar filters packets on the node. The API server does not sit in the path.
Unmatched traffic is dropped
Once any policy of that direction selects the pod, everything not explicitly allowed is denied.
What NetworkPolicy can and cannot do
Allowlist east-west traffic
Permit only checkout pods to reach the payments API on its port—not the whole namespace.
Constrain egress
Stop a job from calling the public internet or the instance metadata service.
Not identity by itself
Labels can be spoofed if RBAC lets attackers create pods. Pair with admission and (optionally) mTLS.
Not a host firewall
Node ports, hostNetwork pods, and VPC routes live outside NetworkPolicy unless the CNI extends there.
Policy shapes teams actually use
| Shape | Intent | Pitfall |
|---|---|---|
| Default deny ingress + egress | Make every namespace fail closed, then open paths | Forgetting DNS, probes, or telemetry collectors |
| Ingress from a frontend namespace | Allow only labeled clients to a Service | Selectors that match too many pods after a label change |
| Egress to CIDR allowlists | Reach a specific API or database IP range | Cloud IPs change; prefer FQDN policies if the CNI supports them |
| Deny metadata / IMDS | Block 169.254.169.254 from application pods | Node-level IMDS hop still exists for the kubelet and hostNetwork |
NetworkPolicy checklist
- Confirm the CNI actually implements NetworkPolicy; test with a deny that you can see drop traffic.
- Start every production namespace with default-deny ingress and egress, then add explicit allows.
- Always allow DNS to the cluster DNS pods when egress is default-deny.
- Select pods by stable, admission-enforced labels—not by labels anyone in the namespace can set.
- Cover both directions: a database should not accept the world, and a frontend should not egress the world.
- Block application pods from link-local metadata addresses and from the host network where possible.
- Review policies when Services, ports, or namespaces change; stale allows are as bad as missing denies.
- Monitor drops and keep an exception process so emergency opens do not become permanent.
The practical takeaway
A Kubernetes NetworkPolicy is a CNI-enforced allowlist for pod ingress and egress. The API object does nothing until the dataplane implements it, and the default cluster network is allow-all.
Default-deny each namespace, open only the peers and ports you can name, and combine with admission so labels stay honest. NetworkPolicy shrinks how far a single compromised pod can walk.
Related security terms
Namespace Isolation
Namespaces alone do not block traffic; NetworkPolicy is what isolates packet flow.
Service Mesh
mTLS and identity policy complement, but do not replace, CNI-level NetworkPolicy.
Security Group
Cloud network ACLs sit outside the cluster; NetworkPolicy governs pod-to-pod paths.
Kubernetes Admission Controller
Admission can require that namespaces have a default-deny policy in place.
Multi-Tenant Isolation
NetworkPolicy is a required layer when tenants share a cluster network.
Frequently asked questions
What is a Kubernetes NetworkPolicy in simple terms?
It is a firewall rule for pods. You name which pods it applies to, then list which peers may connect in or which destinations those pods may call.
Does Kubernetes enforce NetworkPolicy by itself?
No. The API stores the object. A CNI plugin such as Calico, Cilium, Antrea, or cloud-provider policy must implement it. Without that, policies are documentation.
What is the default if no policy exists?
Pods are typically fully reachable on the cluster network. Once any ingress policy selects a pod, unmatched ingress is denied. Egress works the same way independently.
Is NetworkPolicy the same as a service mesh?
No. NetworkPolicy is L3/L4 (and sometimes L7 with advanced CNIs). A mesh adds workload identity and mTLS. Use both: packets and cryptographic identity.
Can NetworkPolicy replace cloud security groups?
No. Security groups and VPC firewalls still control node and load-balancer exposure. NetworkPolicy does not stop traffic that never enters the pod network.
How do DNS and egress default-deny interact?
A default-deny egress policy must explicitly allow DNS (kube-dns or CoreDNS) or name resolution fails and everything looks “broken.”
Should every namespace start with default deny?
Yes for production. Add a deny-all ingress and egress, then open only the peers and ports each workload needs, including DNS and health checks.
References
Explore authoritative guidance and frameworks related to kubernetes network policy.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.