A container breakout is when an attacker escapes a container (e.g., a Docker/Kubernetes pod) and reaches the host OS. From there, they can read sensitive files, tamper with other containers, or run malware with host-level access. (Escaping a virtual machine is similar but is usually called a VM escape.)
Kernel bugs: containers share the host kernel; a vuln can break isolation.
Over-privileged containers: --privileged, extra capabilities, or unsafe syscalls.
Dangerous mounts: mounting /var/run/docker.sock, host dirs, or device files.
Weak pod policies: no admission controls, no seccomp/apparmor, no read-only FS.
Unexpected host processes spawned by a container
New mounts, modified binaries, or odd activity in /var/run, /etc, /proc
Lateral movement between pods/nodes; secrets accessed from other workloads
Isolate the node from the network; cordon/drain in Kubernetes if possible.
Capture evidence (logs, container and kernel events) before stopping containers.
Rotate secrets (K8s secrets, cloud creds, registry tokens) from a clean admin host.
Rebuild compromised nodes from clean images; don’t just restart containers.
Least privilege: drop capabilities, avoid --privileged, use read-only FS and non-root users.
Harden the host: keep kernel up to date; enable seccomp/AppArmor/SELinux.
Safe mounts: never mount the Docker socket; restrict hostPath volumes.
Policies & scanning: apply Pod Security Standards/OPA; scan images and block risky ones.
Network & secrets: segment workloads; use minimal, scoped tokens and short-lived creds.