What Can Go Wrong
Containers Are Not a Security Boundary (By Default)
Containers share the host kernel. A default docker run gives the app a root user, a writable filesystem and a dozen kernel capabilities it almost never needs. If the app is compromised, all of that belongs to the attacker.
The two catastrophic anti-patterns:
Danger: --privileged disables essentially every isolation mechanism - all capabilities, all devices, no seccomp. A privileged container is root on the host wearing a thin costume. It exists for tools like Docker-in-Docker, never for apps.
Danger: Mounting/var/run/docker.sockhands the container the Docker API. Whoever holds the socket can start a privileged container with the host's/mounted - i.e., they own the machine. Treat the socket like the root password, because it is one.
# Audit any container in seconds:
$ docker inspect app --format '{{.HostConfig.Privileged}}'
$ docker inspect app --format '{{range .Mounts}}{{.Source}}{{"\n"}}{{end}}' | grep docker.sock
$ docker exec app id # uid=0(root)? that's finding #3
| Risk | Why it matters |
|---|---|
| Runs as root | container escape = root on host; file writes anywhere it can reach |
| Extra capabilities | NET_RAW, SYS_ADMIN etc. are escape toolkits |
| Writable rootfs | attacker persists malware, rewrites the app |
| Secrets in image/env | anyone with the image or inspect rights reads them |