容器根文件系统只读需协同用户权限、能力控制与挂载策略：启用--read-only后，须显式挂载/tmp等必要可写路径，配置文件只读挂载并配非root用户，密钥用--secret，禁用sys_admin等能力，定期审计验证。
让容器根文件系统只读，不是加个 --read-only 就完事；它必须和用户权限、能力控制、挂载策略协同生效，否则可能启动失败、功能异常，甚至形同虚设。
根文件系统只读：从启动就锁定写入
使用 docker run --read-only 可强制容器根目录（/）以只读方式挂载。此时任何对 /tmp、/var/run、/etc/hostname 等路径的写操作都会被内核拒绝，报错 Read-only file system。
但业务往往需要临时写入——正确做法是显式放开必要路径：
- 用
--tmpfs /tmp:rw,size=64m提供内存级可写空间 - 对日志目录，用
-v /host/logs:/var/log/app:rw单独挂载可写卷 - 避免使用
--privileged或--cap-add=SYS_ADMIN绕过只读限制
配置文件与敏感数据：只读挂载 + 权限隔离
配置文件（如 nginx.conf、application.yml）应始终以只读方式挂载，防止运行时被篡改。在 Docker Compose 中明确声明 read_only: true：
volumes:
- type: bind
source: ./config/app.conf
target: /app/config/app.conf
read_only: true
同时确保宿主机上该文件属主为非 root、权限为 644，并配合容器内非 root 用户运行（USER 1001），实现双重防护。
密钥、证书等敏感内容绝不用 ENV 注入，优先使用 --secret（Swarm）或 --mount type=secret（CLI），它们天然以只读方式挂载在 /run/secrets/ 下。
企业合规关键点：不可变性 + 审计可追溯
金融、政务等强合规场景要求“配置不可篡改、行为可审计”。只读策略需嵌入完整生命周期：
- 镜像构建阶段：基础镜像选用
slim或distroless，删除/bin/sh、apt等写入工具 - 运行时加固：启用
--cap-drop=ALL --cap-add=NET_BIND_SERVICE，禁用chown、chmod等破坏只读语义的能力 - 操作留痕：所有容器启动命令记录到 CMDB 或审计日志，包含是否启用
--read-only、挂载哪些可写路径等字段 - 定期验证：通过脚本检查运行中容器是否实际启用只读（
docker inspect $id | jq '.HostConfig.ReadonlyRootfs'）
常见失效场景与规避方式
只读设置容易因细节疏忽而失效：
- 挂载
bind卷时未设read_only: true，即使根只读，仍可通过挂载点写入宿主机 - 容器内进程以
root身份运行，可调用mount --remount,rw /（需SYS_ADMIN能力，故务必--cap-drop=ALL） - 使用
volume类型默认可写，若误用于配置目录，将失去只读保护意义 - 未清理构建缓存，Dockerfile 中
RUN echo 'xxx' > /etc/config留下可写层，绕过运行时只读
