核心目标是防止容器内进程篡改宿主机关键文件以提升安全性；推荐对配置文件、SSL证书、静态资源等路径使用:ro挂载，正确写法为-volumes中直接添加:ro后缀，需配合非root用户、权限加固等措施并验证Read-only file system错误。
在 docker-compose.yml 中使用 :ro（即 read_only）挂载模式，核心目标是防止容器内进程意外或恶意修改宿主机上的配置文件、证书、静态资源等关键内容，从而提升部署安全性与稳定性。
明确哪些路径该设为只读
以下几类路径强烈建议用 :ro 挂载：
-
配置文件：如
nginx.conf、redis.conf、自定义的.env或application.yml -
SSL 证书与私钥：如
example.com.crt和example.com.key，Nginx/TLS 终端只需读取，绝不应写入 - 静态资源目录：如前端 HTML/JS/CSS 文件夹，运行时无需更新
-
Terraform 模板或 IaC 代码：如 Blast Radius 的
./data目录，避免执行中被覆盖
正确写法与常见误区
:ro 是简写形式，功能等同于 read_only: true。但要注意语法位置和层级：
- ✅ 正确（volumes 列表中直接加
:ro）：- ./config/nginx.conf:/etc/nginx/nginx.conf:ro - ❌ 错误（在 volumes 下单独写
read_only: true，YAML 结构不合法）：- ./config/nginx.conf:/etc/nginx/nginx.conf<br> read_only: true
- ⚠️ 注意：若使用
volume块定义（非 inline 简写），才需显式写read_only: true，但日常推荐简写更清晰
配合其他安全措施效果更佳
仅靠 :ro 不足以构建完整防护，需组合使用：
-
非 root 用户运行：即使挂载可写，也无权限修改系统路径；在服务中添加
user: "1001:1001" -
最小能力集：用
cap_drop移除不必要的 Linux capabilities，如- ALL+ 仅保留必需项 -
环境变量隔离：敏感配置（如数据库密码）不用
environment明文传，改用secrets或env_file并限制读取权限 -
宿主机文件权限加固：确保
./certs/或./config/在宿主机上属主明确、权限严格（如600证书私钥）
验证只读是否生效
启动容器后，可进入容器内部快速验证：
- 执行
touch /etc/nginx/nginx.conf.test—— 应报错Read-only file system - 检查挂载信息：
mount | grep nginx.conf，输出中应含ro,标识 - 查看进程权限：
ls -l /etc/ssl/private/，确认文件属主和权限未被容器内进程篡改
