只读挂载不能防止后门，但能收窄攻击面，使恶意写入在系统调用层失败；必须保护的路径包括配置目录、静态资源、证书密钥、启动脚本等；需避免挂载父目录、权限过宽、保留高权限等失效陷阱，并配合tmpfs、--read-only、用户命名空间等机制强化隔离。
只读挂载本身不能防止后门篡改宿主机，但它能有效阻断容器内恶意进程通过挂载点反向写入宿主机关键路径。关键不在于“防后门”，而在于“收窄攻击面”——把本不该被写的目录变成不可写，让篡改行为在系统调用层直接失败。
哪些目录必须设为只读
优先保护那些容器只需读取、绝不应修改的宿主机路径：
-
配置文件目录：如
/etc/nginx、/opt/app/conf，防止运行时被注入恶意配置 -
静态资源或模板：如
/usr/share/nginx/html、/templates，避免页面被替换为钓鱼内容 -
证书与密钥文件：单独挂载
/certs/tls.crt和/certs/tls.key并设为:ro，阻止私钥被覆盖或导出 -
启动脚本或二进制依赖：例如挂载
/scripts/entrypoint.sh，防止被替换成带外连逻辑的版本
正确配置只读绑定挂载
两种等效写法，推荐长语法（更清晰、可扩展性强）：
短语法（兼容旧版）：
-v /host/conf:/etc/conf:ro
长语法（docker-compose.yml 中推荐）：
volumes:
- type: bind
source: /host/conf
target: /etc/conf
read_only: true
注意：:ro 仅作用于该挂载点，不影响容器根文件系统或其他卷；它由内核 VFS 层拦截写操作，和容器内用户权限无关——即使进程是 root，写入也会返回 Read-only file system 错误。
避开常见失效陷阱
只读不是万能盾，以下情况会让防护形同虚设：
- 挂载了整个父目录（如
/host），但只对子路径设:ro—— 攻击者可能绕过目标路径，在同级创建新文件并诱导应用加载 - 宿主机路径权限过于宽松（如
/host/conf所有者是777），虽然容器内写失败，但宿主机上其他进程仍可篡改，失去隔离意义 - 未限制容器能力，比如保留
CAP_SYS_ADMIN，攻击者可能卸载只读挂载再重新挂载为可写 - 错误地将日志、临时目录也设为只读（如
/var/log或/tmp），导致应用启动失败，反而暴露异常行为
配合其他机制加固效果
单靠只读挂载不够，需组合使用：
- 对必须可写的目录（如
/var/log），改用tmpfs挂载，内存存储、重启即清，避免落盘留存恶意日志 - 用
--read-only启动容器，让整个根文件系统只读，再显式挂载需要读写的路径（如/tmp、/run） - 结合用户命名空间（
--userns-remap）和非 root 用户运行容器，进一步限制容器内进程对宿主机路径的潜在影响范围
