Docker Security Hardening: Images, Runtime, and Secrets

The Container Security Misconception

Containers are not a security boundary. A privileged container, a container with host network, or a container with a mounted docker socket is functionally equivalent to root on the host.

Dockerfile Best Practices

FROM python:3.12-slim@sha256:abc123...

RUN useradd -m -u 1000 appuser
USER appuser

RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
  && rm -rf /var/lib/apt/lists/*

HEALTHCHECK --interval=30s CMD curl -f http://localhost:8080/health || exit 1

Runtime Hardening

docker run \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  --security-opt no-new-privileges \
  --memory 512m \
  --cpus 1.0 \
  --user 1000:1000 \
  myapp:1.2.3

Secrets: Never Environment Variables

# BAD
docker run -e DB_PASSWORD=secret myapp

# GOOD — Docker secrets (Swarm)
docker secret create db_password ./db_password.txt

Image Scanning

trivy image myapp:1.2.3 --severity HIGH,CRITICAL
trivy image --exit-code 1 --severity CRITICAL myapp:${TAG}

Defensive Takeaways

• Never mount the Docker socket into a container
• Scan images in CI and block on CRITICAL CVEs
• Use image digests to prevent tag confusion attacks
• Audit docker inspect on production containers for privileged or host mounts