Docker Security: Hardening Your Container Deployments

Containers provide process isolation, not security isolation. A misconfigured Docker deployment can expose your host system, leak secrets, and provide attackers with lateral movement opportunities. This guide covers practical hardening techniques that reduce the attack surface of containerized applications without adding operational complexity.

Minimal Base Images

Every package in your base image is a potential vulnerability. Standard images like ubuntu:22.04 or python:3.12 include shells, package managers, and system utilities that your application never uses but an attacker would find convenient.

Distroless images from Google contain only your application and its runtime dependencies:

# Build stage
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt --target /app/deps
COPY . .

# Runtime stage - distroless has no shell, no package manager
FROM gcr.io/distroless/python3-debian12
WORKDIR /app
COPY --from=builder /app /app
ENV PYTHONPATH=/app/deps
CMD ["main.py"]

Alpine-based images offer a middle ground: small size with a package manager available for installing system dependencies. Be aware that Alpine uses musl libc, which can cause compatibility issues with some Python packages that expect glibc.

For the most restrictive option, scratch images contain nothing at all, suitable for statically compiled Go or Rust binaries:

FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /server

FROM scratch
COPY --from=builder /server /server
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
ENTRYPOINT ["/server"]

Running as Non-Root

By default, containers run as root. If an attacker escapes the container, they have root privileges on the host. Always specify a non-root user:

FROM node:20-slim

RUN groupadd -r appuser && useradd -r -g appuser -d /app appuser
WORKDIR /app
COPY --chown=appuser:appuser . .
RUN npm ci --production

USER appuser
CMD ["node", "server.js"]

Verify your containers actually run as non-root:

docker run --rm your-image id
# Should output: uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)

Drop Linux capabilities that your application doesn't need:

# docker-compose.yml
services:
  api:
    image: your-api
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # Only if binding to ports below 1024
    security_opt:
      - no-new-privileges:true

Image Scanning

Integrate vulnerability scanning into your CI pipeline. Images with known CVEs should not reach production.

Trivy scans images, filesystems, and IaC configurations:

# Scan an image and fail on high/critical vulnerabilities
trivy image --severity HIGH,CRITICAL --exit-code 1 your-registry/your-image:latest

# Scan a Dockerfile for misconfigurations
trivy config --severity HIGH,CRITICAL Dockerfile

In CI (GitHub Actions):

- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ${{ env.IMAGE_NAME }}
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'HIGH,CRITICAL'

- name: Upload scan results
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: 'trivy-results.sarif'

Scan both your application images and your base images. A clean application built on a vulnerable base image is still vulnerable.

Secrets Management

Never bake secrets into images. They persist in image layers even if you delete them in a later step.

# WRONG: secret exists in image history
COPY .env /app/.env
RUN source /app/.env && npm run migrate
RUN rm /app/.env  # Still in the layer cache

# RIGHT: use build-time secrets (BuildKit)
RUN --mount=type=secret,id=db_password \
    DB_PASSWORD=$(cat /run/secrets/db_password) npm run migrate

Build with secrets:

docker build --secret id=db_password,src=./db_password.txt -t myapp .

At runtime, use your orchestrator's secrets management:

# Docker Compose with secrets
services:
  api:
    image: your-api
    secrets:
      - db_password
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password

secrets:
  db_password:
    external: true  # Managed outside Compose

For Kubernetes, use external secret operators (AWS Secrets Manager, HashiCorp Vault) rather than native Kubernetes secrets, which are only base64-encoded and stored in etcd.

Read-Only Filesystems

If your application doesn't need to write to the filesystem, make it read-only. This prevents attackers from writing malware, modifying configurations, or creating persistence mechanisms.

services:
  api:
    image: your-api
    read_only: true
    tmpfs:
      - /tmp:size=100M  # Writeable temp directory with size limit
      - /var/run         # For PID files if needed

Applications that write logs to files need adjustment. Redirect logs to stdout/stderr instead, which Docker captures automatically. If the application requires writeable directories, mount them as tmpfs with size limits.

Network Policies

By default, all containers on the same Docker network can communicate freely. Restrict inter-container traffic to only what's necessary.

services:
  frontend:
    networks:
      - frontend-net

  api:
    networks:
      - frontend-net
      - backend-net

  database:
    networks:
      - backend-net

networks:
  frontend-net:
    driver: bridge
  backend-net:
    driver: bridge
    internal: true  # No external access

In this configuration, the frontend can reach the API, and the API can reach the database, but the frontend cannot directly access the database. The internal: true flag on backend-net prevents any container on that network from reaching the internet.

Docker Content Trust

Docker Content Trust (DCT) ensures that you pull only signed images. When enabled, Docker refuses to pull, run, or build with unsigned images.

export DOCKER_CONTENT_TRUST=1

# Sign and push an image
docker trust sign your-registry/your-image:latest

# Verify signatures
docker trust inspect your-registry/your-image:latest

In CI environments, enable DCT and verify that your base images are signed. This prevents supply chain attacks where a compromised registry serves malicious images.

Runtime Security Checklist

Combine these techniques for defense in depth:

• Base image: Use distroless or minimal images. Rebuild regularly to pick up security patches.
• User: Run as non-root with no-new-privileges.
• Capabilities: Drop all, add back only what's needed.
• Filesystem: Read-only where possible, tmpfs with size limits where writes are necessary.
• Network: Isolate services on separate networks. Use internal networks for backend services.
• Secrets: Never in images. Use BuildKit secrets for build time, orchestrator secrets for runtime.
• Scanning: Automated in CI, blocking on high and critical vulnerabilities.
• Signing: Enable DCT for production deployments.

Each layer limits what an attacker can accomplish after gaining an initial foothold. No single measure is sufficient, but together they make container exploitation significantly harder.