⏱️4 min read · 768 words
Docker security is often an afterthought until a breach occurs. In 2026, running containers as root, using unscanned images, and exposing unnecessary ports are among the most common production security mistakes. This guide covers Docker security hardening from Dockerfile to runtime.
📋 Table of Contents
The Top Docker Security Risks
- Running containers as root user
- Using outdated base images with known CVEs
- Hardcoding secrets in images or compose files
- Exposing the Docker daemon socket
- Using latest tag (unpinned versions)
- Overly permissive capabilities
- No resource limits (CPU/memory)
Secure Dockerfile Patterns
# SECURE: Multi-stage, minimal base, non-root user
FROM python:3.12-slim AS builder
# Pin all package versions
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt && pip install pip-audit && pip-audit # fail build if known CVEs
FROM gcr.io/distroless/python3-debian12 # minimal, no shell
# OR use: python:3.12-slim (if you need shell for debugging)
# Never run as root
RUN groupadd -r appgroup && useradd -r -g appgroup -u 1001 appuser
WORKDIR /app
# Copy only what's needed
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
COPY --chown=appuser:appgroup src/ .
# Declare what's sensitive (documentation, not actual protection)
# NEVER put actual secrets here
ENV APP_ENV=production
USER appuser # non-root!
# Make filesystem read-only (app should write to /tmp or mounted volumes)
VOLUME ["/tmp", "/var/run"]
EXPOSE 8000
# Health check
HEALTHCHECK --interval=30s --timeout=10s --retries=3 CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
Secrets Management
# WRONG: secrets in compose file
services:
app:
environment:
DB_PASSWORD: mysecretpassword # visible in 'docker inspect'!
# CORRECT: use Docker secrets or env file
services:
app:
environment:
DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
secrets:
db_password:
file: ./secrets/db_password.txt # .gitignore this!
# OR for Docker Swarm:
# external: true
# Never embed secrets in images!
# Bad: COPY .env /app/.env
# Bad: ENV DB_PASSWORD=secret
# Good: pass at runtime
docker run -e DB_PASSWORD="$(cat ~/.secrets/db_password)" myapp
# Better: use a secret manager
# AWS Secrets Manager, HashiCorp Vault, Azure Key Vault
# Check for leaked secrets
docker history --no-trunc myimage:latest | grep -i secret
docker inspect myimage | grep -i password
Runtime Security
# compose.yaml — secure runtime config
services:
app:
image: myapp:1.2.3 # pin exact version!
read_only: true # read-only root filesystem
tmpfs:
- /tmp:size=100m,noexec # writable temp, no execution
security_opt:
- no-new-privileges:true # prevent privilege escalation
cap_drop:
- ALL # drop all capabilities
cap_add:
- NET_BIND_SERVICE # add only what's needed
user: "1001:1001" # non-root UID:GID
ulimits:
nofile:
soft: 1024
hard: 2048
mem_limit: 512m
cpus: '1.0'
networks:
- backend # isolated network
# Never expose Docker socket:
# volumes:
# - /var/run/docker.sock:/var/run/docker.sock # DANGEROUS!
networks:
backend:
driver: bridge
internal: true # no external access
Image Scanning
# Trivy — fast, free vulnerability scanner
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:latest image --severity HIGH,CRITICAL myapp:latest
# Docker Scout (built into Docker Desktop 2024+)
docker scout cves myapp:latest
docker scout recommendations myapp:latest
# Snyk
snyk container test myapp:latest
# In CI/CD pipeline
name: Security Scan
on: [push]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
format: sarif
exit-code: '1' # fail on HIGH/CRITICAL
severity: 'HIGH,CRITICAL'
Network Security
# Use user-defined networks (not default bridge)
docker network create --driver bridge --subnet 172.20.0.0/16 appnet
# Verify containers can't reach each other on default network
# By default, containers on same network CAN reach each other
# Use 'internal: true' to prevent external access
# Limit exposed ports
# WRONG: 0.0.0.0:5432:5432 (exposed to all interfaces)
# CORRECT: 127.0.0.1:5432:5432 (localhost only)
# Or don't expose at all — access via internal network name
Docker Security Checklist
- Non-root user in Dockerfile
- Pinned image versions (no :latest)
- Multi-stage build (minimal final image)
- No secrets in images or compose environment
- Read-only root filesystem
- Drop all capabilities, add only required
- Resource limits set (memory/CPU)
- Image scanned with Trivy or Snyk before deploy
- Docker socket not mounted in containers
- Isolated networks per service tier
- Secrets via Docker secrets or vault (never env vars)
Docker security in 2026: the threat model is real — container escapes, secret leaks, and privilege escalation are documented attack vectors. Implement non-root users, read-only filesystems, image scanning in CI, and proper secret management before going to production. The effort is minimal compared to the risk of a breach.
📚 You might also like
🔗 Share this article




✍️ Leave a Comment