Docker's isolation makes containers feel safe, and that feeling is the danger. A container is not a virtual machine: it shares the host kernel, and a misconfiguration that would be a minor issue on a VM can become a full host compromise in a container. The good news is that most Docker security problems come from a small set of well-known mistakes, and fixing them is mostly a matter of defaults and discipline rather than deep expertise. Run through this checklist before your next deploy, not after an incident.

Never Run as Root, and Never Mount the Socket

The first two rules are the ones that matter most. Containers run as root by default, which means a process that escapes the container has root on the host. Add a non-root user to your images and run containers with an explicit user — a one-line change in the Dockerfile and the Compose file that removes the worst-case outcome. Equally important: never mount the Docker socket into a container. A container with access to the socket can start new containers with full host access, which is effectively giving it root on the host. Tools that need the socket, like some CI runners, deserve their own isolated host or a socket proxy with strict limits.

Read-only filesystems are the third cheap win. Run containers with a read-only root filesystem and only mount writable volumes where the application genuinely needs them, such as an uploads directory or a temporary folder. An attacker who cannot write to the filesystem cannot install tools, modify the application, or persist malware. Combine this with dropping unnecessary Linux capabilities — containers do not need most of them — and the escape routes narrow dramatically.

Images, Secrets and the Network

Your images are your supply chain, and most images contain more than you think. Use minimal base images, such as Alpine or distroless variants, which carry fewer packages and therefore fewer vulnerabilities. Scan images in your pipeline with a tool like Trivy or Grype and fail the build on critical vulnerabilities — scanning only helps if it blocks bad images, not if it merely reports them. Pin image versions by digest rather than by a moving tag like latest, so a deploy today runs the exact image you tested yesterday.

Secrets deserve their own rule: never bake them into images. Passwords, API keys and tokens baked into an image layer stay in that layer forever, even if you delete them in a later layer, and anyone with the image can extract them. Use Docker secrets, a vault, or environment variables injected at runtime from a secure store. On the network side, put containers on isolated networks by default, expose only the ports that must be public, and run a reverse proxy in front of anything that faces the internet. A database that is reachable from the public internet is a breach waiting for a scanner to find it.

Keep the Host and the Pipeline Honest

Security does not stop at the container boundary. Keep the Docker engine and the host operating system patched — container escapes that rely on kernel vulnerabilities are rare but real, and patching is the only defence. Enable Docker Content Trust or image signing so only images you built can be deployed, and keep the build context small: a careless COPY that includes your .git directory or a .env file leaks credentials into the image. Add resource limits to every container, because a runaway process that consumes all host memory is a denial of service even without an attacker.

Finally, log and watch. Centralise container logs, alert on unexpected container restarts, and review who can access the Docker host — SSH keys, sudo access, and the Docker group all grant effective root, so treat them accordingly. None of these steps is difficult on its own; together they turn a default Docker setup, which is convenient but porous, into one that resists the attacks that actually happen to small teams. Revisit the checklist whenever you add a new service, because each new container is a new chance to reintroduce an old mistake.

Frequently Asked Questions

Q: Is Docker secure by default?

A: Reasonably, but not fully. The defaults prioritise convenience, and the gaps — root users, the socket, unpinned images — are exactly what attackers look for.

Q: Do I need to scan images if I use official images?

A: Yes. Official images contain vulnerabilities too, and they change over time. Scan on every build and fail on critical issues.

Q: What is the single most important Docker security step?

A: Do not run containers as root. It is one line in the Dockerfile, and it removes the worst outcome of a container escape.