Docker_security
Chapter 12: Docker Security - Container Security Best Practices
Section titled “Chapter 12: Docker Security - Container Security Best Practices”Table of Contents
Section titled “Table of Contents”- Introduction to Container Security
- Why Container Security Matters
- Docker Security Fundamentals
- Container Security Best Practices
- Linux Kernel Security Features
- Docker Content Trust
- Image Scanning and Vulnerability Management
- Secrets Management
- Network Security
- Runtime Security
- Security Scanning Tools
- Security Hardening
- Compliance and Auditing
- Summary
Introduction to Container Security
Section titled “Introduction to Container Security”The Security Challenge
Section titled “The Security Challenge”Container security is a critical aspect of modern DevOps practices. While containers provide isolation, they share the host kernel, making security a shared responsibility.
┌─────────────────────────────────────────────────────────────────────────────┐│ CONTAINER SECURITY CHALLENGES │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Traditional Security vs Container Security ││ ──────────────────────────────────────── ││ ││ Traditional (VMs) Container ││ ┌─────────────────┐ ┌─────────────────┐ ││ │ App 1 │ │ Container 1 │ ││ │ ┌─────────┐ │ │ ┌─────────┐ │ ││ │ │ OS │ │ │ │ App │ │ ││ │ └─────────┘ │ │ └─────────┘ │ ││ └───────┬───────┘ └────────┬────────┘ ││ │ │ ││ ┌───────┴───────┐ ┌────────┴────────┐ ││ │ Hypervisor │ │ Docker Daemon │ ││ │ (Hard HW) │ │ (Shared Kernel)│ ││ └───────┬───────┘ └────────┬────────┘ ││ │ │ ││ ┌───────┴───────┐ ┌────────┴────────┐ ││ │ Hardware │ │ Host Kernel │ ││ └───────────────┘ └─────────────────┘ ││ ││ Implications: ││ • VM: Strong isolation via separate kernels ││ • Container: Weaker isolation, faster but shared kernel ││ │└─────────────────────────────────────────────────────────────────────────────┘Security Layers
Section titled “Security Layers”Container security follows a defense-in-depth approach with multiple layers:
┌─────────────────────────────────────────────────────────────────────────────┐│ CONTAINER SECURITY LAYERS │├─────────────────────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ APPLICATION LAYER │ ││ │ • Secure coding practices │ ││ │ • Input validation │ ││ │ • Dependency management │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ CONTAINER LAYER │ ││ │ • Minimal base images │ ││ │ • Non-root user │ ││ │ • Read-only filesystem │ ││ │ • Drop capabilities │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ ORCHESTRATION LAYER │ ││ │ • Network policies │ ││ │ • Resource limits │ ││ │ • Pod security policies │ ││ │ • RBAC │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ INFRASTRUCTURE LAYER │ ││ │ • Host hardening │ ││ │ • Kernel namespaces │ ││ │ • SELinux/AppArmor │ ││ │ • Seccomp │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘Why Container Security Matters
Section titled “Why Container Security Matters”Attack Vectors
Section titled “Attack Vectors”Understanding potential attack vectors helps prioritize security measures:
┌─────────────────────────────────────────────────────────────────────────────┐│ CONTAINER ATTACK VECTORS │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Common Attack Vectors in Container Environments ││ ││ ┌──────────────────────────────────────────────────────────────────┐ ││ │ │ ││ │ 1. COMPROMISED IMAGES │ ││ │ ├── Malicious base images │ ││ │ ├── Vulnerable dependencies │ ││ │ ├── Embedded secrets │ ││ │ └── Supply chain attacks │ ││ │ │ ││ │ 2. CONTAINER ESCALATION │ ││ │ ├── Kernel exploits │ ││ │ ├── Privilege escalation │ ││ │ ├── Capability abuse │ ││ │ └── Mount escapes │ ││ │ │ ││ │ 3. NETWORK ATTACKS │ ││ │ ├── Man-in-the-middle │ ││ │ ├── Eavesdropping │ ││ │ ├── DNS spoofing │ ││ │ └── Service exploitation │ ││ │ │ ││ │ 4. RUNTIME ATTACKS │ ││ │ ├── Container breakout │ ││ │ ├── Resource exhaustion │ ││ │ ├── Denial of service │ ││ │ └── Cryptomining │ ││ │ │ ││ │ 5. SUPPLY CHAIN │ ││ │ ├── Compromised registries │ ││ │ ├── Typosquatting │ ││ │ └── Backdoored images │ ││ │ │ ││ └──────────────────────────────────────────────────────────────────┘ ││ ││ Real-world Impact: ││ • Data breaches - Exposure of sensitive data ││ • Service disruption - Downtime and revenue loss ││ • Reputation damage - Loss of customer trust ││ • Compliance violations - Regulatory penalties ││ • Cryptojacking - Resource theft for cryptocurrency ││ │└─────────────────────────────────────────────────────────────────────────────┘Security Statistics
Section titled “Security Statistics”┌─────────────────────────────────────────────────────────────────────────────┐│ CONTAINER SECURITY STATISTICS │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Recent Security Reports Highlight Critical Concerns: ││ ││ ┌────────────────────────────────────────────────────────────────────┐ ││ │ │ ││ │ 📊 60% of organizations experienced a container security incident │ ││ │ │ ││ │ 📊 94% of scanned images contain known vulnerabilities │ ││ │ │ ││ │ 📊 67% of images have high or critical severity issues │ ││ │ │ ││ │ 📊 75% of developers don't scan containers before deployment │ ││ │ │ ││ │ 📊 Top vulnerabilities: │ ││ │ • Outdated system libraries │ ││ │ • Application dependencies │ ││ │ • Base image issues │ ││ │ • Misconfigurations │ ││ │ │ ││ └────────────────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘Docker Security Fundamentals
Section titled “Docker Security Fundamentals”Docker Daemon Security
Section titled “Docker Daemon Security”The Docker daemon runs with root privileges, making its security critical:
# Secure Docker daemon configuration{ "icc": false, "ip-forward": false, "iptables": true, "userland-proxy": false, "live-restore": true, "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" }, "storage-driver": "overlay2", "default-ulimits": { "nofile": { "Name": "nofile", "Hard": 64000, "Soft": 64000 } }, "default-cgroupns-mode": "host", "no-new-privileges": true, "security-options": { "seccomp-profile": "/etc/docker/seccomp.json", "apparmor-profile": "docker-default" }}Running Docker as Non-Root
Section titled “Running Docker as Non-Root”# Create docker group and add users (if not exists)sudo groupadd dockersudo usermod -aG docker $USER
# Use rootless Docker (recommended for better security)# Requires docker-rootless-setuptool.shContainer Security Best Practices
Section titled “Container Security Best Practices”1. Use Minimal Base Images
Section titled “1. Use Minimal Base Images”┌─────────────────────────────────────────────────────────────────────────────┐│ MINIMAL BASE IMAGES COMPARISON │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Full Image (Ubuntu) Minimal Image (Alpine) ││ ┌───────────────────┐ ┌───────────────────┐ ││ │ ~900 MB │ │ ~5 MB │ ││ │ │ │ │ ││ │ Includes: │ │ Includes: │ ││ │ • Full OS │ │ • Minimal Linux │ ││ │ • Package manager│ │ • BusyBox │ ││ │ • Many libraries│ │ • APK package │ ││ │ • Development tools│ │ • libc │ ││ │ │ │ │ ││ │ Attack Surface: │ │ Attack Surface: │ ││ │ HIGH │ │ LOW │ ││ └───────────────────┘ └───────────────────┘ ││ ││ Even Better: Distroless Images ││ ┌───────────────────┐ ││ │ gcr.io/distroless │ ││ │ ~2 MB │ ││ │ │ ││ │ No shell, no pkg │ ││ │ manager │ ││ │ │ ││ │ Attack Surface: │ ││ │ MINIMAL │ ││ └───────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘2. Run as Non-Root User
Section titled “2. Run as Non-Root User”# Bad: Running as rootFROM ubuntu:22.04RUN apt-get update && apt-get install -y nginxCMD ["nginx", "-g", "daemon off;"]
# Good: Running as non-rootFROM ubuntu:22.04RUN apt-get update && apt-get install -y nginx \ && useradd -m -s /bin/bash appuser
USER appuserWORKDIR /home/appuser
# Best: Using minimal imageFROM alpine:3.18RUN addgroup -g 1000 appgroup && adduser -u 1000 -G appgroup -s /bin/sh -D appuserCOPY --chown=appuser:appgroup . /home/appuserUSER appuserCMD ["nginx", "-g", "daemon off;"]3. Use Read-Only Filesystem
Section titled “3. Use Read-Only Filesystem”# Run container with read-only filesystemdocker run --read-only -d nginx
# Combine with tmpfs for writable areasdocker run --read-only --tmpfs /tmp -d nginx
# In docker-composeservices: web: image: nginx read_only: true tmpfs: - /tmp:size=100M,mode=17774. Drop All Capabilities and Add Only Required Ones
Section titled “4. Drop All Capabilities and Add Only Required Ones”# Drop all capabilities, add only NET_BIND_SERVICEdocker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx
# Common capabilities needed:# - NET_BIND_SERVICE: Bind to privileged ports# - CHOWN: Change file ownership# - SETGID/SETUID: Set process IDs# - SYS_CHROOT: Change root directory5. Limit Resources
Section titled “5. Limit Resources”# Limit CPU and memorydocker run --memory=256m --cpus=0.5 nginx
# Limit pids (processes)docker run --pids-limit=100 nginx
# Limit file descriptorsdocker run --ulimit nofile=100:200 nginxLinux Kernel Security Features
Section titled “Linux Kernel Security Features”Namespaces
Section titled “Namespaces”Docker uses Linux namespaces to provide isolation:
┌─────────────────────────────────────────────────────────────────────────────┐│ LINUX NAMESPACES │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Namespaces provide isolation for: ││ ││ ┌─────────────────┐ ┌─────────────────────────────────────────────┐ ││ │ PID Namespace │ │ Process Isolation │ ││ │ │ │ Container sees only its processes │ ││ │ Process ID │ │ PID 1 inside container = PID X on host │ ││ └─────────────────┘ └─────────────────────────────────────────────┘ ││ ││ ┌─────────────────┐ ┌─────────────────────────────────────────────┐ ││ │ NET Namespace │ │ Network Isolation │ ││ │ │ │ Separate network stack per container │ ││ │ Network │ │ Virtual eth0, loopback, routing tables │ ││ └─────────────────┘ └─────────────────────────────────────────────┘ ││ ││ ┌─────────────────┐ ┌─────────────────────────────────────────────┐ ││ │ IPC Namespace │ │ Inter-Process Communication │ ││ │ │ │ Separate semaphores, shared memory │ ││ │ IPC │ │ Cannot communicate with host IPC │ ││ └─────────────────┘ └─────────────────────────────────────────────┘ ││ ││ ┌─────────────────┐ ┌─────────────────────────────────────────────┐ ││ │ MNT Namespace │ │ Filesystem Isolation │ ││ │ │ │ Separate mount points │ ││ │ Mount │ │ Rootfs appears as full system │ ││ └─────────────────┘ └─────────────────────────────────────────────┘ ││ ││ ┌─────────────────┐ ┌─────────────────────────────────────────────┐ ││ │ UTS Namespace │ │ Hostname Isolation │ ││ │ │ │ Can set different hostname │ ││ │ UTS │ │ Different domain names possible │ ││ └─────────────────┘ └─────────────────────────────────────────────┘ ││ ││ ┌─────────────────┐ ┌─────────────────────────────────────────────┐ ││ │ USER Namespace │ │ User ID Mapping │ ││ │ │ │ Root in container ≠ root on host │ ││ │ User │ │ Map UID 0 in container to UID 100000 on host │ ││ └─────────────────┘ └─────────────────────────────────────────────┘ ││ │└────────────────────────────────────────────────────────────────────────────### Control Groups (cgroups)
```─┘bash
View cgroups for a container
Section titled “View cgroups for a container”docker exec
Example output:
Section titled “Example output:”12:devices:/docker/
Section titled “12:devices:/docker/”11:cpu,cpuacct:/docker/
Section titled “11:cpu,cpuacct:/docker/”10:memory:/docker/
Section titled “10:memory:/docker/”9:freezer:/docker/
Section titled “9:freezer:/docker/”### Seccomp
Seccomp limits system calls available to containers:
```json{ "defaultAction": "SCMP_ACT_ERRNO", "architectures": ["SCMP_ARCH_X86_64"], "syscalls": [ { "names": [ "read", "write", "open", "close", "mmap", "mprotect", "brk", "rt_sigaction", "rt_sigprocmask", "ioctl" ], "action": "SCMP_ACT_ALLOW" } ]}# Use default seccomp profiledocker run --security-opt seccomp=docker-default nginx
# Use custom seccomp profiledocker run --security-opt seccomp=/path/to/profile.json nginx
# Disable seccomp (not recommended for production)docker run --security-opt seccomp=unconfined nginxAppArmor
Section titled “AppArmor”# Run with AppArmor profiledocker run --security-opt apparmor=docker-default nginx
# Check AppArmor status in containerdocker exec <container> cat /sys/kernel/security/apparmor/profilesDocker Content Trust
Section titled “Docker Content Trust”Enabling Content Trust
Section titled “Enabling Content Trust”# Enable Docker Content Trustexport DOCKER_CONTENT_TRUST=1
# Now pulls will verify image signaturesdocker pull nginx:latest
# Signing images requires private keydocker trust sign myregistry.io/myimage:latestManaging Keys
Section titled “Managing Keys”# Initialize trust (first time)docker trust init
# Add signersdocker trust key load key.pemdocker trust signer add --key key.pem publisherName myregistry.io
# View signersdocker trust inspect myregistry.io/myimage:latestImage Scanning and Vulnerability Management
Section titled “Image Scanning and Vulnerability Management”Inline Scanning
Section titled “Inline Scanning”# Using Docker Scout (recommended)docker scout cves myimage:latest
# Using Trivytrivy image myimage:latest
# Using Clairclair-scanner --ip 127.0.0.1 myimage:latestScanning in CI/CD
Section titled “Scanning in CI/CD”# GitHub Actions examplename: Security Scan
on: [push, pull_request]
jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3
- name: Run Trivy scanner uses: aquasecurity/trivy-action@master with: scan-type: 'fs' scan-ref: '.' format: 'sarif' output: 'trivy-results.sarif'
- name: Upload results to GitHub Security uses: github/codeql-action/upload-sarif@v2 with: sarif_file: 'trivy-results.sarif'Vulnerability Management Process
Section titled “Vulnerability Management Process”┌─────────────────────────────────────────────────────────────────────────────┐│ VULNERABILITY MANAGEMENT PROCESS │├─────────────────────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ 1. SCAN │ ││ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ Local │ │ CI/CD │ │ Registry │ │ ││ │ │ Scanner │ │ Scanner │ │ Scanner │ │ ││ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ 2. ASSESS │ ││ │ │ ││ │ Severity Levels: │ ││ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ││ │ │ CRITICAL│ │ HIGH │ │ MEDIUM │ │ LOW │ │ ││ │ │ Fix Now │ │ Fix Soon│ │ Plan Fix│ │ Accept │ │ ││ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ││ │ │ ││ │ Consider: Exploitability, CVSS score, Asset criticality │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ 3. REMEDIATE │ ││ │ │ ││ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ Update │ │ Remove │ │ Apply │ │ ││ │ │ Base Image │ │ Dependency │ │ Patch │ │ ││ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ │ │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────────────────────┐ ││ │ 4. VERIFY │ ││ │ │ ││ │ Re-scan to confirm remediation │ ││ │ Update baseline for acceptable risks │ ││ │ Document exceptions │ ││ └─────────────────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘Secrets Management
Section titled “Secrets Management”Docker Secrets
Section titled “Docker Secrets”# Create a secretecho "my-secret-password" | docker secret create db_password -
# Create secret from filedocker secret create db_password ./password.txt
# List secretsdocker secret ls
# Use secret in servicedocker service create \ --name myapp \ --secret db_password \ myapp:latest
# Access secret in container# File-based: /run/secrets/<secret_name>cat /run/secrets/db_passwordDocker Compose with Secrets
Section titled “Docker Compose with Secrets”version: '3.8'
services: web: image: nginx secrets: - db_password - api_key
secrets: db_password: file: ./secrets/db_password.txt api_key: external: trueBest Practices for Secrets
Section titled “Best Practices for Secrets”┌─────────────────────────────────────────────────────────────────────────────┐│ SECRETS MANAGEMENT BEST PRACTICES │├─────────────────────────────────────────────────────────────────────────────┤│ ││ ✓ DO: ││ ───────────────────────────────────────────────────────────────────── ││ • Use Docker secrets in Swarm / Kubernetes secrets in K8s ││ • Rotate secrets regularly ││ • Use external secrets management (Vault, AWS Secrets Manager) ││ • Audit secret access ││ • Enable encryption at rest ││ • Use separate secrets per environment ││ ││ ✗ DON'T: ││ ───────────────────────────────────────────────────────────────────── ││ • Never commit secrets to version control ││ • Don't store secrets in environment variables ││ • Don't use same secrets across environments ││ • Don't share secret files ││ • Never log secrets ││ │└─────────────────────────────────────────────────────────────────────────────┘Network Security
Section titled “Network Security”Network Isolation
Section titled “Network Isolation”# Create custom network with isolationdocker network create --driver bridge --internal myapp-network
# Run containers on specific networksdocker run --network myapp-network nginx
# Use network aliases for service discoverydocker run --network-alias api myapp:latestNetwork Policies (Swarm)
Section titled “Network Policies (Swarm)”# Create encrypted overlay networkdocker network create \ --driver overlay \ --encrypted \ --attachable \ secure-networkPort Security
Section titled “Port Security”# Don't expose unnecessary ports# Bad: Expose alldocker run -p 0.0.0.0:8080:8080 myapp
# Good: Bind to localhost onlydocker run -p 127.0.0.1:8080:8080 myapp
# Good: Minimal exposuredocker run -p 80:8080 myappRuntime Security
Section titled “Runtime Security”Container Runtime Security
Section titled “Container Runtime Security”# Enable additional security optionsdocker run \ --security-opt no-new-privileges:true \ --cap-drop ALL \ --read-only \ --tmpfs /tmp \ nginx
# Add specific capabilitiesdocker run \ --cap-drop ALL \ --cap-add NET_BIND_SERVICE \ --cap-add CHOWN \ nginxFalco - Runtime Security Monitoring
Section titled “Falco - Runtime Security Monitoring”# Install Falcodocker run -d \ --name falco \ --privileged \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /proc:/host/proc:ro \ falcosecurity/falco
# Example Falco rule for container security- rule: Shell in container desc: A shell was spawned in a container condition: > container.id != host and proc.name = bash output: "Shell spawned in container (user=%user.name %container.info)" priority: WARNINGSecurity Scanning Tools
Section titled “Security Scanning Tools”Popular Security Tools
Section titled “Popular Security Tools”┌─────────────────────────────────────────────────────────────────────────────┐│ CONTAINER SECURITY TOOLS │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Image Scanning ││ ───────────────── ││ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ││ │ Trivy │ │ Clair │ │ Anchore │ ││ │ Free/Open │ │ Open Source │ │ Enterprise │ ││ │ Fast, Easy │ │ Static │ │ Deep │ ││ │ │ │ Analysis │ │ Inspection │ ││ └────────────────┘ └────────────────┘ └────────────────┘ ││ ││ Runtime Security ││ ───────────────── ││ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ││ │ Falco │ │ Sysdig │ │ Aqua │ ││ │ Open Source │ │ Commercial │ │ Enterprise │ ││ │ Kernel-based│ │ Full Stack │ │ Complete │ ││ │ Monitoring │ │ Security │ │ Platform │ ││ └────────────────┘ └────────────────┘ └────────────────┘ ││ ││ Registry Security ││ ───────────────── ││ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ││ │ Docker Hub │ │ Harbor │ │ ACR/GCR/ECR │ ││ │ Security │ │ Open Source │ │ Native Scan │ ││ │ Scanning │ │ Registry │ │ │ ││ └────────────────┘ └────────────────┘ └────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘Security Hardening
Section titled “Security Hardening”Docker Bench Security
Section titled “Docker Bench Security”# Run Docker Benchdocker run --rm -it \ --net host \ --pid host \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/docker:/etc/docker \ docker/bench-securityChecklist
Section titled “Checklist”┌─────────────────────────────────────────────────────────────────────────────┐│ DOCKER SECURITY CHECKLIST │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Infrastructure ││ ─────────────── ││ □ Keep Docker engine updated ││ □ Use minimal base images ││ □ Regular security scans ││ □ Enable Docker Content Trust ││ □ Use private registries ││ ││ Container Configuration ││ ───────────────────── ││ □ Run as non-root user ││ □ Use read-only filesystem ││ □ Drop all capabilities ││ □ Limit resources (memory, CPU) ││ □ Disable inter-container communication ││ □ Use specific image tags ││ ││ Network Security ││ ──────────────── ││ □ Use custom networks ││ □ Encrypt overlay networks ││ □ Minimize port exposure ││ □ Use TLS for registry ││ □ Implement network policies ││ ││ Secrets Management ││ ─────────────────── ││ □ Use Docker secrets ││ □ Rotate secrets regularly ││ □ Use external secrets management ││ □ Never commit secrets ││ ││ Monitoring & Logging ││ ──────────────────── ││ □ Enable audit logging ││ □ Monitor for anomalies ││ □ Set up alerts ││ □ Review logs regularly ││ │└─────────────────────────────────────────────────────────────────────────────┘Compliance and Auditing
Section titled “Compliance and Auditing”CIS Docker Benchmark
Section titled “CIS Docker Benchmark”The CIS Docker Benchmark provides security configuration guidelines:
# Docker Bench includes CIS checksdocker run -d \ --name docker-bench \ --net host \ --pid host \ -v /etc/docker:/etc/docker \ docker/bench-securityAudit Requirements
Section titled “Audit Requirements”┌─────────────────────────────────────────────────────────────────────────────┐│ COMPLIANCE CONSIDERATIONS │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Common Compliance Frameworks: ││ ││ • SOC 2 - Security, availability, confidentiality ││ • PCI-DSS - Payment card industry ││ • HIPAA - Healthcare data ││ • GDPR - EU data protection ││ • ISO 27001 - Information security ││ ││ Audit Requirements: ││ ───────────────────────────────────────────────────────────────────── ││ • Document all container configurations ││ • Maintain image provenance ││ • Log all security events ││ • Regular vulnerability scans ││ • Incident response procedures ││ • Access control documentation ││ │└─────────────────────────────────────────────────────────────────────────────┘Summary
Section titled “Summary”Key Takeaways
Section titled “Key Takeaways”- Defense in Depth - Layer multiple security controls
- Minimal Attack Surface - Use minimal images, drop capabilities
- Run as Non-Root - Never run containers as root unless necessary
- Scan Regularly - Integrate security scanning into CI/CD
- Manage Secrets Properly - Use Docker secrets or external solutions
- Monitor Continuously - Implement runtime security monitoring
- Keep Updated - Patch vulnerabilities regularly
- Follow Best Practices - Use CIS benchmarks and security guides
Quick Reference Commands
Section titled “Quick Reference Commands”# Run securelydocker run \ --rm \ --cap-drop ALL \ --read-only \ --pids-limit 100 \ --memory=256m \ --cpus=0.5 \ --user 1000:1000 \ nginx
# Security scanningdocker scout cves myimage:latesttrivy image myimage:latest
# Docker benchdocker run --rm -it --net host --pid host \ -v /var/run/docker.sock:/var/run/docker.sock \ docker/bench-securityNext Steps
Section titled “Next Steps”In the next chapter, we’ll explore Docker Monitoring (Chapter 13), covering:
- Container logging best practices
- Monitoring tools and metrics
- Log aggregation
- Alerting strategies