🐳 Docker Top 10 Misconfigurations
Intro: Docker mistakes are dangerous because they blur boundaries between build, runtime, host, and registry trust. A secure program treats Docker as a system, not just a Dockerfile.
| # | Misconfiguration | Why it is dangerous | Better pattern |
|---|---|---|---|
| 1 | Runtime as root | Easier privilege abuse after compromise | Run as non-root and validate at deploy time |
| 2 | Floating base images | Uncontrolled drift and hard-to-reproduce builds | Pin intentionally and refresh on schedule |
| 3 | Secrets copied into layers or passed via weak build args | Secrets survive in image history or CI output | Use runtime secret injection or build secret mounts |
| 4 | No image provenance or signing | Hard to know what artifact is really running | Sign promoted images and verify before deploy |
| 5 | Pulling from untrusted registries | Increased malware and poisoned-image risk | Use curated registries and trusted image sources |
| 6 | No patch/rebuild discipline | Known CVEs remain deployed too long | Rebuild, rescan, and redeploy immutable images |
| 7 | Shared hosts across incompatible trust tiers | Breakout or noisy-neighbor impact grows | Segregate sensitive and public-facing workloads by host or node pool |
| 8 | Overly broad Docker daemon access | Docker control often equals host root | Restrict daemon access and remote API exposure |
| 9 | Weak host hardening | Container controls inherit weak host posture | Keep kernel updated, keep LSMs enabled, harden daemon and host OS |
| 10 | No limits on resources or runtime behavior | DoS and post-exploitation activity become easier | Apply memory, CPU, filesystem, and syscall limits |
The five risks every team should know by heart
A useful way to teach Docker risk is to keep five recurring failure modes visible:
- kernel exploit;
- denial of service;
- container breakout;
- poisoned image;
- compromised secrets.
Those five categories explain most “why does this hardening control exist?” conversations.
Signs of a mature Docker operating model
- images are rebuilt instead of patched manually;
- base image ownership is explicit;
- registry promotion path is curated;
- host security is treated as part of container security;
- runtime privileges are intentionally small;
- detection exists for unusual daemon, registry, and container activity.
Quick review prompts
- which users can control the Docker daemon?
- which registries are allowed for production workloads?
- which images can cross from dev to prod?
- which workloads are allowed to run with elevated privileges?
- which hosts or node pools can run sensitive workloads?