Docker Security Hardening Tutorial 2026: Daemon, Rootless, Runtime & Scanning

Root Daemon = Root Host

The classic Docker daemon runs as root. Anyone who can reach /var/run/docker.sock — or is in the docker group — can mount the host filesystem into a container and read or write any file as root. Docker group membership is root-equivalent.

Shared Kernel

Containers are not VMs. Every container shares the host kernel. A kernel exploit or a dangerous syscall reached from inside a container can break isolation entirely — which is why seccomp and capability dropping matter.

Root-by-Default Processes

Unless an image sets a USER, the process inside runs as UID 0. Combined with a writable root filesystem and extra capabilities, an application RCE becomes in-container root with room to pivot.

Opaque Supply Chain

A :latest tag is a moving target. Public base images carry hundreds of OS packages, many with known CVEs. Without pinning and scanning, you ship vulnerabilities you never wrote.

Before changing anything, record the current state so you can measure improvement and roll back. Capture engine version, storage driver, cgroup version and whether any LSM is active.

Hardening steps restart the daemon and swap seccomp/AppArmor profiles. Do this on a throwaway VM (Proxmox, VirtualBox, a cloud instance you can destroy) — never first on a host running live workloads. Create a snapshot now.

The daemon config is where host-wide defaults live. This configuration enables user-namespace remapping, turns on live-restore (containers survive daemon restarts), disables inter-container communication on the default bridge, enables no-new-privileges globally, and caps log growth so a chatty container cannot fill the disk.

The CIS Benchmark is strict about file ownership on the daemon socket and config files, because write access to any of them is effectively root. Set correct ownership and modes, and audit who is in the docker group — treat that group as a list of root-equivalent accounts.

The Linux audit framework records every access to the Docker binaries, socket and config. These rules are the raw signal we later forward to a SIEM. Each watch key (-k) becomes a searchable field downstream.

With no-new-privileges set globally in daemon.json (step 1), any setuid binary inside a container can no longer gain additional privileges — the kernel PR_SET_NO_NEW_PRIVS bit is set on container processes. Confirm it actually takes effect by trying to escalate inside a test container.

Never run rootless Docker as your interactive login account. Create a locked service user with its own subordinate UID/GID range and a persistent systemd user session (linger), so the daemon survives logout.

Rootless mode needs uidmap (for newuidmap/newgidmap), dbus-user-session for the per-user systemd bus, and slirp4netns/fuse-overlayfs for userspace networking and storage.

Switch into the service user's own systemd session and run the bundled setup tool. It installs a docker.service under the user's systemd, not the system one.

A rootless daemon cannot bind ports below 1024 by default. Rather than grant cap_net_bind_service to the whole daemon, publish on a high port and reverse-proxy, or allow low ports explicitly via sysctl for the rootless process only.

Tags move; digests do not. Pinning image@sha256:... guarantees every build and every host pulls the exact bytes you reviewed and scanned. Resolve the current digest once, then commit it.

The build stage has compilers and dev headers; the final stage ships only the runtime and the app, running as a dedicated non-root UID with no shell package. The USER directive is the single highest-value line in the file.

A missing .dockerignore is how .git, .env files and SSH keys end up baked into images and pushed to a registry. Exclude everything secret or unnecessary, and build with BuildKit for better caching and secret handling.

Containers start with a default capability set that most apps never use. Start from zero and add back the minimum. A web server that binds a low port needs only NET_BIND_SERVICE; a plain app server usually needs nothing.

A read-only root filesystem defeats persistence: an attacker with code execution cannot drop a web shell, modify a binary or write a cron entry. Mount small writable tmpfs areas only where the app genuinely needs to write (temp, caches, pid files).

Docker's default seccomp profile already blocks around 44 dangerous syscalls. For sensitive workloads, tighten further: start from the default profile and remove syscalls the app does not use. Below we derive the exact set with strace, then whitelist only those.

AppArmor (or SELinux on RHEL) constrains file and capability access beyond seccomp's syscall layer. Resource limits via cgroups stop a compromised container from starving the host — a crypto-miner pinned to 0.5 CPU and 256 MB is loud and contained.

Here is everything above expressed as a single declarative stack. Every security control is explicit: non-root user, dropped capabilities, no-new-privileges, custom seccomp, AppArmor, read-only rootfs with scoped tmpfs, pids and memory limits, a loopback-only published port, a healthcheck, and bounded logging. Copy it, swap the image digest, and adapt the tmpfs paths to your app.

An ENV API_KEY=... or a COPY .env is permanent — it lives in the image history even after a later layer "deletes" it. Use BuildKit secret mounts at build time (never persisted) and file-based secrets at runtime.

Signing proves provenance; an SBOM (software bill of materials) lets you answer "are we affected?" the next time a library CVE lands. Sign on push with cosign and attach an SBOM.

Trivy finds OS-package and language-dependency CVEs, hardcoded secrets and Dockerfile misconfigurations. Run it locally, and make the build fail on HIGH/CRITICAL so vulnerable images never leave CI.

The official Docker Bench script runs the CIS Docker Benchmark checks against your live host — daemon config, file permissions, and container runtime flags — and prints exactly which controls pass, warn or fail. Run it from the host or as a container.

Shift scanning left so a vulnerable image never reaches a registry. This pipeline builds, scans with Trivy, and uploads SARIF to GitHub code scanning — failing the job on HIGH/CRITICAL.

The Sentinel AMA agent collects auditd via the Linux data connector; Splunk uses the Add-on for Unix and Linux with an auditd input, or the Splunk Connect for Syslog. Deploy Falco for high-signal runtime alerts (shell-in-container, sensitive mount, outbound connection from an unexpected container).

Writes to the Docker socket from an unexpected process, and any container started with --privileged, are the two highest-value signals. The socket watch (docker_socket) and daemon command lines surface both.

A hardened container should rarely, if ever, have someone exec an interactive shell into it in production. docker exec landing a shell, or a shell process whose parent is a container runtime, is a strong hands-on-keyboard signal.

Hardening sometimes breaks the app. Use this table to tell a genuine security block from a profile that is simply too tight.