Container Security

Attack surface map

flowchart TB
  subgraph external [External threats]
    REG[Compromised registry image]
    API[Exposed container API]
  end
  subgraph container [Container boundary]
    APP[Application vulnerability]
    ESC[Kernel escape / breakout]
    PRIV[Privilege escalation inside container]
  end
  subgraph host [Host impact]
    SOCK[docker.sock access]
    HOST[Host filesystem / processes]
    LAT[Lateral movement to other containers]
  end
  REG --> APP
  API --> APP
  APP --> PRIV
  PRIV --> ESC
  ESC --> HOST
  SOCK --> HOST
  HOST --> LAT

Six threat categories

Trust boundaries

• Image → runtime — treat every pulled image as untrusted until scanned and signed
• Container → host — assume kernel bugs exist; minimize capabilities that amplify exploits
• Container → container — default bridge allows east-west traffic; segment explicitly
• Build → registry — CI runners are high-value targets; isolate builders, rotate credentials

Default: what Docker drops vs keeps

Docker starts from the full capability set, then drops everything not in the allowlist. The default container retains only these capabilities (14 on most kernels):

Dropped by default (never available unless explicitly added):

• CAP_SYS_ADMIN — mount filesystems, load kernel modules, many namespace operations; primary enabler of container escapes
• CAP_NET_ADMIN — configure interfaces, iptables, routing tables
• CAP_SYS_PTRACE — debug/trace any process—read memory of other containers on shared PID namespace
• CAP_SYS_MODULE, CAP_BPF, CAP_PERFMON — kernel introspection and modification

Production pattern: drop all, add minimum

# Web server binding port 80 as non-root
docker run -d \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  --user 1000:1000 \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  -p 8080:80 \
  nginx:alpine

# Inspect effective capabilities
docker inspect --format '{{.HostConfig.CapDrop}} {{.HostConfig.CapAdd}}' mycontainer

The --privileged flag

--privileged grants all capabilities, disables most seccomp restrictions, and gives access to all host devices. It exists for Docker-in-Docker and hardware debugging—not production apps. CIS Docker Benchmark marks privileged containers as a critical failure.

Inspect capabilities with capsh

$ docker run --rm alpine capsh --print
Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,
         cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,
         cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
Bounding set =cap_chown,cap_dac_override,...

$ docker run --rm --cap-drop ALL --cap-add NET_BIND_SERVICE alpine capsh --print
Current: cap_net_bind_service=ep
Bounding set =cap_net_bind_service

Default Docker seccomp profile

Unless overridden, Docker applies the default seccomp profile (shipped as /etc/docker/seccomp.json on Linux or embedded in dockerd). It uses SCMP_ACT_ERRNO to deny dangerous syscalls while allowing normal application behavior.

The full default profile blocks approximately 44 syscalls (plus flag-conditioned rules for clone, socket, and arch_prctl). Architectures may vary slightly.

Custom seccomp JSON

When an application legitimately needs a blocked syscall (rare), create a custom profile that inherits the default and adds explicit allows—never start from an empty allowlist.

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"],
  "syscalls": [
    {
      "names": ["personality"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

# Apply custom profile
docker run --rm --security-opt seccomp=/path/to/custom-seccomp.json myapp

# Verify profile in OCI bundle (running container)
docker inspect --format '{{.HostConfig.SecurityOpt}}' mycontainer

seccomp=unconfined — the danger

--security-opt seccomp=unconfined disables syscall filtering entirely. Combined with any kernel vulnerability, the container has maximum syscall reach. --privileged implies unconfined seccomp. Some legacy apps request unconfined during migration—treat it as technical debt with a sunset date.

AppArmor (Ubuntu, Debian, SUSE)

Docker automatically applies the docker-default AppArmor profile on supported hosts. It restricts mount operations, raw network access, /proc writes, and ptrace across containers.

# Check AppArmor profile on a running container
docker inspect --format '{{.AppArmorProfile}}' mycontainer
# Expected: docker-default (or custom profile name)

# Explicitly set profile
docker run --security-opt apparmor=docker-default nginx:alpine

# Disable AppArmor (DANGEROUS — debugging only)
docker run --security-opt apparmor=unconfined alpine

SELinux (RHEL, Fedora, CentOS)

On SELinux-enforcing hosts, Docker labels containers with container_t (process type) and content with container_file_t. Bind mounts inherit container_file_t or custom labels via :z / :Z volume flags.

# SELinux: private volume label
docker run -v /data/app:/app:Z myapp

# Custom SELinux level (multi-tenant MLS environments)
docker run --security-opt label=level:s0:c100,c200 myapp

# Check process context
docker exec mycontainer cat /proc/1/attr/current

--security-opt reference

Dockerfile: USER instruction

FROM eclipse-temurin:21-jre-alpine

# Create dedicated group and user (UID/GID >= 10000)
RUN addgroup -g 10001 -S appgroup && \
    adduser -u 10001 -S appuser -G appgroup

WORKDIR /app
COPY --chown=appuser:appgroup target/app.jar app.jar

USER 10001:10001
ENTRYPOINT ["java", "-jar", "app.jar"]

Why numeric UID matters

Use numeric UIDs (USER 10001:10001) instead of usernames. The username may not exist in the runtime image (multi-stage builds drop /etc/passwd entries), but the numeric UID always resolves. Kubernetes runAsUser: 10001 matches exactly.

Runtime override: --user

# Override image USER at runtime
docker run --user 10001:10001 myapp

# Verify effective user inside container
docker exec mycontainer id
# uid=10001 gid=10001

chown at build time

Files created by COPY or RUN as root are owned by root. Use COPY --chown=appuser:appgroup or a RUN chown -R before switching USER. Writable paths (logs, caches, temp) must be owned by the runtime user—or mounted via volumes/tmpfs.

Read-only root filesystem + tmpfs

docker run -d \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=128m \
  --tmpfs /var/run:rw,noexec,nosuid,size=16m \
  --user 10001:10001 \
  --cap-drop ALL \
  myapp

--read-only makes the container layer immutable—attackers cannot drop binaries or modify configs. Mount tmpfs for paths the app must write. Use noexec,nosuid mount options to block executed payloads in temp directories.

Why root is still dangerous

• Kernel escape amplification — root + CVE = host root in rootful mode
• Writable application dirs — root can modify binaries, cron, and startup scripts inside the container
• Package managers — apt install in production images adds attack surface at runtime
• Bind mount ownership — root in container may chown host-mounted files if CAP_CHOWN is present
• Compliance — PCI-DSS, SOC2, and CIS benchmarks require non-root containers

Never use ARG or ENV for secrets

# ❌ ANTI-PATTERN — secret persists in image history forever
ARG DB_PASSWORD
ENV DB_PASSWORD=${DB_PASSWORD}
RUN curl -u admin:${DB_PASSWORD} https://internal/api

# Anyone can recover it:
# docker history --no-trunc myapp:latest

BuildKit secret mount (build-time only)

When a build must reach a private registry or API, use BuildKit secret mounts. Secrets are available only during the RUN line—they never commit to a layer.

# syntax=docker/dockerfile:1
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci --omit=dev
COPY . .
RUN npm run build

# Pass secret from file at build time (not stored in image)
DOCKER_BUILDKIT=1 docker build \
  --secret id=npmrc,src=$HOME/.npmrc \
  -t myapp .

Runtime secret delivery

# Docker Compose — Swarm secrets (deployed stack)
services:
  api:
    image: myapp:latest
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true

Rotation

1. Prefer short-lived credentials — Vault dynamic secrets or AWS SM rotation over static files
2. Reload without rebuild — app reads secret file on interval or receives SIGHUP; no image rebuild for rotation
3. Dual-write window — during rotation, accept both old and new credentials for a bounded period
4. Audit access — log every secret read with principal identity; alert on anomalous patterns
5. Revoke on incident — runbook to invalidate tokens, roll pods/containers, and scan registry for leaked layers

Inter-container communication (ICC)

By default, containers on the same bridge can ping each other. Disable ICC on the docker0 bridge when containers do not need direct peer access (legacy standalone Docker hosts):

// /etc/docker/daemon.json
{
  "icc": false
}

In Compose and Swarm, use multiple networks to segment tiers—frontend on web, API on backend, database only attached to backend.

services:
  web:
    networks: [frontend]
  api:
    networks: [frontend, backend]
  db:
    networks: [backend]   # not reachable from web tier

networks:
  frontend:
  backend:
    internal: true       # no external routing

Network segmentation patterns

Bind to loopback, not 0.0.0.0

Applications listening on 0.0.0.0 accept connections from any container on the shared network. Configure apps to bind 127.0.0.1 for admin/metrics endpoints, and expose only through a reverse proxy with authentication. Use -p 127.0.0.1:8080:8080 to limit host-side exposure during local dev.

No privileged or host networking in production

Quick validation commands

# Scan image for CVEs
trivy image --severity HIGH,CRITICAL myapp:latest

# Check image history for leaked secrets
docker history --no-trunc myapp:latest | grep -iE 'password|secret|key|token'

# Verify non-root and security opts at runtime
docker inspect mycontainer --format 'User={{.Config.User}} Privileged={{.HostConfig.Privileged}} ReadonlyRootfs={{.HostConfig.ReadonlyRootfs}} SecurityOpt={{.HostConfig.SecurityOpt}}'

# Lint Dockerfile before build
hadolint Dockerfile