A privileged container is one started with Docker’s --privileged flag (or a privileged Kubernetes security context), which gives it almost all Linux capabilities, access to host devices, and a relaxed seccomp/AppArmor profile. That effectively removes the isolation boundary: an attacker inside can mount the host disk and escape to the host in a few commands. It exists for legitimate niche workloads, but on a normal app it is a critical misconfiguration.
What a privileged container is
Running a container with --privileged tells the runtime to drop most of its safety restrictions. The container gets nearly the full capability set, access to all host devices under /dev, and loosened syscall filtering.
The intent is to support workloads that genuinely need deep host access (some storage or networking tools). The side effect is that the container is barely separated from the host at all, which is why it is so dangerous on ordinary applications.
The escape and payload
From inside a privileged container, escaping to the host is short. A classic route is mounting the host disk:
- List host disks (visible because devices are exposed):
fdisk -l - Mount the host root filesystem:
mkdir /h && mount /dev/sda1 /h - Now read or write host files: drop a SSH key, a cron job, or
chroot /hto operate as the host.
Another route abuses the cgroup `release_agent` to run a command on the host as root. Documented techniques shown for defenders.
How to defend
- Never run application workloads as privileged. Treat
--privilegedas forbidden outside rare, audited infrastructure tools. - Drop all capabilities and add back only the specific ones needed.
- In Kubernetes, block privileged pods with Pod Security Standards (restricted) and admission control.
- Run as non-root with a read-only root filesystem and seccomp on.
- Scan manifests for
privileged: trueand the--privilegedflag in CI.