What are network policies?
Network policies control which workloads can talk to which, at the network level. In Kubernetes they are objects that allow or deny traffic between pods; in the cloud they are security groups and firewall rules. The goal is least-connectivity: nothing talks to anything it does not need to.
Why it matters
By default, everything inside a cluster or network can often reach everything else, so one compromised pod can move laterally to the whole system. Network policies contain a breach to a small blast radius. This segmentation is a key part of defense in depth and a growing compliance requirement.
What to learn
- Default-allow versus default-deny postures
- Kubernetes NetworkPolicy objects
- Ingress and egress rules
- Cloud security groups and firewall rules
- Segmenting tiers: web, app, data
- Zero-trust networking principles
- Testing that a denied path is actually blocked
Common pitfall
Assuming pods are isolated when the cluster actually allows all pod-to-pod traffic by default. Until you apply a default-deny policy, a compromised container can reach every other service. Start from deny-all and explicitly allow only the connections each workload needs.
Resources
Primary (free):
- Kubernetes — Network policies · docs
- Cilium — Network policy guide · docs
- NIST — Zero trust architecture · docs
Practice
In a cluster, apply a default-deny NetworkPolicy to a namespace, then add an explicit policy allowing only your app to reach its database. Confirm another pod cannot reach the database. Done when the only permitted connections are the ones you allowed.
Outcomes
- Explain default-deny versus default-allow networking.
- Write Kubernetes network policies for ingress and egress.
- Segment tiers with cloud security groups.
- Verify that a denied connection is actually blocked.