解读

在国内金融、运营商、政务云等合规场景下，“等保 2.0” 与 “关基安全保护条例” 均把容器平台纳入测评范围。面试官抛出该题，既考察候选人能否快速定位 Docker 守护进程、镜像、容器、网络、存储五大平面的高危配置，也验证其是否具备可落地的修复脚本与灰度方案，而非停留在“跑个脚本”层面。答题节奏通常控制在 5 分钟内：1 分钟讲原理，2 分钟讲扫描输出解读，2 分钟给出修复命令与回滚策略。

知识点

1. docker-bench-security 原理：基于 CIS Docker Benchmark 1.6.0（国内等保测评直接引用），18 大项 120+ 检测项，每条用 “WARN/FAIL/INFO” 标注，返回码 0 仅表示脚本执行成功，不表示合规。
2. 国内高风险红线：
   • 守护进程未启用 TLS 双向认证且 tcp://0.0.0.0:2375 裸奔；
   • userns-remap 未开启导致容器逃逸可获宿主机 root；
   • AppArmor/SElinux 被禁用；
   • --privileged 容器或 --cap-add=SYS_ADMIN 滥用；
   • docker.sock 直接挂载入容器；
   • 镜像未使用国内更新源且 apt-get upgrade 被禁用，导致漏洞补丁滞后。
3. 修复闭环：扫描 → 基线报告 → 配置加固 → 二次扫描 “FAIL→PASS” → 提交 GitLab MR → 纳入 “蓝绿/金丝雀” 验证 → 归档到 “等保测评证据包”。

答案

1. 一键扫描（生产环境推荐 dry-run 模式，避免误杀）

   # 使用国内镜像源加速
   docker run --rm --net host --pid host --cap-add audit_control \
     -v /var/lib:/var/lib \
     -v /var/run/docker.sock:/var/run/docker.sock \
     -v /usr/lib/systemd:/usr/lib/systemd \
     -v /etc:/etc \
     registry.cn-hangzhou.aliyuncs.com/acs/docker-bench-security:v1.6.0 \
     -c container_images -c container_runtime > docker-bench-$(date +%F).log
   

2. 快速定位高危项（FAIL 级别）

   grep -E '(FAIL|WARN)' docker-bench-$(date +%F).log | awk '{print $2}' | sort | uniq -c | sort -nr
   

   典型输出：
   5 “2.8 确保启用用户命名空间”
   3 “4.1 确保容器不使用默认 bridge 网络”
   2 “5.5 确保不使用特权容器”

3. 逐条修复（给出可回滚方案）
   a) 启用用户命名空间，防止 “容器逃逸获 root”

   echo '{"userns-remap": "default"}' > /etc/docker/daemon.json.d/userns.json
   systemctl daemon-reload
   systemctl restart docker
   # 回滚：删除该 json 文件并重启即可
   

   b) 创建自定义网络，避免 docker0 网桥嗅探

   docker network create --driver bridge \
     --subnet 172.26.0.0/24 \
     --gateway 172.26.0.1 \
     -o com.docker.network.bridge.name=br-custom \
     custom_bridge
   # 存量容器通过蓝绿迁移到新网络
   

   c) 禁止特权容器，强制使用最小 Capabilities
   在 GitLab-CI 模板中增加：

   variables:
     DOCKER_DRIVER: overlay2
     DOCKER_TLS_CERTDIR: "/certs"
   script:
     - docker run --rm --read-only --cap-drop ALL --cap-add NET_BIND_SERVICE myapp:${CI_COMMIT_SHA}
   

   d) 守护进程 TLS 加固，满足 “传输加密” 等保条款

   # 使用 cfssl 签发双向证书，已集成到企业内部 CA
   dockerd --tlsverify --tlscacert=ca.pem --tlscert=server.pem --tlskey=server-key.pem \
     -H=0.0.0.0:2376
   

4. 二次扫描验证

   docker run ...（同上） | grep FAIL
   # 期望输出为空，表示全部修复
   

5. 证据归档
   把 “docker-bench-YYYY-MM-DD.log” 与 “daemon.json” 一并提交到 “等保测评 SVN”，供第三方机构抽查。

拓展思考

1. 大规模集群如何 7×24 持续合规？
   把 docker-bench-security 封装为 Kubernetes CronJob，每周二凌晨执行；结果通过 Sidecar 容器推送到阿里云 SLS，再配置 “日志服务告警”，FAIL>3 条即触发钉钉机器人。
2. 与镜像漏洞扫描联动：
   先跑 trivy/clair 做 CVE 静态扫描，再跑 docker-bench 做配置基线扫描，两者都通过才允许 Harbor 自动签署“可信镜像”标记，实现 “镜像安全+运行时配置” 双因子门禁。
3. 零信任场景下的进阶：
   在 “容器运行时安全” 侧接入 Falco，对用户命名空间逃逸、--security-opt apparmor:unconfined 等实时阻断；同时把 docker-bench 结果写入 OPA Gatekeeper 约束模板，集群内任何新节点未通过 CIS 检测即自动被 cordon，实现 “安全即代码” 闭环。