Kubernetes Network Policies: Microsegmentation for Container Workloads

The Problem: Flat Network

In a standard Kubernetes cluster, every pod can reach every other pod — regardless of the namespace. This is convenient for developers but a nightmare for security teams.

Understanding Network Policies

Network Policies are Kubernetes-native firewall rules at the pod level. They define which traffic is allowed — everything else is blocked (default deny).

• Ingress Policies: Control incoming traffic — which pods are allowed to communicate with this pod?
• Egress Policies: Control outgoing traffic — where is this pod allowed to establish connections?
• Label-based: Policies select pods via labels, not IP addresses — dynamic and Kubernetes-native.

Best Practices

• Default Deny: Start with a policy that blocks all traffic, then allow selectively.
• Namespace Isolation: Separate environments (dev, staging, prod) at the namespace level with policies.
• Allow DNS: Do not forget to allow egress to port 53 (DNS) — otherwise service discovery will stop working.
• CNI Plugin: Ensure your CNI plugin supports Network Policies. Calico and Cilium are recommended.

Conclusion

Network Policies are a must for production Kubernetes clusters. They cost nothing, are declaratively manageable, and drastically reduce the attack surface. At devRocks, they are part of every cluster setup.