Docker Bind Mount 合规检查如何做

Bind Mount合规检查核心是防止敏感路径暴露与权限滥用：需验证挂载源是否为白名单路径、Mode是否设为ro、宿主机目录权限是否符合最小权限原则、用户与上下文是否隔离、审计日志是否可追溯、生命周期管理是否健全，并优先用Named Volume替代。

Bind Mount 的合规检查核心在于确认挂载行为是否可控、可审计、不越权，尤其在等保、HIPAA 或 GDPR 场景下，必须防止敏感路径暴露、权限滥用或数据残留。

挂载路径来源与权限控制

合规要求明确禁止将宿主机敏感目录（如 /etc、/root、/var/lib/docker）直接挂载进容器。检查时需逐项确认：

1. 运行 docker inspect <container_id>，查看 Mounts 字段中 Source 是否为预定义白名单路径（如 /data/app-conf、/opt/logs），而非 /、/home 等泛目录
2. 检查 Mode 字段是否为 rw 或 ro —— 生产环境对配置类挂载应设为 ro，避免容器内进程意外改写宿主机文件
3. 验证挂载点的宿主机目录权限：执行 ls -ld /path/on/host，确保属主非 root 或至少组权限不开放（如 drwxr-x---），且 SELinux 上下文正确（z 或 Z 参数已按需使用）

用户与上下文隔离

Bind Mount 不自动继承容器用户身份，容易造成权限错配或提权风险：

1. 若容器以非 root 用户运行（如 UID 1001），但挂载目录属主是 root 且无读写权限，则应用启动失败；反之，若目录权限过宽（如 777），则违反最小权限原则
2. 检查是否显式设置了 --user 或 Dockerfile 中 USER 指令，并与挂载目录的 chown 结果匹配。例如：chown -R 1001:1001 /host/data
3. 在 Kubernetes 场景中，还需确认 securityContext.runAsUser 与挂载卷的 fsGroup 配置一致，避免因 group 权限缺失导致日志写入失败

审计与生命周期管理

合规日志必须能追溯“谁、何时、挂载了什么、是否修改”：

1. 仅靠 docker logs 或容器内日志无法满足要求。需结合宿主机 auditd 规则监控挂载行为：auditctl -a always,exit -F arch=b64 -S mount -F path=/host/path -k bind_mount
2. 检查挂载路径是否纳入备份与清理策略：容器删除后，/host/path 内残留的临时文件、PID、socket 是否有自动清理机制（如 systemd-tmpfiles 或 CI/CD 后置脚本）
3. 对含 PHI/PII 的挂载目录，须确认其所在宿主机分区已启用全盘加密（如 LUKS），且挂载参数包含 noexec,nosuid,nodev（可通过 findmnt -t overlay2 查看实际挂载选项）

替代方案优先级评估

Bind Mount 虽灵活，但在强合规场景下属于高风险挂载方式：

1. 优先用 Named Volume 替代 —— Docker 自动管理权限、路径抽象、备份友好，且支持插件加密（如 Vault 插件）
2. 若必须用 Bind Mount，应在 CI/CD 流水线中嵌入静态检查：解析 docker run 命令或 docker-compose.yml，拦截 -v /etc:/etc、-v /:/host 等危险模式
3. 医疗或金融系统中，建议通过 OPA/Gatekeeper 策略强制拒绝未声明 bindPropagation 和 readOnly 的挂载请求