Kubernetes Is Flat by Default. One Compromised Pod Can Reach Everything.

Most teams think of a Kubernetes breach as a wall being broken. In reality it is usually a single room being entered, followed by a stroll through every other room in the building because none of the interior doors were locked. That stroll has a name. Security teams call it lateral movement, and Kubernetes makes it easy, because the default network is flat.

Flat means every pod can reach every other pod. Your public-facing web pod can talk directly to your database pod, your secrets store, and the cluster's control plane, with nothing in between saying no. So the moment one container is compromised, whether through a vulnerable dependency, a leaked credential, or a container escape, the attacker does not have a foothold. They have the run of the place.

Kubernetes was designed so that every pod gets its own IP and can, in principle, reach every other pod directly, with no NAT and no port mapping. That is genuinely convenient when you are getting a cluster running. It is also, from a security standpoint, the absence of a posture rather than a posture.

The consequence is blunt. When a container in a compromised pod attempts lateral movement, nothing in the default network model prevents it from reaching the database, the secrets store, or the Kubernetes API server. A single vulnerable container becomes a launchpad. Investigators who work these incidents describe the same arc again and again: one pod compromised, then a pivot through the cluster, then databases read, secrets exfiltrated, and in the worst cases the control plane itself reached. Attackers have a shorter word for a flat network. They call it paradise.

This is why the OWASP Kubernetes Top 10 for 2025 puts missing network segmentation, insecure workload configuration, and overly permissive authorization at the top of what actually gets found on production clusters. These are not exotic zero-days. They are the three controls most teams skip when shipping under a deadline, and a new 2025 entry for cluster-to-cloud lateral movement shows the blast radius now extends past the cluster and into the cloud account itself through workload identity.

There is a reason this problem is spreading faster in 2026. A growing share of the Terraform and Kubernetes manifests running in production was written by an AI assistant, and AI-generated infrastructure code reliably reproduces the insecure defaults in its training data: containers running as root, logging switched off, permissive roles, and, crucially, no network policies at all. The model optimizes for making it run, and a flat network with a root container runs perfectly until the day it does not.

We went deep on the code-quality side of this in AI passes coding tests 86% of the time, on infrastructure code it passes 19%, and on the invisible debt it creates in vibe coding's hidden security debt. This article is about the other half: not whether the generated code is written well, but whether the cluster it lands in can contain a compromise when one inevitably slips through. Even perfectly reviewed code runs inside a runtime, and the runtime is where lateral movement happens.

Segmentation matters even more once you remember that the boundary of a container is thinner than people assume. Container escape vulnerabilities (the runc Leaky Vessels flaw, CVE-2024-21626, is a well-known example) let a process inside a container break out to the underlying host. From the host, an attacker can reach other workloads, harvest tokens from the node's filesystem, and probe the kubelet API. The right mental model is not if a container is breached but when, and to design so that the breach is survivable.

That means limiting what a container can do in the first place. A container that runs as root, with a full set of Linux capabilities and a writable filesystem, hands an escape most of what it needs. A container stripped to least privilege, with seccomp and AppArmor profiles constraining its syscalls, gives an attacker far less to work with even after a successful escape. Hardening the workload and segmenting the network are two halves of the same idea: shrink the blast radius before anything goes wrong.

You do not fix this by hoping developers write perfect manifests. You fix it by making the cluster itself defensible, so a mistake or a breach is contained by design. In practice that is a stack of controls that work together:

That combination is precisely the work our Cloud Armor build does across AWS, Azure, and GCP: systematically hardening container and cloud infrastructure so a single compromise cannot become a cluster-wide incident. But the principle stands on its own. Kubernetes gives you speed. It does not give you containment for free. Containment is a decision you make on purpose.

The dangerous thing about a flat Kubernetes network is that everything works. The app runs, the tests pass, the demo looks great, and nobody notices that any pod can reach the database and the control plane until an attacker does. Missing segmentation, permissive workloads, and unencrypted internal traffic are the defaults, not the exceptions, and AI-generated manifests are spreading those defaults faster than review can catch them. Hardening is not a single tool. It is default-deny networking, enforced pod security, constrained container privileges, encrypted traffic, secure IaC baselines, and continuous scanning, working together so that when one container falls, it stays one container.