K8s 里 Secret 挂载成文件后，core dump / /proc/PID/environ 仍可能把密钥带出去——有没有「只进内存、不落盘、不进 /proc」的落地方案？

背景： 我做了 5 年安全加固，最近给一个 K8s 1.28（containerd 1.7、内核 5.15）的多租户 SaaS 做凭据管理加固。现在所有服务的密钥（数据库密码、第三方 API key、TLS 私钥）都是这么走的：

• 写进 K8s Secret（base64，等于没加密）
• 要么 envFrom: secretRef 注入成环境变量，要么 volume 挂载成文件
• 业务进程用 os.environ / 读文件取走

我的核心担忧是「落盘 + 进进程环境」这两件事：密钥一旦以文件形式躺在容器里，或挂在进程环境里，就有三条泄露通道我没法封死——

1. core dump / 崩溃日志把内存里的密钥带出去（尤其 C/C++/Go 服务 panic 时）；
2. /proc/PID/environ 和 /proc/PID/maps（内存映射）在容器内同 UID 用户或具备 SYS_PTRACE 的情况下可读；
3. 任何一次 kubectl exec / 调试镜像里的 env 命令，密钥直接回显。

现象： 我们做季度渗透时，安全组用一条 kubectl exec <pod> -- cat /proc/1/environ 就把生产 DB 密码捞出来了——因为那个 Pod 是 root 跑的，exec 进去就是全权限。事后复盘，问题不在「谁 exec」，而在「密钥本来就躺在一个能被 exec 直接读到的地方」。

已尝试的排查与结果：

1. 把 Secret 从 env 改成 volume 挂载成文件——好了一点（不进 /proc/environ），但文件还在，core dump 和 exec cat 照样能读，没根治；
2. 引入 Vault + Vault Agent Injector——调研后发现 Agent 默认还是把 token/密钥写成文件（/vault/secrets/），等于换了个地方落盘，/vault/secrets 一样能被 exec 读到，我卡在这儿了；
3. 查了 K8s 的 Ephemeral Volume / 内存文件（把 secret 挂到 tmpfs）——发现挂载点只要进程能读，cat 还是拿得到，tmpfs 只是不落「物理盘」，但「进可读内存/文件」这个本质没变；
4. 想过用 libinjector / 进程内直接拉 Vault（SDK 取，不落文件），但担心：进程崩溃时内存里的密钥照样进 core dump，而且每个服务都要改代码接 SDK，改造成本很高。

我现在的判断是：只要密钥以「文件」或「进程环境」的形式存在，且容器允许 exec / 能读 /proc，就一定存在泄露面。我想找的是「密钥只以短期 token 形式存在、真正的主密钥留在 Vault/KMS 侧、进程拿到的是一句可过期的引用而非明文」这类架构，但不知道怎么在 K8s 里具体落地。

期望得到的答案形态（希望具体、可复现）：

• 请给一条在 K8s 里让密钥不落盘、不进 /proc、且 exec 拿不到明文的推荐路径，最好带具体配置/命令（Vault Agent 的 memory 模式？CSI driver + 短期 token？AppRole + 进程内 SDK + 禁用 core dump 的组合？）；
• 针对 core dump 泄露，ulimit -c 0 / noexec 挂载 / seccomp 禁 ptrace 这几招各自能封住哪条通道、哪条封不住，请说清楚；
• 如果是「短期 token + KMS 侧持主密钥」模型，请给一个最小可跑的示例（Vault 策略 + Agent Injector 注解 + 业务侧取 token 的代码片段），别只给概念；
• 如果结论是「K8s 原生做不到，必须上 Vault/KMS + 进程内 SDK」，请说明改造成本和有没有更轻量的中间态（比如只把 DB 密码走 Vault、其余保持文件挂载的分层策略）。

我引用的两条站内内容，和我的问题同属「凭据/密钥在容器里怎么放」这条线，供参考上下文：

• 站内有篇讲镜像分层里 .env 密钥泄露链与加固的文章（id=1450）——它解决的是「密钥烘进镜像层」这条通道，和我这里「密钥挂在运行期 Pod 里」是相邻但不同的问题；
• 还有一篇容器镜像「可调试 vs 够安全」取舍的讨论（id=462）——它引出的「调试要能进容器」和我的「exec 能直接读密钥」正好是同一枚硬币的两面，想听听大家在这条线上怎么平衡。