Kubernetes Network Policies — Microsegmentation in the Cluster

By default, every pod in Kubernetes can communicate with every other pod. From a security perspective, this is unacceptable. Network Policies allow you to define who can talk to whom.

Why the Default State Isn’t Enough¶

Imagine this: you have a production database and development workload in your cluster. By default, a developer’s experimental pod can directly access the production database. All it needs is the IP address or DNS name of the service.

Prerequisite: CNI Plugin with Network Policy Support¶

Not every CNI plugin supports Network Policies. Flannel — no. Calico — yes. Weave — yes. Cilium — yes. We use Calico, which offers extended GlobalNetworkPolicy in addition to standard Network Policies.

Example: Database Isolation¶

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-only-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgresql
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-server
    ports:
    - protocol: TCP
      port: 5432

Strategy: Default Deny¶

We recommend starting with a default deny policy in every namespace and then explicitly allowing necessary communication. It’s more work upfront, but dramatically improves your security posture.

Practical Tips¶

• Don’t forget to allow DNS (port 53) in egress rules
• Labels are fundamental — a consistent labeling strategy is essential
• Test policies in dev environment before deploying to production
• Calico has excellent calicoctl for debugging network rules
• Visualization: Weave Scope or Calico Enterprise for graphical overview

Network Policies Are the Foundation of Zero Trust in Kubernetes¶

Network isolation in the cluster isn’t nice-to-have, it’s a necessity. With Network Policies, you implement the principle of least privilege at the network level and dramatically reduce the blast radius of potential compromise.