Home / Knowledge hub / Kubernetes network policy
Knowledge hub
Kubernetes network policy
Rules that say which pods may talk to which other pods.
What it means
A Kubernetes network policy is a rule that controls traffic to and from pods. It selects pods by label and lists which other pods, namespaces or address ranges they may exchange traffic with, in which direction and on which ports.
By default, pods in a cluster can talk to every other pod. Once a policy selects a pod for a direction, only traffic that some policy allows is permitted for it. Policies add up, and they only allow; there is no deny rule in the basic API.
Why it matters
An open internal network means one compromised pod can reach databases, internal tools and the metadata of other services. That is how a small foothold in a web front end becomes a path to customer data, a pattern known as lateral movement.
Network policy is the main way to limit that blast radius inside a cluster. It also supports isolation between tenants or teams sharing the same machines.
How it shows up
Policies are enforced by the cluster's network plugin, not by Kubernetes itself. If the plugin does not support them, you can create policy objects that do nothing and never see an error. Confirm your plugin supports enforcement and test it.
A common pattern is a default-deny policy per namespace, followed by narrow allow rules: front end to API, API to database, and DNS. Mistakes include forgetting egress, leaving whole namespaces open, and broad selectors that match more pods than intended.
Questions people ask
Kubernetes network policy, answered
Is there a default network policy?
No. With none in place, all pods can talk to all pods. Many teams add a default-deny policy per namespace and then allow specific flows.
Does network policy replace a firewall?
No. It controls pod-to-pod traffic inside the cluster. You still need controls at the edge and around the cluster.
Why would a policy have no effect?
Your network plugin may not enforce them. Test by trying a connection that should be blocked.
Does it control egress too?
Yes, if you include egress in the policy. Limiting outbound traffic helps stop a compromised pod from calling out.
Does it apply between namespaces?
Yes. Policies can select pods in other namespaces by label, so you can allow or block cross-namespace traffic.
Sources
Where this comes from
Related
Terms that sit next to this one
Kubernetes
A system that runs and manages containers across many machines.
Lateral movement
Moving from the first thing reached to the things worth taking.
Egress filtering
Limiting what your servers may connect out to, which blunts data theft.
Service mesh
A layer that handles encryption and identity between services in a cluster.
Tenant isolation
What keeps one customer's data unreachable from another's session.
What can one pod reach?
We test what a flaw in your running application lets someone reach, and prove it with the request and response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.