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.sock hands 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
RiskWhy it matters
Runs as rootcontainer escape = root on host; file writes anywhere it can reach
Extra capabilitiesNET_RAW, SYS_ADMIN etc. are escape toolkits
Writable rootfsattacker persists malware, rewrites the app
Secrets in image/envanyone with the image or inspect rights reads them