Docker Security

When to use

Reduce attack surface of containers and avoid common pitfalls (root user, copying secrets, exposed ports).

Analogy

container security is leaving your house: don’t leave windows open, keys on the table, alarm off.

Data-flow diagram

  Risks and mitigations:
    1. running as root          -> USER 1000
    2. secrets in layers        -> BuildKit secrets / runtime env
    3. vulnerable base images    -> distroless / alpine; Trivy scan
    4. privileged mode + mounts -> CAP_DROP ALL; --read-only fs
    5. publishing too many ports -> publish only what you need

Deep explanation

(1) Run as a non-root user (USER 1000). (2) Use minimal base images (distroless, alpine, scratch for static binaries). (3) Drop Linux capabilities (--cap-drop=ALL then add back only what’s needed). (4) Make filesystem read-only (--read-only). (5) Limit resources (--memory, --cpus). (6) Scan images regularly (Trivy, Clair, Snyk). (7) Multi-stage builds. (8) Sign images (Docker Content Trust / sigstore).

Examples

Example 1

FROM python:3.12-slim
RUN useradd --create-home --uid 1000 app
WORKDIR /home/app
COPY --chown=app:app . .
USER app
CMD ["python", "app.py"]

creates non-root user, copies code with correct ownership, switches to it.

Example 2

docker run --cap-drop=ALL --read-only \
  --tmpfs /tmp --tmpfs /run \
  --memory 256m --cpus 0.5 myapp:1.0.0

drops all Linux capabilities, makes root fs read-only; mounts writable tmpfs.

Example 3

trivy image --severity HIGH,CRITICAL myapp:1.0.0
# fail CI based on findings count

scans the image for known CVEs; integrate into CI to fail builds with critical CVEs.

Common mistake

Running as root. Adding secrets to ENV (visible in docker inspect). Using --privileged (huge attack surface). Leaving SSH server in the image.

Key takeaway

non-root, minimal base, read-only FS, dropped caps, scanned regularly, signed. NEVER bake secrets into layers.

Production Failure Playbook

Failure scenario 1: container-escape-via-privileged

• Symptom: a compromised application container was used to escape into the host.
• Detection: host audit; security scanner alerts.
• Root cause: developer started the container with --privileged.
• Mitigation: incident response; rotate any host credentials; restart host affected.
• Prevention: policy: no --privileged in production; OPA / admission controller rejects it.

Failure scenario 2: prod-password-in-env

• Symptom: docker inspect revealed the prod DATABASE_URL including password; logs included the URL.
• Detection: internal pentest; trivy found env var with secret pattern.
• Root cause: developer put ENV DATABASE_URL=postgres://user:prod123@db/app in the Dockerfile.
• Mitigation: rotate password; remove from image; use docker secrets / k8s secret API at runtime.
• Prevention: BuildKit secret mounts at build time; runtime secrets from Vault / k8s secret.