Kubernetes Network Policies and Zero-Trust East-West Traffic

Ask most teams how their pods are segmented and the honest answer is: they aren't. A default Kubernetes cluster is a single flat network where any pod can open a connection to any other pod, in any namespace, on any port. Perimeter firewalls see none of this east-west traffic. So the moment one pod is compromised, the attacker's reachable surface is the entire cluster — and network policies are how you shrink that surface back to what each workload actually needs.

A NetworkPolicy is a namespaced object that selects pods by label and specifies which ingress and egress connections are allowed. The critical, counter-intuitive rule: policies are allow-lists that activate on selection. A pod with no policy selecting it permits all traffic; the moment any policy selects it for a direction, everything not explicitly allowed in that direction is denied. Segmentation begins the instant you write the first default-deny policy.

The pattern: default-deny, then allow what's needed

Zero trust for east-west traffic is a discipline, not a product: no implicit trust based on being 'inside' the cluster, and every allowed flow explicitly justified. The mechanical starting point is a default-deny policy per namespace — for ingress and, importantly, egress — followed by narrow allow rules for the connections each service legitimately makes.

Egress is the half everyone forgets

Teams write ingress rules and stop. But egress is what an attacker uses to exfiltrate data and reach a command-and-control server, and what a compromised pod uses to pivot to internal services. Restricting egress — so a payment pod can reach the database and nothing else — both contains a breach and turns an unexpected outbound connection into a loud, detectable anomaly. Locking down egress to the Kubernetes API server and cloud metadata endpoints (a classic SSRF-to-credential-theft path) is especially high value.

The limits of NetworkPolicy, and what goes further

Native NetworkPolicy operates at L3/L4 — IPs, ports, pod and namespace selectors — and it is only enforced if your CNI implements it (Calico, Cilium, and others do; some do not, in which case the policies are silently inert, a dangerous false sense of safety). It cannot express L7 rules like 'GET but not DELETE on this path'. For that, CNIs such as Cilium add L7-aware policy, and a service mesh (Istio, Linkerd) layers on mutual TLS so identity, not just IP, authorises a connection — the fuller expression of zero trust.

• Confirm your CNI enforces NetworkPolicy. If it doesn't, your policies are decorative. Verify before you rely on them.
• Default-deny per namespace, ingress and egress. Make the empty-allow-list the baseline and every flow an explicit, reviewed addition.
• Lock down egress to metadata and the API server. Cut the common SSRF-to-cloud-credential and rogue-API-call paths.
• Select by label, and keep labels honest. Policies are only as correct as the labels they match; a mislabelled pod is an unintended hole.
• Add mTLS for identity-based auth where the stakes justify a mesh. IP-based rules are spoofable within a shared network; cryptographic identity is not.

Segmentation converts a single compromised pod from a cluster-wide emergency into a contained incident. But a policy only protects the pods it selects, in the namespaces you have written it for, on a CNI that actually enforces it. An unlabelled workload, or a whole cluster running a CNI that ignores NetworkPolicy, is an open flat network hiding in plain sight — and you can't segment traffic you haven't mapped.