Docker container hardening checklist

If a process inside a root-owned container escapes — via a kernel vulnerability or a supply-chain compromise — the attacker lands on the host as root. The fix is two lines in your Dockerfile and it costs nothing at runtime.

At runtime you can also pass --user 1000:1000 (or any non-zero UID) to override the image default. In docker-compose.yml: user: "1000:1000". The OWASP Docker Security Cheat Sheet treats this as the first line of defense against privilege escalation.

Linux capabilities break the all-or-nothing root model into roughly 40 discrete permissions. Docker grants a default subset at container start. --cap-drop all removes every capability; --cap-add lets you add back only the ones your process actually needs.

Most web servers and API processes need nothing. If a service binds to a port below 1024, add NET_BIND_SERVICE. Avoid SYS_ADMIN — it is a catch-all that re-opens most of what you just closed.

--security-opt no-new-privileges (OWASP Rule #4) prevents setuid and setgid binaries inside the container from acquiring capabilities at runtime — a common privilege-escalation vector that cap-drop alone does not close.

--privilegedgrants all Linux capabilities, disables the default seccomp profile, and disables AppArmor confinement. A privileged container has the same level of access to the host kernel as a process running directly on the host as root. It is not a “slightly less secure” option — it negates the containment model entirely.

Privileged mode appears in tutorials for Docker-in-Docker CI setups and some hardware-access use cases. In those narrow contexts it may be necessary. In a production application workload it is never acceptable. If you find --privileged in a docker-compose.yml or a deployment manifest, remove it and identify what capability the author actually needed — then add only that.

Docker's default seccomp profile blocks approximately 44 system calls out of 300+, including kernel-module loading, namespace manipulation, hardware I/O access, and io_uring operations — a kernel interface with a documented history of container-escape vulnerabilities.

The profile is enabled by default, but it is disabled whenever you pass --privileged or --security-opt seccomp=unconfined. Do neither. For high-assurance services, start from Docker's default profile and remove syscalls you can confirm are unused — but the default is the right baseline for most workloads.

Seccomp restricts which system calls a process can make. AppArmor restricts what resources — files, network interfaces, capabilities — a process can access. They are complementary layers, not alternatives.

Docker applies its default docker-default AppArmor profile automatically on systems where AppArmor is available (most Debian/Ubuntu hosts). Verify the profile is loaded and active with aa-status | grep docker. On Fedora/RHEL hosts, the equivalent is an SELinux policy — confirm with getenforce. A container running --security-opt apparmor=unconfined or in a permissive-SELinux environment is missing a significant isolation layer.

A container without resource limits can exhaust host memory and CPU, taking down every other container and the host itself — a denial-of-service from one compromised workload. This is especially relevant when containers are running AI agent processes that may spawn sub-processes or consume unbounded context windows.

The deploy.resourcesblock is honoured by Docker Compose in standalone mode (v2 Compose file format). Set limits that reflect your application's actual steady-state usage, not the maximum you could imagine — the goal is to cap runaway processes, not to starve normal operation.

--read-onlymounts the container's root filesystem read-only. An attacker who compromises the process cannot drop scripts, modify binaries, or establish persistence via the filesystem. When the application needs to write temporary data, pair it with --tmpfs /tmp to provide an in-memory writable scratch area.

Not all applications support a fully read-only root — some write to locations like /etc or /var at startup. Use docker run --read-only in staging first to identify which paths need writable mounts, then add only those explicit volumes or tmpfs mounts in production.

Each of the seven checks above is a deterministic test — the answer is pass, warn, or critical, not a probability. Keelix runs all of them as part of its whole-box scan and folds the results into your 0–100 posture score alongside exposure, host configuration, and AI/MCP findings. One scan, one score.

CVE scanners tell you what software versions are on disk. Keelix tells you whether the runtime configuration limits what a compromised process can actually do — the two questions are independent, and both matter. Run Keelix before you ship; gate CI on the posture score; get the finding before it goes live.