只读挂载（:ro）通过内核级强制策略阻断容器对宿主机挂载路径的写入，卡住后门持久化环节，需配合路径精准控制与权限预置，是轻量关键的安全边界。
在 Bind Mount 流程中，通过显式设置 :ro（只读）挂载选项，能有效切断容器内开源软件对宿主机关键路径的写入能力，构成一道轻量但关键的安全边界。它不依赖复杂策略或特权控制，而是从数据流向本身做“物理隔离”，尤其适用于运行来源不明、更新频繁或社区维护型开源工具的场景。
只读挂载如何阻断后门写入链
多数开源后门（如恶意 nc、反弹 shell 脚本、配置篡改器）需完成三步才能扎根宿主机：读取敏感文件 → 修改配置或注入代码 → 持久化到磁盘（如写入 /etc/passwd、~/.ssh/authorized_keys、/var/www 或用户项目目录）。Bind Mount 的 :ro 选项直接卡在第三步——只要挂载点被声明为只读，内核会拒绝所有 write()、open(O_WRONLY|O_RDWR)、mkdir() 等系统调用，无论容器进程是否以 root 身份运行。
- 即使容器内程序拥有
cap_sys_admin或其他 capabilities，也无法绕过 VFS 层的只读挂载检查 - 不同于容器用户权限控制（如
--user），:ro 是内核级强制策略，不受容器内 UID/GID 映射影响 - 对静态资源目录（如配置模板、证书、前端资产）尤其适用，既保障程序可读，又杜绝“顺手写个 webshell”的风险
实际部署要点与常见陷阱
只读不是加个 :ro 就万事大吉。需配合路径设计与权限预置，否则程序启动即失败，反而暴露配置缺陷。
- 宿主机路径必须提前存在且权限合理：Docker 不再自动创建目录（23.0+ 版本），若挂载点不存在会报错；若存在但属主不可读，容器内进程将无法打开文件
- 区分“只读挂载”和“只读文件系统”：挂载点本身是只读的，但宿主机该路径下其他未挂载子目录仍可被访问（除非额外限制）；因此应确保挂载路径足够精准，避免挂载整个
/home或/opt - 避免挂载点重叠：例如同时挂载
/host/config:/app/config:ro和/host:/mnt/host:rw，后者会覆盖前者只读语义，导致绕过 - 组合使用
--read-only容器级开关：进一步禁用容器根文件系统写入，形成双重防护（注意需显式挂载/dev/shm、/proc等必要 tmpfs）
典型安全加固示例
以运行一个社区版 AI 工具镜像（如某开源 LLM Web UI）为例，其需读取模型权重和提示模板，但绝不应修改用户家目录：
- 将模型目录
/data/models/llama3-8b挂载为只读：-v /data/models/llama3-8b:/app/models:ro - 将提示模板
/etc/ai/prompts/挂载为只读：-v /etc/ai/prompts:/app/prompts:ro - 禁止挂载用户主目录、
/home、/root或任何含 SSH 密钥/凭证的路径 - 若工具需临时输出日志，应挂载专用空目录并设为可写：
-v /var/log/ai-ui:/app/logs:rw，而非复用宿主机/var/log
局限性与补充建议
:ro 只防御“写入宿主机挂载路径”这一条路径，不能阻止其他逃逸方式：
- 无法拦截容器内进程通过网络连接外泄数据（需配合网络策略或 eBPF 过滤）
- 无法防止利用 CVE-2026-31431 类内核漏洞提权后绕过挂载限制
- 无法阻止攻击者通过 D-Bus、
/run/user/$UID或环回 socket 与宿主桌面环境通信
因此，:ro 应作为最小权限实践的第一层，搭配非 root 用户运行（--user 1001:1001）、禁用 capability（--cap-drop=ALL）、关闭 ServiceAccount Token（K8s 场景）等共同构成纵深防御。对于高敏环境，可进一步用 Bubblewrap 构建命名空间沙箱，在进程启动前就裁剪可见路径，比 Bind Mount 更早介入控制面。
