A Kubernetes cluster groups pods into namespaces — logical partitions used to isolate teams or environments, not a security boundary by themselves. Three independent controls actually keep a compromised pod contained:
- Network Policy — by default every pod can talk to every other pod ("flat network"). Without an explicit policy, a compromised web-app pod can open a connection straight to the database pod. A Network Policy allow-lists only the traffic a pod actually needs, so that lateral hop is refused at the network layer.
- RBAC (Role-Based Access Control) — every pod runs under a service account, and RBAC binds that account to a Role that lists exactly which API verbs (get/list/create/delete) it may use on which resources. Without a scoped Role, a compromised pod's default token can list secrets or pods cluster-wide; with least-privilege RBAC, that API call is rejected as forbidden.
- Pod Security (Pod Security Admission / SecurityContext) — forbids running a container as root and forbids
privileged: true. A privileged container shares the host's kernel namespaces, so an attacker inside it can mount the host filesystem and step straight out of the container. Pod Security rejects that container at admission time, so it never launches privileged in the first place.
Run the simulation with all three enabled to watch each step get blocked in turn, then flip a toggle off to see exactly what a missing control lets through — this mirrors real cluster misconfigurations, where teams often ship without one of the three and only find out during an incident.