Bind Mount 安全合规的关键是四重校验：路径须绝对静态且无符号链接、挂载选项必须组合启用 ro/noexec/nosuid/nodev、传播属性显式设为 rprivate、运行时身份与能力需同步收紧，缺一不可。
在安全合规检查中，Bind Mount 的风险不在于“用了没用”，而在于挂载行为是否引入越权、逃逸或信息泄露路径。关键不是回避 bind mount，而是让每次挂载都经得起权限、路径、传播性与运行时上下文四重校验。
路径必须绝对且静态可验证
合规工具（如 Docker Bench、kube-bench 或 CIS 基准扫描器）会标记任何含相对路径、环境变量或符号链接的挂载项。必须做到：
- 宿主机源路径和容器目标路径均以 / 开头，例如
/opt/app/config和/etc/myapp - 启动前用
realpath -m /host/path确认路径无 dangling symlink，且最终落在白名单目录内（如仅允许/data、/config、/logs） - 禁用
./、../、$HOME、${PWD}等动态表达式，CI/CD 流水线中应做静态路径 lint 检查
挂载选项需强制组合启用
单靠 ro 不足以满足等保2.0、GDPR 或 PCI-DSS 对“最小权限”的要求。所有非系统级 bind mount 必须同时包含：
- noexec：阻止执行任意二进制或脚本，防 payload 注入
-
nosuid：忽略 SUID/SGID 位，切断借
/bin/mount或/usr/bin/passwd提权的链路 -
nodev：禁止识别设备节点，规避
/dev/kmem、/dev/fuse类攻击面 -
ro（只读）：默认启用；确需写入时，单独授权最小粒度子目录，并配
umask=022或初始化chown
示例命令：docker run -v /host/data:/app/data:ro,noexec,nosuid,nodev myapp
传播属性必须显式设为 rprivate
合规检查常告警 “mount propagation is shared”，因 shared 可能导致容器退出后挂载残留、卸载失败，甚至被恶意进程反向影响宿主机挂载树。正确做法是：
- 始终使用
--mount语法而非-v，以便指定bind-propagation=rprivate - 避免将 bind mount 源路径嵌套在 NFS/CIFS 或其他远程挂载点下（如
/mnt/nfs/share），防止传播链外溢 - 验证方式：
findmnt -o TARGET,PROPAGATION /app/data输出必须为rprivate，不可是shared或空
运行时身份与能力必须同步收紧
即使挂载参数全合规，若容器以 --privileged 启动或拥有 SYS_ADMIN，所有挂载限制均可被绕过。合规项必须覆盖运行时层：
- 禁用
--privileged，改用精确能力控制：--cap-drop=ALL --cap-add=NET_BIND_SERVICE等按需添加 - 强制非 root 用户运行：
--user 1001:1001，或启用 user namespace remap（--userns-remap=default） - 配合
--read-only启动，再用--tmpfs单独放开/run、/tmp等必要可写路径 - 镜像构建阶段就指定
USER 1001，避免依赖运行时参数补救
不复杂但容易忽略
