Hardening Docker hosts and daemons: CIS ideas, rootless mode and user namespaces

Why the host matters

All containers on a host share its kernel and are managed by the Docker daemon, which by default runs as root. If an attacker escapes a container, or gains access to the daemon, they usually own the host and every container on it. Hardening the host and daemon limits that blast radius. The CIS Docker Benchmark from the Center for Internet Security is a widely used checklist; the ideas below follow its main themes in plain terms.

The host

• Use a minimal, supported Linux distribution or a container-optimised OS, and patch the kernel promptly.
• Run only container workloads on the host; avoid mixing in unrelated services.
• Put Docker data (/var/lib/docker) on its own partition so a full disk from container logs or images does not take down the OS.
• Enable auditd rules for Docker files and binaries and forward logs centrally. See Linux hardening for general host steps.

The daemon and its socket

Anyone who can talk to the Docker socket can start a privileged container and mount the host filesystem, so membership of the docker group is effectively root. Keep that group small, never expose the daemon on an unauthenticated TCP port, and if remote access is required use SSH or mutual TLS.

{
  "icc": false,
  "live-restore": true,
  "no-new-privileges": true,
  "userns-remap": "default",
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

This example /etc/docker/daemon.json disables unrestricted traffic between containers on the default bridge, keeps containers running during daemon restarts, blocks privilege escalation by default, enables user namespace remapping and caps log size. Test such changes in a lab first, because some applications depend on the defaults.

Rootless mode and user namespaces

User namespace remapping (userns-remap) maps UID 0 inside containers to an unprivileged range of UIDs on the host. A process that is root in the container is just an ordinary user outside it. Rootless mode goes further: the daemon itself and all containers run under a normal user account, so even a daemon compromise does not give host root. Podman takes a similar daemonless, rootless-first approach.

dockerd-rootless-setuptool.sh install
systemctl --user enable --now docker
docker context use rootless

Rootless mode has some limits, for example binding to ports below 1024 needs extra configuration and some network and storage drivers behave differently. Check these against your workloads.

A practical checklist

Tip: the open-source docker-bench-security script checks a host against many CIS recommendations. Run it on your own lab host to see where you stand.