Docker Security — 安全加固与防护

Comprehensive guidance for securing Docker across the full lifecycle.

When to Use

ALWAYS use this skill when the user mentions:

• "docker 安全", "镜像安全", "container security"
• "非root运行", "rootless", "least privilege"
• "seccomp", "AppArmor", "SELinux"
• "Docker Bench", "CIS"
• "secrets management", "密钥管理"
• "image signing", "content trust"

Security Model — Layered Defense

Layer 1: Image Security    — minimal base, non-root, pinned versions
Layer 2: Build Security    — secret injection, noCOPY secrets
Layer 3: Runtime Security  — capabilities, seccomp, AppArmor, read-only
Layer 4: Registry Security — content trust, signing, vulnerability scan
Layer 5: Host Security     — Docker Bench, CIS, user namespace

Image Security Checklist

Secure Dockerfile

FROM alpine:3.20
RUN apk add --no-cache ca-certificates
RUN addgroup -S app && adduser -S -G app app
COPY --chown=app:app ./app /app
WORKDIR /app
USER app
CMD ["./server"]

Runtime Security

Capabilities (Least Privilege)

# Drop ALL capabilities, add only what's needed
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

# Common needed caps: NET_BIND_SERVICE, CHOWN, DAC_OVERRIDE
# NEVER: --privileged (gives full host access)

Read-Only Root Filesystem

# Prevents container from writing anywhere (except volumes/tmpfs)
docker run --read-only --tmpfs /tmp --tmpfs /run nginx

Seccomp Profile

# Custom seccomp profile (block syscalls)
docker run --security-opt seccomp=profile.json app

# Unconfined (NEVER in production)
docker run --security-opt seccomp=unconfined app

No New Privileges

# Prevent privilege escalation via setuid binaries
docker run --security-opt no-new-privileges app

Secrets Management

BuildKit Secrets (build-time)

# syntax=docker/dockerfile:1
FROM alpine
RUN --mount=type=secret,id=aws_creds \
  AWS_ACCESS_KEY_ID=$(cat /run/secrets/aws_creds) \
  aws s3 cp s3://bucket/file .

docker build --secret id=aws_creds,src=$HOME/.aws/credentials -t app .

Docker Secrets (Swarm runtime)

echo "mysecretpassword" | docker secret create db_password -
docker service create --secret db_password postgres

Docker Bench Security Audit

docker run --rm \
  --pid host --network host \
  -v /var/run/docker.sock:/var/run/docker.sock \
  docker/docker-bench-security

Workflow — 安全加固流程

Step 1: 镜像安全: docker scout cves <image> 扫描漏洞 → 更新基础镜像/依赖 Step 2: Dockerfile 加固: USER 非 root、COPY 优于 ADD、固定 digest Step 3: 运行时安全: --read-only、--cap-drop=ALL、--security-opt no-new-privileges Step 4: 审计检查: docker run --rm docker/docker-bench-security 逐条修复 Step 5: CI 门禁: Scout 策略阻断 critical/high CVE 合并

Gotchas — Common Pitfalls

• --privileged flag: Gives full host access. Never use in production. → Recovery: Use specific --cap-add=NETBINDSERVICE instead; audit with docker inspect --format='{{.HostConfig.Privileged}}'.
• API keys in Dockerfile: ENV APIKEY=xxx is baked into image layers forever. → Recovery: Use runtime injection: docker run -e APIKEY=$KEY or BuildKit --mount=type=secret.
• Root container: Default user is root. Escaping the container means root on the host. → Recovery: Always USER 1000:1000 in Dockerfile; verify with docker exec myapp whoami.
• Docker socket mount: -v /var/run/docker.sock gives container control over ALL containers. → Recovery: Use Docker API with TLS auth instead of socket mount; never mount socket in production.
• Ignoring CVE remediation: Running docker scout but never fixing findings. → Recovery: Set CI policy to block critical/high CVEs; update base images regularly.

Boundary — 能力边界（适用与不适用场景）

When NOT to Use This Skill

Security & Stability

• All security practices are based on CIS Docker Benchmark and Docker official security guidance.
• Run Docker Bench Security regularly in CI/CD to detect configuration drift.
• Subscribe to Docker security advisories for CVE notifications.
• No executable scripts bundled. Guidance only.

📚 官方文档参考

🧭 Docker Skills Journey

📍 You are here: docker-security — 安全加固

← Previous: docker-build | → Next: docker-scout / docker-cicd