核心是分层控制：构建阶段隔离源码、运行时挂载点强制只读、关键路径防绕过，并叠加签名与扫描形成可信闭环。
配置容器通过只读挂载点安全消费公共代码资产，核心是**让业务容器能读取外部共享代码（如 SDK、工具库、配置模板），但无法篡改、覆盖或泄露宿主机或镜像层内容**。这不是简单加 :ro 就完事，而需分层控制：镜像构建阶段隔离源码、运行时挂载点强制只读、关键路径防绕过、配合签名与扫描形成闭环。
构建阶段：确保公共资产不“混进”镜像层
公共代码资产（如开源 SDK、CLI 工具包、通用配置模板）不应直接 COPY 进最终镜像——否则一旦镜像被导出或误传，资产可能被提取、修改甚至反向工程。
- 用多阶段构建：在 builder 阶段下载/解压/校验公共资产，仅将验证后的二进制或编译产物复制到 runtime 阶段；原始压缩包、.git 目录、build 日志等全部丢弃
- 禁用构建时写入敏感路径：避免
RUN echo 'export PATH=...' > /etc/profile.d/sdk.sh，这类操作会把可写配置固化进镜像层；应改用ENV或运行时挂载 - 对资产做哈希校验：构建时用
curl -sL $URL | sha256sum -c sdk.sha256，失败则中断构建，防止中间人污染
运行时：只读挂载 + 显式路径约束
真正消费公共资产，应在容器启动时通过挂载方式注入，并确保其只读语义不可绕过：
- 使用
-v /host/sdk:/opt/sdk:ro挂载宿主机上预置的已校验 SDK 目录；不要挂载父目录（如/host:/mnt），否则应用可通过..跳出限制 - 若资产来自配置中心或对象存储，优先用 init 容器下载后写入 emptyDir（
emptyDir.medium: Memory），再以readOnly: true挂载给主容器——内存盘天然不落盘、重启即清空 - 对挂载点做权限加固：挂载后执行
chmod 555 /opt/sdk（移除写+执行位），并确认ls -ld /opt/sdk输出中无w字符；若用docker run --read-only，该挂载自动继承只读，无需额外 chmod
防逃逸：阻断常见绕过路径
只读挂载本身可被某些手法绕过，必须主动封堵：
- 禁止挂载点父目录可写：比如挂载
/opt/sdk，要确保/opt在原始镜像中就是只读的（可用--read-only全局启用），否则攻击者可rm -rf /opt/sdk && mkdir /opt/sdk创建同名可写目录 - 不挂载
/etc或/usr等系统路径：这些目录下存在大量符号链接和动态加载机制，容易引发意外行为；公共资产应统一放在/opt、/usr/local/share等语义明确的只读区 - 禁用容器内 package manager：在 runtime 镜像中删除
apt、pip、yum等工具，或设为不可执行（chmod -x /usr/bin/pip），防止运行时偷偷安装/覆盖依赖
可信链：从拉取到加载全程验证
只读只是访问控制，不是信任保障。必须叠加可信机制：
- 镜像拉取前校验签名：用
cosign verify --certificate-oidc-issuer=https://token.actions.githubusercontent.com --certificate-identity-regexp=".*github\.com.*" your-registry/sdk-base:1.2 - 挂载资产前校验完整性：在容器 entrypoint 中加入
sha256sum -c /opt/sdk/SHA256SUMS 2>/dev/null || exit 1 - CI/CD 流水线中集成 Trivy 扫描：对挂载的 SDK 目录做离线 SBOM 分析，检测已知漏洞（如
trivy fs --security-checks vuln,config /host/sdk）
