Microsegmentation is surprisingly less about blocking traffic and more about making explicit allow lists for every single component.
Let’s watch this in action. Imagine a simple web application with a frontend, a backend API, and a database.
# Kubernetes NetworkPolicy for Frontend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: frontend-allow
namespace: default
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector: {} # Allow from any pod in the namespace (initially)
ports:
- protocol: TCP
port: 80
egress:
- to:
- podSelector:
matchLabels:
app: backend
ports:
- protocol: TCP
port: 8080 # Allow egress to backend on port 8080
In this initial NetworkPolicy, the frontend can receive traffic from any pod in the default namespace (because podSelector: {} in the ingress from field means "all pods in this namespace"). It can also send traffic to the backend application on port 8080.
Now, let’s refine this. We want to restrict the frontend so it only receives traffic from our ingress controller, and only sends traffic to the backend.
# Kubernetes NetworkPolicy for Frontend (Refined)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: frontend-allow-refined
namespace: default
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: ingress-nginx # Assuming ingress controller is in a namespace with this label
podSelector:
matchLabels:
app.kubernetes.io/name: ingress-nginx # Specific pod selector for ingress controller
ports:
- protocol: TCP
port: 80
egress:
- to:
- podSelector:
matchLabels:
app: backend
ports:
- protocol: TCP
port: 8080
This refined policy is much more restrictive. The ingress section now specifies that traffic is only allowed from pods in a namespace labeled name: ingress-nginx and with the label app.kubernetes.io/name: ingress-nginx. The egress section remains the same, allowing traffic only to pods labeled app: backend on port 8080.
The core problem microsegmentation solves is the "east-west" traffic problem. In traditional networks, once traffic is inside the perimeter, it often has free reign to move between servers. If a compromised machine exists, it can pivot and attack others. Microsegmentation treats every workload as if it’s on a public network, requiring explicit authorization for all communication. It’s about least privilege applied at the network layer, down to individual pods or even containers.
Internally, this is often implemented by a network agent (like Calico, Cilium, or cloud provider solutions) running on each node. This agent programs network rules (e.g., iptables, eBPF) on the host kernel. When a packet destined for a pod arrives, or a pod tries to send a packet out, the kernel intercepts it and consults the programmed policies. If the traffic doesn’t match an explicit allow rule, it’s dropped. The "Zero-Trust" aspect comes from the assumption that no network location is inherently trusted.
The surprising part is how often people focus on the deny aspect of Zero Trust, when in reality, successful microsegmentation is built entirely on precise allow rules. You don’t try to list all bad things; you list all good things. This makes it auditable and predictable.
The next hurdle is managing these policies at scale, especially as your application topology changes dynamically.