10.3 容器安全：Docker Bench Security 配置审计

预计阅读时间：18 分钟

Docker Bench Security 是 Aqua Security 基于 CIS（Center for Internet Security）Docker Benchmark 开发的自动化审计脚本。它检查 Docker 主机、Docker 守护进程配置、容器运行时、镜像安全等是否符合 CIS 安全基线。CIS Docker Benchmark 是业界公认的 Docker 安全配置标准，涵盖了从主机配置到容器运行时各层面的安全检查。Docker Bench Security 将这些检查自动化，帮助运维团队快速识别和修复安全配置问题。

学习目标

• 理解 CIS Docker Benchmark 的检查体系和六大类别
• 能够运行 Docker Bench Security 并正确解读审计结果
• 掌握关键安全检查项的修复方法（特权容器、只读文件系统、健康检查等）
• 能够编写自动化巡检脚本，将审计集成到日常运维流程中

前置知识

• Docker 基础操作（docker ps、docker inspect、docker run）
• Docker Compose 基本语法
• Linux 系统管理基础（分区、文件权限、systemd）
• 了解容器安全的基本概念（capabilities、seccomp、AppArmor）
• 基础 Shell 脚本编写能力

安装与运行

# 直接从 GitHub 运行（不需要安装）
docker run --rm \
  --net host \
  --pid host \
  --userns host \
  --cap-add audit_control \
  -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /etc:/etc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc/systemd:/etc/systemd:ro \
  docker/docker-bench-security

# 也可以克隆仓库直接运行
git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo ./docker-bench-security.sh

运行参数详解

检查项概览（CIS Docker Benchmark v1.6）

结果状态说明

关键检查项详解

1. Docker 使用独立分区（Score: 高分）

# CIS 要求 /var/lib/docker 在独立分区
# 防止 Docker 日志填满根分区导致系统崩溃
df -h /var/lib/docker

# 如果不在独立分区，添加新的磁盘挂载到 /var/lib/docker

# 检查方法
mount | grep /var/lib/docker
# 如果没有单独的挂载点，说明 /var/lib/docker 在根分区上

# 修复步骤
# 1. 添加新磁盘
sudo fdisk /dev/sdb
sudo mkfs.ext4 /dev/sdb1

# 2. 临时停止 Docker
sudo systemctl stop docker

# 3. 迁移数据
sudo mkdir -p /mnt/docker-data
sudo mount /dev/sdb1 /mnt/docker-data
sudo rsync -av /var/lib/docker/ /mnt/docker-data/

# 4. 更新 /etc/fstab
echo '/dev/sdb1 /var/lib/docker ext4 defaults 0 0' | sudo tee -a /etc/fstab

# 5. 卸载临时挂载并挂载到正确位置
sudo umount /mnt/docker-data
sudo mount /dev/sdb1 /var/lib/docker

# 6. 重启 Docker
sudo systemctl start docker

2. 禁止特权容器（Score: 高危）

# 检查运行中的特权容器
docker ps --filter "status=running" --format "{{.Names}}" \
  | xargs docker inspect --format '{{.Name}} {{.HostConfig.Privileged}}'

# 在 Docker Compose 中不设置 privileged: true
# 在 K8s 中不设置 securityContext.privileged: true

# 替代方案：只给予需要的 capabilities
docker run --cap-add=NET_ADMIN --cap-add=SYS_PTRACE nginx

# 查看容器的所有 capabilities
docker inspect --format '{{.HostConfig.CapAdd}}' 

# 了解默认 capabilities
# Docker 默认赋予容器的 capabilities：
# CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FSETID, CAP_FOWNER,
# CAP_MKNOD, CAP_NET_RAW, CAP_SETGID, CAP_SETUID,
# CAP_SETFCAP, CAP_SETPCAP, CAP_NET_BIND_SERVICE,
# CAP_SYS_CHROOT, CAP_KILL, CAP_AUDIT_WRITE

3. 默认网桥配置（Score: 中危）

# 禁止容器间通信（默认开启）
# /etc/docker/daemon.json
{
  "icc": false
}

# 不使用默认网桥，使用自定义网络
docker network create mynet
docker run --network mynet nginx

# 检查默认网桥上的容器
docker network inspect bridge | jq '.[0].Containers'

# 使用自定义网络可以实现：
# 1. DNS 解析（容器名自动解析）
# 2. 网络隔离（不同网络间默认不互通）
# 3. 更好的安全性

4. 使用只读根文件系统（Score: 高分）

# 容器只读根文件系统 + 临时写入卷
docker run --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /var/run:rw,noexec,nosuid \
  nginx

# Docker Compose
services:
  app:
    image: myapp
    read_only: true
    tmpfs:
    - /tmp:noexec
    - /var/run

# 只读根文件系统的好处：
# 1. 防止容器内恶意写入可执行文件
# 2. 防止篡改应用代码或配置
# 3. 减小攻击面
# 4. 强制使用临时卷处理运行时数据

5. 健康检查（Score: 中危）

# Dockerfile 中设置
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

# Docker Compose
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
  interval: 30s
  timeout: 10s
  retries: 3

# 健康检查参数说明
# interval:  检查间隔（默认 30s）
# timeout:   超时时间（默认 30s）
# retries:   失败重试次数（默认 3）
# start-period: 容器启动后的宽限期（此期间失败不计入重试次数）

# 查看容器健康状态
docker inspect --format '{{.State.Health.Status}}' 
# 输出：healthy / unhealthy / starting

6. 资源限制（Score: 高分）

# 限制容器资源使用，防止资源耗尽攻击
docker run -d \
  --memory="256m" \
  --cpus="1.0" \
  --pids-limit=100 \
  nginx

# Docker Compose
services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 256M
        reservations:
          cpus: '0.5'
          memory: 128M

# 检查容器资源限制
docker inspect --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}' 

7. 日志配置（Score: 中危）

# 配置日志驱动和大小限制
# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

# 或在 docker run 时指定
docker run --log-driver=json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  nginx

# 查看容器日志配置
docker inspect --format '{{.HostConfig.LogConfig.Type}}' 

自动化巡检脚本

#!/bin/bash
# 每周自动运行 Docker Bench Security 并将结果写入文件
# 配合 cron：0 8 * * 1 /opt/scripts/docker-bench-audit.sh

OUTPUT_DIR=/var/log/docker-bench
mkdir -p $OUTPUT_DIR

docker run --rm \
  --net host --pid host --userns host \
  --cap-add audit_control \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /etc:/etc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc/systemd:/etc/systemd:ro \
  docker/docker-bench-security \
  > $OUTPUT_DIR/$(date +%F).txt 2>&1

# 检查高危项
grep -E "\[WARN\]|\[FAIL\]" $OUTPUT_DIR/$(date +%F).txt | \
  grep -i "privileged\|user namespace\|read-only" | \
  mail -s "Docker Bench Security 高危项" ops@example.com

CIS 基线体系与审计项分类

CIS（Center for Internet Security）是国际非营利安全组织，发布覆盖操作系统、数据库、云平台等 100+ 产品的安全基线（Benchmark）。Docker Benchmark 是其中针对 Docker 的分册，每 1-2 年随 Docker 功能演进更新版本（v1.6.0 对应 Docker 23.x 时代）。

审计项按"防护对象"分为六大类，理解分类逻辑能帮你快速定位问题归属：

审计项的三层解读方法

• 识别：先看懂脚本在"检查什么配置"（读对应 shell 片段或 CIS 文档原文）
• 评估：判断该配置在你的运行环境下是否必要——例如"1.2.1 启用隔离性更强的 cgroup 版本"在 cgroup v2 内核上本来就满足
• 修复：按"守护进程级（daemon.json）→ 镜像级（Dockerfile）→ 容器级（run 参数）"的优先级落地

关键审计项分级处置矩阵

daemon.json 生产加固模板

# /etc/docker/daemon.json —— 对应类别 2/3 的大多数检查项
{
  "icc": false,
  "iptables": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true,
  "userland-proxy": false,
  "no-new-privileges": true,
  "default-ulimits": {
    "nofile": { "Name": "nofile", "Hard": 65535, "Soft": 65535 }
  },
  "default-runtime": "runc",
  "storage-driver": "overlay2",
  "experimental": false
}

# 应用配置并验证
sudo systemctl daemon-reload
sudo systemctl restart docker
# 验证配置生效
docker info | grep -E "Logging Driver|Cgroup Driver|Storage Driver"
# 重新跑一次审计，观察对应项从 FAIL 变为 PASS

自动化巡检平台化

把审计从"人肉跑脚本"升级为"平台任务"，关键是解析输出。Docker Bench Security 支持 -j 输出 JSON，配合集中式采集即可形成可视化趋势：

# 1. 生成 JSON 结果（-j 参数）
docker run --rm \
  --net host --pid host --userns host \
  --cap-add audit_control \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /etc:/etc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc/systemd:/etc/systemd:ro \
  docker/docker-bench-security -j \
  > /var/log/docker-bench/$(date +%F).json 2>/dev/null

# 2. 解析：统计各状态数量（jq）
jq '{PASS: (.summary.pass), FAIL: (.summary.fail), WARN: (.summary.warn)}' \
  /var/log/docker-bench/$(date +%F).json

# 3. 失败项明细（供修复团队直接领取）
jq -r '.checks[] | select(.result=="FAIL") | [.id, .desc] | @tsv' \
  /var/log/docker-bench/$(date +%F).json

# 4. 与上次结果对比，输出"新增 FAIL"（基线漂移检测）
diff <(jq -r '.checks[]|select(.result=="FAIL")|.id' 上周.json) \
     <(jq -r '.checks[]|select(.result=="FAIL")|.id' 今天.json) | grep "^>"

集中化落地路径：cron 定时执行 → JSON 落盘 → filebeat/promtail 采集进 Loki/ES → Grafana 面板展示"FAIL 数量趋势 + 新增项高亮"，配合告警规则（FAIL 数超过阈值或出现新 FAIL 项时通知安全组）。

修复闭环管理

审计的真正价值在"修复"，而没有流程支撑的修复清单只会烂在邮件里。推荐闭环如下：

1. 建单：每次巡检把 FAIL 项按"严重性 × 影响范围"自动生成工单（高危项自动指派安全负责人）
2. 修复：按上文的处置矩阵时限完成（daemon.json / Dockerfile / run 参数三处落点）
3. 复检：修复后立即重跑对应检查项，确认 FAIL → PASS（只跑单项：docker-bench-security.sh -c section_5）
4. 豁免登记：确认为业务必需、无法修改的项（如需要 hostNetwork 的监控组件），登记豁免原因 + 到期复审日期，纳入文档
5. 月度回顾：汇总"新增修复数 / 新增豁免数 / 反复出现的项"，把反复项提升为专项治理

# 只审计某一大类（加快迭代反馈）
sudo ./docker-bench-security.sh -c section_5
# 检查项过滤：只跑指定 ID（如 4.1 健康检查）
sudo ./docker-bench-security.sh -i 4.1
# 跳过指定项（已知豁免）
sudo ./docker-bench-security.sh -e 4.1 -e 5.12

常见检查项速查表

日常巡检中命中率最高的 10 个检查项及其修复落点，运维可以直接对照执行：

镜像级 vs 守护进程级检查的定位

# 同一个问题可能出现在不同层面，先分清修哪里
# 例："容器以 root 运行"（4.6 镜像项 / 5.4 运行时项）
# 修镜像：Dockerfile 加 USER appuser（一劳永逸，所有部署受益）
# 修运行时：docker run --user 1000（紧急止血，镜像重建前过渡）

# 例："未设置资源限制"（5.10 运行时项）
# 修镜像：Compose/编排模板统一加 resources
# 修守护进程：daemon.json 无法全局限制单容器——必须在部署层解决

# 快速定位工具：检查项编号前缀决定层面
# 1.x 宿主机、2.x/3.x 守护进程、4.x 镜像、5.x 容器运行时、6.x 组织机制

审计输出解读示例

拿到一份 Docker Bench 报告，正确的解读顺序不是"挨个看 PASS/FAIL"，而是先看统计、再看高危、最后核对 NOTE：

[INFO] 1 - Host Configuration
[PASS] 1.1  Ensure a separate partition for containers
[WARN] 1.2  Ensure the container host has been Hardened
[NOTE] 1.5  Ensure Docker socket is not attached to a network
[FAIL] 2.7  Ensure the default address on bridge 172.17.0.1 is not used
...
[INFO] 5 - Container Runtime
[FAIL] 5.1  Ensure privileged containers are not used
[WARN] 5.6  Ensure the root filesystem is mounted as read-only
[FAIL] 5.7  Ensure container root filesystem is mounted as read-only
...
[INFO] Summary: PASS=18 WARN=6 FAIL=4 NOTE=2

逐项解读

审计任务失败的兜底与告警

自动化巡检同样会"失灵"：cron 没执行、容器拉取失败、输出目录写满——任何一个都会让审计悄悄中断。兜底机制与业务监控同等重要：

#!/bin/bash
# 审计任务包装器：失败也留下痕迹
set -uo pipefail

OUTPUT_DIR=/var/log/docker-bench
LATEST="$OUTPUT_DIR/$(date +%F).json"
LOCK=/tmp/docker-bench.lock

# 1. 互斥锁：防止任务重叠（前一轮卡住时跳过本轮）
exec 9>"$LOCK"
if ! flock -n 9; then
  echo "ALERT: 上一轮审计仍未结束，跳过本轮" | logger -t docker-bench
  exit 1
fi

# 2. 执行审计（失败也要写结果文件，保证趋势面板不断档）
if ! docker run --rm \
  --net host --pid host --userns host \
  --cap-add audit_control \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /etc:/etc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc/systemd:/etc/systemd:ro \
  docker/docker-bench-security -j > "$LATEST" 2>/dev/null; then
  echo "ALERT: 审计执行失败，详见 $LATEST" | logger -t docker-bench
  exit 2
fi

# 3. 结果健康自检：JSON 可解析 + FAIL 数在阈值内
jq -e '.checks | length > 0' "$LATEST" >/dev/null || exit 3
FAILS=$(jq '[.checks[] | select(.result=="FAIL")] | length' "$LATEST")
if [ "$FAILS" -gt 8 ]; then
  echo "ALERT: 本轮 FAIL 数 $FAILS 超过阈值 8" | logger -t docker-bench
fi

# 4. 结果转发到集中日志（供 Grafana 趋势面板消费）
logger -t docker-bench "pass=$(jq '.summary.pass' "$LATEST") fail=$FAILS warn=$(jq '.summary.warn' "$LATEST")"

三层容器安全体系总览

容器安全入门检查清单

[ ] 使用非 root 用户运行容器（USER 指令）
[ ] 镜像使用多阶段构建减小攻击面
[ ] 镜像定期扫描漏洞（Trivy）
[ ] 容器文件系统设为只读（--read-only）
[ ] 不设置 --privileged，用 --cap-add 细粒度授权
[ ] 启用 Docker Content Trust
[ ] 配置日志和健康检查
[ ] 不允许 hostNetwork 和 hostPID
[ ] 使用自定义网络隔离容器
[ ] 启用 AppArmor / seccomp 策略

常见错误

最佳实践

• 在生产环境中每周自动运行 Docker Bench Security，将结果存档并发送报告
• 将 Dockerfile 安全检查集成到 CI/CD 流水线中（如 hadolint 检查 Dockerfile 最佳实践）
• 对检查结果中的 FAIL 项进行分级处理：高危立即修复，中危在当前迭代内修复
• 将检查脚本和修复记录纳入 Git 版本管理，便于审计追溯
• 结合 CIS Benchmark 文档理解每项检查的安全意义，而非盲目修复
• 在容器编排层面（K8s Pod Security Standards）统一实施安全策略
• 定期更新 Docker 和宿主机内核，修复已知漏洞
• 使用 Docker Content Trust（DCT）确保镜像来源可信

练习题

1. 基础审计练习：在一台 Linux 服务器上运行 Docker Bench Security，记录所有 FAIL 和 WARN 项。对每个 FAIL 项，查阅 CIS Benchmark 文档，给出具体的修复步骤。
2. 自动化脚本练习：编写一个 Shell 脚本，实现以下功能：每周自动运行 Docker Bench Security，解析输出结果，将 FAIL 项按严重性分类，并通过邮件发送给运维团队。将脚本配置为 cron 定时任务。
3. 安全加固练习：选择一个现有的 Docker Compose 项目，根据 Docker Bench Security 的检查结果，对 docker-compose.yml 进行安全加固：添加资源限制、只读文件系统、健康检查、非 root 用户运行等配置。重新运行 Docker Bench Security 验证改进效果。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

Docker Bench Security 基于 CIS Docker Benchmark 这一行业标准，对宿主机、守护进程、镜像与容器等层面做配置审计，是建立容器安全基线最直接的起点。静态检查的价值在于持续跟踪：把巡检纳入 cron 定时任务或 CI/CD 流水线，每周自动运行并归档结果，才能避免"审计一次、安全一年"的假象。更要牢记审计不等于加固——对 FAIL 项分级修复并形成"检查—修复—复检"的闭环，才是配置审计的真正意义。

延伸阅读