How it works
Kernel flaws, unsafe mounts or excessive privileges weaken the isolation between a workload and its host, while the orchestration API offers a legitimate path to deploy code, read secrets and assume service identities across every node.
Escapes are usually configuration, not exploits
Kernel exploits get attention; configuration hands over the host far more often, and the culprits are a short list.
- Privileged containers, which disable most isolation by design and are frequently used to make something work quickly.
- The host container socket mounted into a workload — control of that socket is control of every container on the host, including privileged ones.
- Host filesystem mounts, particularly of configuration or credential directories.
- Host network or PID namespaces, which remove the separation they were meant to provide.
- Excess capabilities retained because the default set was never trimmed.
- Containers running as root, so a process escaping the filesystem boundary arrives on the host as root.
The orchestrator is the real prize
Escaping to one host is a limited outcome. Reaching the orchestration API is a much larger one, because it is a legitimate interface for running code on any node.
An identity with sufficient rights can schedule a workload that mounts the host, read secrets from any namespace, or open an interactive session in an existing pod. None of this requires an exploit; it is the API working as designed for someone who should not be using it.
Service account tokens mounted into pods are the usual bridge. A compromised application reads its token, and whatever that token can do in the cluster becomes reachable — which is why default-mounted tokens with broad permissions turn a single application vulnerability into cluster compromise.
The controls are least-privileged RBAC, not mounting tokens into workloads that do not call the API, and separating the identity a workload runs as from the identity an operator uses.
Admission control is where policy becomes real
Guidance that privileged containers are forbidden is guidance. Admission policy that refuses to schedule them is a control, and the difference matters because the pressure to make an exception always arrives during an incident or a deadline.
Enforce at admission: no privileged containers, no host namespace sharing, no host path mounts outside an allow-list, no images from unapproved registries, and required resource limits so one workload cannot starve a node.
Pair it with runtime behavioural monitoring, since admission control validates what was requested while runtime detection catches what a workload actually does — a container that suddenly reads host paths or spawns unexpected processes is worth an alert regardless of how it was admitted.
Also known as
What defenders may observe
- A container accessing host namespaces, devices or sockets
- Unexpected host processes following container activity
- Privileged or host-mounted workloads appearing
- Unusual orchestration API operations or exec sessions
- New privileged workloads or role bindings
- Secrets read by principals other than their owning controller
Prevention and mitigation
- Run workloads rootless, unprivileged and with minimal capabilities
- Never mount the host container socket into a workload
- Patch hosts and container runtimes — isolation depends on the shared kernel
- Enforce admission policy so non-compliant workloads cannot be scheduled
- Apply least-privileged RBAC and separate operator from workload identity
- Audit orchestration API activity and isolate secrets with network policy
Initial response priorities
- Freeze unauthorized control-plane changes and rotate credentials.
- Trace the affected artifact, pipeline or trust relationship.
- Rebuild from verified sources and review downstream exposure.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.