A container is not a virtual machine: it shares the kernel with the host. Run as root, with --privileged or with the Docker socket mounted, a compromised container means root on the server. Isolation is real only if you configure it.
Docker isolates processes with namespaces and cgroups, but the kernel is shared. If the container process runs as root and someone finds a kernel vulnerability or a permissive setting, escaping the container leaves them root on the server. --privileged switches off almost all isolation. Mounting the Docker socket is equivalent: whoever talks to the daemon can start a privileged container with the host's root filesystem mounted. So the image declares an unprivileged user, and the container starts with capabilities dropped and no-new-privileges.
An image based on a full distribution brings hundreds of packages and their vulnerabilities, although the application uses a few libraries. Choose minimal images, alpine, slim or distroless, and build multi-stage so compilers stay in the build stage. Pin the base image by digest rather than by tag, and rebuild when the scanner reports a patch. Scanning runs in CI before the push to the registry; an image with critical vulnerabilities does not reach production. Do not put secrets in the image or run npm or pip in the production container.
| Control | How you apply it | What it prevents |
|---|---|---|
| Non-root user | USER app in the Dockerfile | Root in the container = root on the host after an escape |
| No unneeded capabilities | --cap-drop ALL, --cap-add only what is needed | Escalation through kernel capabilities |
| No new privileges | --security-opt no-new-privileges | Escalation through setuid binaries |
| Read-only filesystem | --read-only, --tmpfs /tmp | Writing backdoors inside the container |
| Docker socket not mounted | No -v /var/run/docker.sock | Full control over the daemon |
| Scanned and pinned images | Trivy in CI, FROM by digest | Known vulnerabilities in production |
FROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts
COPY . .
RUN npm run build && npm prune --omit=dev
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build --chown=node:node /app/dist ./dist
COPY --from=build --chown=node:node /app/node_modules ./node_modules
USER node
HEALTHCHECK CMD wget -qO- http://127.0.0.1:3000/health || exit 1
CMD ["node", "dist/server.js"]docker run -d --name app \
--read-only --tmpfs /tmp \
--cap-drop ALL \
--security-opt no-new-privileges \
--memory 512m --cpus 1 --pids-limit 200 \
--network app-net \
-p 127.0.0.1:3000:3000 \
example.ro/app@sha256:<digest>trivy image --severity HIGH,CRITICAL --exit-code 1 example.ro/app:1.4.0
# The CIS audit is the one exception to the 'never mount the socket' rule: run it once,
# by hand, not as a permanent service. Without the mounts below, CIS sections 1-3
# report wrongly or are skipped. `:ro` on a Unix socket limits nothing.
docker run --rm --net host --pid host --userns host --cap-add audit_control \
-v /var/lib:/var/lib:ro -v /etc:/etc:ro \
-v /usr/bin/containerd:/usr/bin/containerd:ro -v /usr/bin/runc:/usr/bin/runc:ro \
-v /usr/lib/systemd:/usr/lib/systemd:ro \
-v /var/run/docker.sock:/var/run/docker.sock docker/docker-bench-securityThe image ran as root because nobody had added USER. A vulnerability in an image-processing library allowed files to be written anywhere in the container. Switching to the node user and a read-only filesystem confined the next incident to the temporary directory.
A monitoring container had /var/run/docker.sock mounted so it could see the other containers. In effect it was root on a host running ten client sites. It was replaced by a read-only socket proxy, and direct mounting was banned.
With most of them. Limits appear with ports below 1024, which need extra configuration, with some network and storage drivers and with applications that need kernel capabilities. Test in staging; if the application runs, you gain a layer of isolation without changing code.
You do not update inside the container; you rebuild the image. Change the base image digest, run the build and scan in CI again and roll out the new version. Containers are immutable: an apt upgrade inside a running container disappears at the next restart.
No. Every control above applies to plain Docker and to Compose. Kubernetes adds admission policies, managed secrets and network isolation at scale, but also a far bigger configuration surface. Choose it when you need orchestration, not for security in itself.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.