The escape mindset

From one popped container to the whole host.

A container escape is the moment isolation fails and code that was confined to a container gains control of the host. Understanding escapes is a defensive skill: every one abuses a specific weakening of the boundary you now know from the inside — a shared namespace, an over-granted capability, a dangerous mount, or a kernel bug. The good news is that the vast majority of real-world escapes are configuration, not exotic zero-days, which means they are preventable by the controls in this course.

Why defense in depth, concretely

No single control is trusted to hold, so you stack them and make each escape step cost the attacker something. A foothold in a non-root, capability-stripped, read-only container has almost nothing to assess and nothing to install. If they somehow escalate, seccomp has cut the syscalls a kernel exploit would use. If they still break out, a user namespace means they land as an unprivileged host user, and Falco has already fired on the anomalous behavior. Every layer that was in place is one the attacker had to get through.

The attacker’s first question is your checklist

On landing, an attacker checks: am I root (id)? what capabilities do I hold (capsh --print)? is the Docker socket mounted (ls /var/run/docker.sock)? are host paths mounted (mount, /proc/mounts)? is this privileged (can I see host devices in /dev)? Each “yes” is an escape route — and each is something you already know how to turn into a “no.” Reading the escapes as a checklist of misconfigurations to eliminate is exactly the right frame.

# the same recon a defender runs to audit a container’s blast radius
$ docker exec web sh -c 'id; capsh --print 2>/dev/null | grep Current; \
    ls -la /var/run/docker.sock 2>/dev/null; mount | grep -E " /host| / " | head'
# root? dangerous caps? socket mounted? host paths? each hit is a finding to fix.