Lateral movement
The pivot chain and default-deny east-west.
Lateral movement is how a single foothold becomes cluster compromise. Following the attacker’s path — and knowing which control breaks each hop — is what turns a scary abstraction into a defensible design.
The pivot chain
A typical intrusion chains stolen identities. An attacker with RCE in a pod reads its service-account token and the secrets it can reach, uses that token against the API to enumerate and access other namespaces, creates a privileged pod (if RBAC allows) to break out to the node, and from the node harvests every co-located pod’s token — or queries the cloud metadata endpoint to lift the node’s cloud credentials and escape the cluster entirely. Each hop reuses the previous one’s spoils. The defensive counterpart is a control at every hop: minimal tokens, tight RBAC, network default-deny, admission policy against privileged pods, and blocked metadata access.
# ATTACKER PIVOT DEFENSE THAT BREAKS IT# RCE in pod → read SA token → automountServiceAccountToken: false# token → API → other namespaces → least-privilege RBAC (no cross-ns)# reach other services → NetworkPolicy default-deny# create privileged pod → node → PSA restricted / policy engine# node → co-located pod tokens → node isolation for sensitive tiers# pod → 169.254.169.254 → cloud → block metadata (IMDSv2 hop-limit / netpol)
Default-deny east-west
Network policy is the single most effective brake on lateral movement. By default, every pod can talk to every other pod, so a foothold can freely scan and reach the whole cluster. A default-deny NetworkPolicy blocks east-west traffic until you explicitly allow the flows a workload needs, boxing a compromised pod into a tiny reachable surface. Combined with least-privilege tokens (so a stolen token opens few API doors) and node isolation (so an escape stays local), default-deny networking turns the flat, wide-open cluster into a series of small, contained cells — exactly what denies an attacker the easy pivots.