K8s 容器做「非 root + 只读根文件系统」加固，怎么系统性找出「隐性写依赖」而不靠人肉 strace？

【背景】 我负责一套 K8s 1.28（containerd 1.7、kernel 5.15）上约 50 个微服务的安全加固。安全基线里有一条硬要求：业务容器必须「非 root 运行 + 只读根文件系统（readOnlyRootFilesystem: true）+ 最小 capabilities」。我习惯从现象倒推根因，所以想先把「加固是否真正落到运行时、适配成本能不能收敛」这件事做实，而不是逐应用拍脑袋改。

【现象】 逐应用适配后发现，问题不在「能不能开」，而在「开了以后哪几个应用会炸、为什么炸、怎么系统性找出来」。具体踩到的隐性写依赖：

1. JVM 系服务：开 readOnlyRootFilesystem 后直接起不来，报 /tmp（java.io.tmpdir）相关 EROFS；有些基础镜像把日志目录硬编码在 /usr/local/app/logs（根文件系统内），没挂 volume。
2. 基础镜像默认以 root 启动：某些 node / python 镜像的 entrypoint 里有 chown、写 /etc、/usr/local/share 的初始化逻辑，非 root 后直接 EACCES。
3. 安装期写缓存：个别镜像在容器启动时还跑 npm ci / pip install（本应在构建期完成），写 ~/.npm、~/.cache，只读后失败。
4. 凭据/证书挂载路径权限：cert-manager / Vault 注入的 secret 挂载目录，对非 root uid 的权限不友好，chmod 失败。

【已尝试的排查与结果】

• 逐应用改 Dockerfile：加 USER、把可写路径改成 emptyDir / volume。能解决单点，但 50 个应用每个都不同，纯人肉，新应用进来还会再踩一遍，没沉淀。
• strace -f -e trace=write,openat 抓写路径：能抓到，但前提是容器得先跑起来——只读模式下它根本起不来，陷入「起不来就抓不到、抓不到就不知道怎么改」的死循环。
• auditd / sysdig 枚举写目标：思路对，但节点侧采集配置繁琐，没形成可复用的 SOP。

【期望得到的答案形态】 希望做过同类加固的朋友给出可复现的方法，最好包含：

1. 「写路径探测」的系统方法：有没有办法在容器「只读试跑」失败的前提下，依然枚举出它想写哪些路径？比如故意以只读启动、抓 EROFS / EACCES 的 syscall 现场，或用 auditd 规则枚举 openat 写目标，而不是靠人肉 strace。
2. 一张「兼容性矩阵」模板：JVM / Node / Python / Go 各类运行时，在非 root + 只读下各自要放行/挂载哪些路径（/tmp、/var/log、缓存目录），有没有现成对照表或脚本。
3. 「只读真的生效」的验证方法：怎么在运行时确认容器确实处于只读根文件系统、而不是被 runtime 或 entrypoint 绕过了？我认同社区里 seccomp「加固是否真生效」那条验证思路，想把它延伸到文件系统权限这一层。
4. 如果逐应用适配成本实在收敛不了，「基础镜像层统一做只读适配、上层应用零改动」的方案是否可行？踩过什么坑？

有现成 SOP、脚本或 config 片段，直接贴出来最好。