Docker Socket Mounts — Why Attackers Get Root in 3 Minutes

Docker containers share the host kernel. A misconfigured container can escape its namespace, read host secrets, or pivot laterally across your cluster. The attack surface spans the image build pipeline, the runtime configuration, the network, the daemon itself, and your secrets management. Miss one layer and the rest does not matter.

Docker's defaults are built for developer convenience, not production hardening. Containers run as root by default. The seccomp profile blocks ~44 of 300+ syscalls but allows the rest. The daemon socket has no authentication by default. Understanding these defaults and how to override them is the foundation of Docker security.

Common misconceptions: containers are not VMs (they share the kernel, so kernel vulnerabilities affect all containers), --privileged is not 'a little extra access' (it disables all isolation), and deleting a secret from a Dockerfile layer does not remove it from the image (layers are additive). Every one of these misconceptions has caused a production breach.

Non-Root Containers — The Single Most Important Security Practice

Docker containers run as root by default. This means the application process inside the container has UID 0 — the same UID as root on the host. If the container's namespace isolation is broken (via a kernel vulnerability), the attacker gains root access to the host.

Running as a non-root user does not prevent container escape, but it limits the damage. A process running as UID 1000 inside the container, even after escaping the namespace, runs as UID 1000 on the host — an unprivileged user who cannot modify system files, install packages, or access other users' data.

The USER instruction must come before CMD/ENTRYPOINT. Any RUN instructions after USER execute as the non-root user, which may cause permission errors for operations that require root (apt-get install, chown). The common pattern is to perform all root operations first, then switch to the non-root user at the end.

Failure scenario — root container exploited via RCE: A web application container running as root had an RCE vulnerability in its image upload endpoint. The attacker uploaded a webshell and gained shell access as root inside the container. Because the container ran as root, the attacker could read /etc/shadow (if mounted), install tools (curl, ncat), and attempt container escape. If the container had run as a non-root user, the attacker would have been UID 1000 — unable to install packages, read protected files, or escalate privileges on the host.

# ── Secure Dockerfile: non-root user, minimal base, no secrets ──
FROM python:3.12-slim-bookworm

WORKDIR /app

# All root operations first
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Create non-root user
RUN groupadd --gid 1000 appgroup && \
    useradd --uid 1000 --gid appgroup --create-home appuser

# Copy application code and set ownership
COPY --chown=appuser:appgroup . .

# Switch to non-root user — everything after this runs as appuser
USER appuser

EXPOSE 8000

CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Image Scanning and Supply Chain Security

Every dependency in your Docker image is an attack surface. The base OS packages, the runtime (Python, Node, Java), the application dependencies (pip, npm, Maven packages) — each can contain known CVEs. Image scanning identifies these vulnerabilities before they reach production.

Scanning tools: - Trivy: open-source, fast, scans OS packages and language dependencies. Integrates with CI/CD. - Grype: open-source, Syft-based, good for SBOM generation. - Docker Scout: Docker's built-in scanner, available in Docker Desktop and Docker Hub. - Snyk Container: commercial, deep integration with CI/CD and container registries.

When to scan: - In CI/CD: scan every image build. Fail the build on critical CVEs. - In the registry: scan on push. Block pulls of images with critical CVEs. - In production: scan running images periodically. Alert on newly discovered CVEs.

Supply chain attacks: Beyond CVEs, consider supply chain attacks — malicious packages injected into public registries. Mitigate with: - Image signing (Docker Content Trust, cosign) - SBOM (Software Bill of Materials) generation - Base image pinning to specific digests - Private registries for internal images

SBOM generation: An SBOM lists every package in your image with its version. It is required for compliance (SBOM Executive Order, SOC 2) and enables rapid response when a new CVE is disclosed — you can query your SBOM database to find all affected images without rescanning.

#!/bin/bash
# Image scanning and supply chain security

# ── Scan with Trivy ───────────────────────────────────────────────
# Install: curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

# Scan a local image for critical and high CVEs
trivy image --severity CRITICAL,HIGH --exit-code 1 io.thecodeforge/secure-app:v1
# --exit-code 1 returns non-zero if vulnerabilities are found (fails CI)

# Scan with JSON output for CI integration
trivy image --format json --output trivy-report.json io.thecodeforge/secure-app:v1

# ── Generate SBOM with Syft ───────────────────────────────────────
# Install: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

syft io.thecodeforge/secure-app:v1 -o spdx-json > sbom.spdx.json
# SBOM can be queried later: 'which images contain openssl 3.0.2?'

# ── Sign image with cosign ────────────────────────────────────────
# Install: go install github.com/sigstore/cosign/v2/cmd/cosign@latest

# Generate a key pair (once)
cosign generate-key-pair

# Sign the image
cosign sign --key cosign.key io.thecodeforge/secure-app:v1

# Verify the signature
cosign verify --key cosign.pub io.thecodeforge/secure-app:v1

# ── CI/CD integration example (GitHub Actions) ────────────────────
# .github/workflows/docker-security.yml
# - name: Scan image
#   run: trivy image --severity CRITICAL,HIGH --exit-code 1 $IMAGE
# - name: Generate SBOM
#   run: syft $IMAGE -o spdx-json > sbom.spdx.json
# - name: Sign image
#   run: cosign sign --key env://COSIGN_PRIVATE_KEY $IMAGE

Secrets Management — Never Bake Secrets Into Images

Secrets (API keys, database passwords, TLS certificates) must never be baked into Docker image layers. Three exposure vectors make this critical:

Vector 1: ENV in Dockerfile. ENV SECRET_KEY=abc123 is visible in docker inspect, docker history, and every container derived from the image. Anyone with image pull access can extract the secret.

Vector 2: ARG in Dockerfile. ARG is build-time only, but it is visible in docker history. If used in a RUN instruction that writes to a file, the secret ends up in that layer.

Vector 3: COPY secrets into the image. COPY .env /app/.env bakes the entire .env file into a layer. Even if a later RUN rm /app/.env removes it, the file still exists in the earlier layer — layers are additive.

The right patterns: - Build-time secrets: Use BuildKit --mount=type=secret. The secret is available during the build but never written to any layer. - Runtime secrets: Use Docker secrets (Swarm), Kubernetes secrets, or mount a tmpfs volume with the secret file. - Environment variables: Acceptable for non-sensitive config. Never for secrets.

Docker Content Trust (DCT): DCT uses digital signatures to verify that an image has not been tampered with. When DOCKER_CONTENT_TRUST=1 is set, Docker only pulls signed images. This prevents supply chain attacks where a malicious image is pushed to a registry with the same tag as a legitimate image.

# ── Safe secrets handling with BuildKit ──────────────────────────
# syntax=docker/dockerfile:1
# Requires BuildKit: DOCKER_BUILDKIT=1 docker build ...

FROM python:3.12-slim-bookworm

WORKDIR /app

COPY requirements.txt .

# WRONG: This bakes the secret into the image layer
# RUN pip install --no-cache-dir -r requirements.txt --index-url https://user:password@private.pypi/simple

# RIGHT: Mount the secret as a file during build, never stored in a layer
RUN --mount=type=secret,id=pypi_token \
    pip install --no-cache-dir -r requirements.txt \
    --index-url https://$(cat /run/secrets/pypi_token)@private.pypi/simple

# Build command:
# DOCKER_BUILDKIT=1 docker build \
#   --secret id=pypi_token,src=$HOME/.pypi_token \
#   -t io.thecodeforge/app:v1 .

COPY . .

RUN useradd --create-home appuser
USER appuser

CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Runtime Hardening — Seccomp, AppArmor, Read-Only Filesystems, and Capabilities

Runtime hardening reduces the attack surface of a running container by restricting what the container process can do. Four mechanisms work together:

1. seccomp (Secure Computing Mode): Filters syscalls at the kernel level. Docker's default seccomp profile blocks ~44 dangerous syscalls (mount, reboot, kexec_load) but allows the rest. Custom profiles can block more syscalls for defense in depth.

2. AppArmor / SELinux: Mandatory Access Control (MAC) frameworks that restrict file access, network access, and capability usage at the process level. AppArmor is default on Ubuntu/Debian. SELinux is default on RHEL/CentOS.

3. Read-only filesystem: --read-only makes the container's root filesystem read-only. The application can only write to tmpfs mounts. This prevents an attacker from installing tools, modifying application code, or writing a backdoor to the filesystem.

4. Linux capabilities: Fine-grained privilege control. Instead of granting full root (all capabilities), grant only what is needed. --cap-drop=ALL removes all capabilities. --cap-add=NET_BIND_SERVICE adds back only the ability to bind to privileged ports.

Performance impact: seccomp adds <1% CPU overhead per syscall (the kernel checks the filter before executing the syscall). AppArmor adds similar negligible overhead. Read-only filesystems can actually improve performance by preventing unnecessary writes. There is no performance reason to skip these security measures.

Failure scenario — writable filesystem exploited: An attacker gained RCE in a web application container through a deserialization vulnerability. Because the filesystem was writable, the attacker wrote a PHP webshell to /app/uploads/shell.php and used it for persistent access. With --read-only, the write would have failed, and the attacker would have been limited to in-memory exploitation (much harder).

#!/bin/bash
# Runtime hardening flags for production containers

# ── Full hardened container run command ────────────────────────────
docker run -d \
  --name secure-api \
  \
  # Non-root user (from Dockerfile USER instruction)
  \
  # Read-only root filesystem
  --read-only \
  \
  # Writable tmpfs for temp files
  --tmpfs /tmp:size=64m,noexec,nosuid \
  --tmpfs /var/run:size=16m,noexec,nosuid \
  \
  # Drop ALL capabilities, add back only what's needed
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  \
  # Prevent privilege escalation via setuid binaries
  --security-opt=no-new-privileges:true \
  \
  # Use custom seccomp profile (optional — default is good enough for most)
  --security-opt=seccomp=/etc/docker/seccomp-profile.json \
  \
  # Use AppArmor profile (Ubuntu/Debian)
  --security-opt=apparmor=docker-default \
  \
  # Resource limits
  --memory=512m \
  --cpus=1.0 \
  --pids-limit=256 \
  \
  # Disable inter-container communication
  --icc=false \
  \
  # Network
  --network app-network \
  -p 8000:8000 \
  \
  io.thecodeforge/secure-app:v1

# ── Verify capabilities ───────────────────────────────────────────
docker exec secure-api cat /proc/1/status | grep Cap
# CapInh: 0000000000000000  (inherited — should be 0)
# CapPrm: 0000000000000400  (permitted — only NET_BIND_SERVICE)
# CapEff: 0000000000000400  (effective — only NET_BIND_SERVICE)
# CapBnd: 0000000000000400  (bounding — only NET_BIND_SERVICE)

# ── Verify seccomp profile ────────────────────────────────────────
docker exec secure-api grep Seccomp /proc/1/status
# Seccomp: 2  (filter mode — seccomp profile is active)

# ── Verify read-only filesystem ───────────────────────────────────
docker exec secure-api touch /test-file 2>&1
# touch: cannot touch '/test-file': Read-only file system

Docker Daemon Security — Protecting the Control Plane

The Docker daemon (dockerd) is the control plane for all container operations. If the daemon is compromised, every container on the host is compromised. Three critical daemon security practices:

1. Never expose the daemon socket without TLS. The default daemon listens on a Unix socket (/var/run/docker.sock) which requires local access. If configured to listen on TCP (port 2375), it accepts unauthenticated connections from the network. Anyone who can reach port 2375 can create, stop, and delete containers — effectively root access to the host.

2. Enable TLS with client certificate authentication. If remote daemon access is required (for CI/CD, monitoring), configure TLS on port 2376 with client certificates. Only clients with a valid certificate can connect. This is the equivalent of SSH key authentication for the Docker daemon.

3. Enable user namespace remapping. By default, UID 0 inside the container maps to UID 0 on the host. User namespace remapping maps container UIDs to unprivileged host UIDs (e.g., container UID 0 -> host UID 100000). This means even a container escape results in an unprivileged host user, not root.

4. Enable live-restore. If the Docker daemon restarts, running containers are killed by default. live-restore=true keeps containers running during daemon restarts, improving availability. This also means a daemon crash does not take down your production workloads.

5. Disable the legacy registry (v1). Docker Registry v1 is deprecated and has known security issues. Ensure the daemon only interacts with v2 registries.

{
  "userns-remap": "default",
  "live-restore": true,
  "no-new-privileges": true,
  "userland-proxy": false,
  "icc": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "storage-driver": "overlay2",
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 65536,
      "Soft": 65536
    }
  },
  "tls": true,
  "tlscacert": "/etc/docker/tls/ca.pem",
  "tlscert": "/etc/docker/tls/server-cert.pem",
  "tlskey": "/etc/docker/tls/server-key.pem",
  "tlsverify": true,
  "hosts": [
    "unix:///var/run/docker.sock",
    "tcp://0.0.0.0:2376"
  ]
}