Containers · Learn

What is a container escape?

A container escape is when an attacker breaks out of a container and gains access to the host running it, turning one compromised app into control of the whole machine and every container on it. Here is how escapes happen and how to prevent them.

Containers · LearnCloud Penetration Testing
TL;DR

A container escape is when an attacker breaks out of a container and reaches the host (or the Kubernetes node) it runs on, because the isolation boundary was weak or misconfigured. Once on the host, they control every container on that machine and can pivot further. Common causes are privileged containers, a mounted Docker socket, shared host namespaces, a host-path mount, or a dangerous capability like CAP_SYS_ADMIN. Preventing it means removing those over-permissions and keeping the kernel patched.

By John Dill, Red Team Lead, SecureLayer7Updated

What a container escape is

A container is meant to be a sealed box: the process inside should only see and touch its own files, processes, and network. A container escape is any technique that breaks that seal and gives the attacker access to the underlying host.

Because every container on a host shares that one kernel, escaping to the host is game over for that machine: the attacker can read other containers, steal their secrets, and use the host as a launch point into the rest of the environment.

How escapes happen

Escapes almost always come from a misconfiguration that hands the container too much access, not an exotic kernel bug. The usual routes:

Why it matters in Kubernetes

In Kubernetes, escaping a pod onto its node is rarely the end. From the node the attacker can read every pod scheduled there, steal their service account tokens, and use those to talk to the API server and move across the whole cluster, then into the cloud account the cluster runs in.

That is why a single weak pod is a cluster-wide risk.

How to prevent escapes

  • Never run privileged containers or mount the Docker socket into workloads.
  • Drop all capabilities and add back only what is needed; avoid CAP_SYS_ADMIN.
  • Do not share host namespaces or mount sensitive host paths.
  • Run as non-root, read-only root filesystem, with seccomp and AppArmor on.
  • Enforce Pod Security Standards and admission control in Kubernetes.
  • Patch the host kernel and test the cluster for real escape paths.

References

  1. [1]MITRE ATT&CK: Containers Matrix(MITRE)
  2. [2]NIST SP 800-190 Application Container Security Guide(NIST)
Related terms

Common questions

Container security, asked often

Want your containers and clusters tested for these paths?

Scope an engagement

Find the container escape paths before an attacker does.

We test your Docker hosts and Kubernetes clusters the way a real intruder would, from a compromised pod to the node and the rest of the cluster, then hand your team reproducible evidence and a fix for every step. Free re-test included.

See cloud penetration testing30-min scoping call, fixed-price proposal in 48 hours.