Docker Security Best Practices for Production

Docker Security Starts Before the Container Runs

Too many teams think of Docker security as a runtime problem. It starts earlier than that.

By the time an image reaches production, most of the security posture has already been decided: the base image, included packages, user model, secret handling, startup command, and scan discipline are already baked in.

The container-escape lesson from CVE-2019-5736 in runC still matters because it reminded everyone that containers are isolation boundaries, not magic boxes. If the container is privileged, rootful, oversized, and connected too broadly, the host ends up carrying the risk.

1. Start With a Smaller Base Image

Every extra package is attack surface.

Production guidance:

• Use minimal official or well-maintained base images
• Pin versions and preferably digests
• Prefer distroless or slim images when the application allows it
• Remove build tools from final runtime image

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM gcr.io/distroless/nodejs20-debian12:nonroot
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["dist/server.js"]

2. Do Not Run as Root Unless You Can Defend the Reason

If the process can run as an unprivileged user, make that the default.

Checklist:

• Create a non-root user in the image or use a non-root base image
• Avoid --privileged
• Drop capabilities aggressively
• Make the filesystem read-only when practical

3. Keep Secrets Out of the Image

Still common in audits:

• .env files copied into the image
• secrets passed as build args
• cloud credentials present in a build layer

Better pattern:

• inject secrets at runtime from the orchestrator or secret manager
• keep build layers free of credentials
• scan the repository and image history for leaked values

4. Scan Images and Dockerfiles in CI

You want to catch both vulnerable packages and unsafe build instructions.

Useful checks:

• Trivy or equivalent for image CVEs
• Hadolint for Dockerfile mistakes
• provenance and signing checks for release images

Example CI flow:

1. Lint Dockerfile
2. Build image
3. Scan image
4. Fail on critical findings or policy violations
5. Sign approved artifact

5. Control Runtime Behavior

Production container security is not complete at build time.

At runtime, enforce:

• least-privilege container user
• tight CPU and memory limits
• read-only root filesystem where possible
• restricted outbound network access
• no shell or package manager in the final image unless truly needed

TeamTNT-style attacks against exposed Docker daemons and misconfigured cloud hosts showed how quickly a small runtime mistake becomes cryptocurrency mining, credential theft, or wider cloud abuse.

6. Trust the Registry Less Than You Think

Use approved registries and immutable references.

Production checklist:

• private registry for internal artifacts
• digest pinning instead of mutable tags
• signed images for release workflows
• review of who can publish and overwrite images

7. Build an Incident Plan Around Containers

When a container is suspicious, know what happens next.

Decide in advance:

• who can isolate the workload
• how forensic data is preserved
• how secrets are rotated if the workload handled credentials
• whether the node must be treated as potentially exposed

Containers are disposable. Evidence is not.

Production Docker Checklist

• Minimal, pinned base image
• Non-root user
• No secrets baked into layers
• Dockerfile linting in CI
• Image scanning in CI
• Signed release images
• Read-only runtime where practical
• Resource limits enforced
• Restricted network access
• Incident response procedure documented

Further Reading

• OWASP Docker Security Cheat Sheet
• NIST SP 800-190 Application Container Security Guide
• Docker Build Best Practices
• Sigstore Cosign

Related SecureCodeReviews guides:

• Container Security Hardening Guide
• Docker Security: Scanning, Hardening, and Runtime Protection
• How to Prevent Supply Chain Attacks in CI/CD

The simplest production Docker rule is still the best one: ship less, trust less, and give containers less room to surprise you.