Container and Docker Security

Harden Your Dockerfile

The Dockerfile is where container security starts. Every decision you make here determines the attack surface of every container that image ever runs. ### Use Minimal Base Images The more packages in a base image, the more potential vulnerabilities. A full Ubuntu image comes with hundreds of packages — cron, SSH, compilers, debugging tools — that your application almost certainly never uses. Each is a potential vulnerability vector. ```dockerfile # Bad — 880MB image, hundreds of packages, many CVEs FROM ubuntu:latest RUN apt-get install -y python3 python3-pip COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["python3", "app.py"] # Better — Alpine, ~5MB base, minimal packages FROM python:3.11-alpine RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python3", "app.py"] # Best — Distroless, no shell, no package manager, minimal CVEs FROM python:3.11-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --target /app/packages -r requirements.txt COPY . . FROM gcr.io/distroless/python3 COPY --from=builder /app /app WORKDIR /app CMD ["app.py"] ``` Distroless images from Google contain only the application runtime and its dependencies. No shell, no package manager, no cron, no utilities. If an attacker gains code execution inside a distroless container, they cannot spawn a shell to explore the system. The attack surface is as small as it can be. A comparison of real-world size and CVE counts: | Base Image | Size | Typical CVEs | |:-----------|:-----|:-------------| | ubuntu:latest | 80MB | 100+ | | python:3.11 | 900MB | 100+ | | python:3.11-slim | 130MB | 30-50 | | python:3.11-alpine | 50MB | 5-15 | | distroless/python3 | 50MB | 0-5 | ### Multi-Stage Builds — Never Ship Build Tools Multi-stage builds solve a critical problem: the tools you need to compile and build your application should never be in your production image. ```dockerfile # Stage 1: Builder — has all build tools, compilers, dev dependencies FROM node:18 AS builder WORKDIR /app COPY package*.json ./ RUN npm ci # Installs ALL dependencies including devDependencies COPY . . RUN npm run build # Compiles TypeScript, bundles assets, etc. # Stage 2: Production — only the runtime, nothing to compile with FROM node:18-alpine AS production WORKDIR /app COPY package*.json ./ RUN npm ci --only=production # Only production dependencies COPY --from=builder /app/dist ./dist # Only compiled output # Create non-root user RUN addgroup -S appgroup && adduser -S appuser -G appgroup USER appuser EXPOSE 3000 CMD ["node", "dist/server.js"] ``` The production image has no source code, no TypeScript compiler, no test frameworks, no development dependencies. If an attacker compromises the running container, they cannot easily understand what the application does or modify it. ### Never Run as Root By default, most containers run as root. If an attacker gets code execution inside that container, they have root privileges — they can read any file, write to any directory, install malware, and in many configurations, escape to the host. Running as a non-root user is the single most impactful change you can make to container security: ```dockerfile FROM python:3.11-alpine # Create a non-root user and group RUN addgroup -S appgroup && adduser -S appuser -G appgroup WORKDIR /app # Install dependencies as root (before switching users) COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # Copy application files, owned by non-root user COPY --chown=appuser:appgroup . . # Switch to non-root user USER appuser # Non-privileged port (applications must use ports > 1024) EXPOSE 8080 CMD ["python3", "app.py"] ``` For applications that need to listen on port 80 or 443 but run as non-root: configure a reverse proxy (nginx, Traefik) in front of your container, or use Kubernetes services to map port 80 to container port 8080. ### Pin Specific Versions — Never Use `latest` ```dockerfile # Dangerous — no guarantee of reproducibility, could introduce vulnerabilities FROM python:latest FROM node:latest # Safe — exact version, predictable, scannable FROM python:3.11.7-slim FROM node:18.19.1-alpine3.19 # Even better — pin to digest (immutable, cannot be changed by publisher) FROM python:3.11.7-slim@sha256:3d6a6c0e6e1b6e5e0a5b... ``` When you pin to a digest, you are guaranteed to always get exactly the same image — even if the publisher updates the tag. Your build is reproducible and auditable. ### Use .dockerignore ``` # .dockerignore — prevent sensitive files entering the build context .git .gitignore *.log .env .env.* secrets/ *.pem *.key node_modules/ __pycache__/ *.pyc .pytest_cache/ tests/ docs/ README.md Dockerfile .dockerignore ``` Files in the build context are sent to the Docker daemon. Anything not in .dockerignore could potentially end up in your image. A `.env` file with database credentials accidentally copied into a layer is a secret leakage waiting to be discovered. ### Use COPY, Not ADD ```dockerfile # ADD can fetch remote URLs and auto-extract archives — potential for abuse ADD http://example.com/file.tar.gz /tmp/ # Never do this # COPY is explicit and predictable COPY src/ /app/src/ COPY requirements.txt /app/ ``` ---