Understanding East-West Traffic in Modern Data Centers
Network security has historically focused on north-south traffic: the flow of data between clients on the internet and servers inside the data center. Firewalls, intrusion detection systems, and DDoS mitigation appliances sit at the network edge and inspect traffic as it crosses the perimeter. This model ignores a fundamental reality: in modern architectures, the majority of network traffic is east-west, flowing laterally between servers, containers, and services within the data center or cloud environment.
In a microservices architecture, a single user request to an e-commerce application might trigger dozens of internal service calls: the API gateway calls the authentication service, which calls the user database, which triggers a cache lookup, which logs an event to the message queue, which notifies the recommendation engine. Each of these calls is east-west traffic, and each represents a potential attack path if the originating service is compromised. Controlling east-west traffic is therefore not optional in a Zero Trust architecture; it is the primary battleground.
Why Traditional Firewalls Fail at East-West Control
Traditional perimeter firewalls are architecturally unsuitable for east-west traffic control for several reasons.
- Traffic hairpinning: To inspect east-west traffic through a perimeter firewall, you must route internal traffic out to the firewall and back in. This introduces latency, consumes firewall capacity, and creates a single point of failure for internal communications.
- Scale limitations: In a Kubernetes cluster with hundreds of pods communicating over thousands of connections per second, a centralized firewall cannot keep up. The inspection bottleneck becomes the performance ceiling for the entire application.
- Ephemeral workloads: Containers and serverless functions are created and destroyed in seconds. Firewall rules based on IP addresses become stale before they can be applied. By the time a rule is written for container IP 10.244.3.47, that container may have been terminated and replaced by a new one at 10.244.5.12.
- Lack of application context: A Layer 3/4 firewall can see that pod A is communicating with pod B on port 8080. It cannot see that the request is a gRPC call to the PaymentService.Charge method with a specific payload structure. Without application-layer visibility, the firewall cannot distinguish between legitimate and malicious internal traffic.
Strategy 1: Kubernetes Network Policies
Kubernetes NetworkPolicy resources provide native east-west traffic control at the pod level. A NetworkPolicy is a namespace-scoped resource that selects pods using label selectors and defines allowed ingress and egress rules. By default, Kubernetes allows all pod-to-pod communication. When you apply a NetworkPolicy that selects a pod, all traffic not explicitly allowed by the policy is denied.
A practical example: in a three-tier application, you would create three NetworkPolicy resources. The database pods accept ingress only from pods labeled tier=backend on port 5432. The backend pods accept ingress only from pods labeled tier=frontend on port 8080 and are allowed egress to the database pods on port 5432. The frontend pods accept ingress from the ingress controller on port 443 and are allowed egress to the backend pods on port 8080.
The limitation of native NetworkPolicy is that it operates at Layer 3/4 only. You can restrict traffic by pod selector, namespace selector, IP block, port, and protocol, but you cannot write policies based on HTTP path, gRPC method, or request headers. For Layer 7 east-west control, you need a service mesh or an extended policy engine like Cilium.
Strategy 2: Service Mesh with mTLS and Authorization Policies
A service mesh like Istio, Linkerd, or Cilium with Envoy provides the richest east-west traffic control. The mesh injects a sidecar proxy alongside each workload, and all traffic between workloads flows through these proxies. This architecture enables three critical capabilities.
First, mutual TLS (mTLS) encrypts all east-west traffic and cryptographically authenticates both ends of every connection. Each workload receives a SPIFFE identity certificate, and the sidecar proxy validates the peer’s certificate on every connection. This means a compromised pod cannot impersonate another service because it does not hold the correct private key.
Second, authorization policies control which services can communicate and what operations they can perform. An Istio AuthorizationPolicy can specify that the payment-service in the production namespace is allowed to receive POST requests to the /charge endpoint only from the order-service, and only if the request includes a valid JWT token in the Authorization header. This level of granularity is impossible with network-level controls alone.
Third, traffic observability provides detailed telemetry for every east-west flow. The mesh emits metrics (request rate, error rate, latency percentiles), distributed traces (end-to-end request flow across services), and access logs (source identity, destination, method, path, response code). This telemetry is essential for detecting anomalous communication patterns that indicate lateral movement.
Strategy 3: eBPF-Based Enforcement with Cilium
Cilium uses eBPF (extended Berkeley Packet Filter) programs running in the Linux kernel to enforce network policies without the overhead of sidecar proxies. eBPF programs are attached to the network stack at the socket and TC (traffic control) layers, providing packet-level visibility and control with minimal performance impact.
Cilium’s CiliumNetworkPolicy CRD extends Kubernetes NetworkPolicy with Layer 7 awareness. You can write policies that allow HTTP GET requests to specific URL paths while denying POST requests, or that permit DNS queries to specific domain names while blocking all others. Cilium also supports identity-based policies using SPIFFE, enabling authentication-aware enforcement without a full service mesh.
The performance advantage of eBPF over sidecar proxies is significant. Sidecar proxies add two context switches per connection (application to proxy, proxy to network, and the reverse on the receiving end). eBPF programs execute inline in the kernel, avoiding context switches entirely. In benchmarks, Cilium adds 1-2% latency overhead compared to 5-10% for sidecar-based meshes, a meaningful difference for latency-sensitive applications.
Implementing a Layered East-West Control Architecture
In production environments, a single strategy rarely suffices. A layered approach combines the strengths of each method while mitigating their individual weaknesses.
- Layer 1 – Namespace isolation: Use Kubernetes NetworkPolicy to enforce coarse boundaries between namespaces. Production namespaces cannot communicate with development namespaces. Each team’s namespace is isolated from every other team’s namespace by default.
- Layer 2 – Service identity and encryption: Deploy mTLS across all services using either a service mesh or Cilium’s identity-based encryption. This ensures that even if an attacker gains access to the pod network, they cannot eavesdrop on or inject traffic into service-to-service communications.
- Layer 3 – Application-layer authorization: For sensitive services (payment processing, PII access, administrative operations), deploy Layer 7 authorization policies that inspect request methods, paths, and headers. These policies should be maintained in version control and deployed through CI/CD pipelines.
- Layer 4 – Runtime anomaly detection: Use the telemetry generated by the enforcement layers to detect deviations from expected communication patterns. A service that suddenly starts making DNS queries to external domains, or a pod that begins scanning internal IP ranges, should trigger an immediate alert.
East-west traffic control is the most technically demanding aspect of Zero Trust networking, but it is also the most impactful. Perimeter breaches are inevitable. The question is whether an attacker who compromises a single service can reach the crown jewels, or whether your east-west controls confine them to a compartment they cannot escape. Build your east-west strategy with the assumption that the perimeter has already been breached, and design your controls accordingly.