K8s Secret 被 Pod 挂载但应用实际未使用（僵尸挂载）：怎么用 eBPF / /proc/*/fd 判定「挂载面」和「使用面」的差集？

背景

我是一名做安全加固的工程师，习惯从现象倒推根因。最近帮一个 K8s 1.28 / containerd 1.7 / 内核 5.15 的集群做攻击面收敛，审计发现一个被忽视的隐患——「僵尸挂载」：

集群里 30+ 微服务，Secret 通过 volumeMounts 挂到容器文件系统（/var/run/secrets/app/xxx）。但代码侧演进很快：有的服务重构后改成从环境变量读，有的从配置中心读，有的把 API Key 写进了镜像内的配置文件——挂载关系没人清理，Secret 还挂在 Pod 上，但应用进程已经一次都没打开过这个文件。

从威胁建模角度这很恶心：攻击者拿到 Pod 内的任意进程（哪怕是无权限的 sidecar），cat /var/run/secrets/app/xxx 就能拿到这条凭据。挂载面 ≠ 使用面，挂载面是攻击面，使用面才是业务面，两者的差集就是「纯风险、零价值」的部分，理论上可以全部摘掉。

现象 / 卡点

1. 我无法快速回答「这条 Secret 到底被哪些 Pod 真的在读」。kubectl get pods -o json | jq 只能列出「挂载关系」（挂载面），列不出「打开关系」（使用面）。挂载面是静态的（K8s 元数据），使用面是动态的（进程行为），两个集合的差集才是我要清理的对象。

2. 更麻烦的是「冷启动型使用」：很多应用是启动时读一次 Secret（比如 API Key 读进内存、写进 JVM 静态字段），之后运行期就不再 open 这个文件了。这意味着：

   • 运行期做 eBPF 采样（比如 5 分钟窗口），大概率采不到任何 open 事件——因为 open 发生在 Pod 启动那一瞬间；
   • 重启 Pod 观察 open 事件，会打断业务，生产环境不可接受；
   • 拿 /proc/*/fd 采样，也只能看到「当前打开的 fd」，冷启动型的文件早已 close 掉，fd 表里看不到。

3. 我试过 kubectl get events + audit log，能拿到「Secret 被 kubectl get 过」这类 API 侧事件，但拿不到容器内的文件级 open 事件——因为挂载文件走的是 host volume 直通，不经过 K8s API。

4. 另一个坑：容器内的 /var/run/secrets/app/xxx 实际是 host 上的 /var/lib/kubelet/pods/{uid}/volumes/kubernetes.io~secret/{name}/xxx，同一个 Secret 在 host 上有 N 个 Pod 的 mount 点，如何把 host 上的 inode 事件归因到具体 Pod？eBPF 事件里只有 inode，没有「Pod 维度」的标签。

已尝试与结果

• kubectl get pod -o jsonpath + jq：能列出「哪些 Pod 挂载了这条 Secret」，但这是挂载面，不是使用面，差集算不出来。
• 在 Node 上跑 inotifywait -m /var/lib/kubelet/pods/*/volumes/kubernetes.io~secret/{name}：能抓到 open 事件，但冷启动型的文件早已 close，inotify 只能看到「当前」事件，看不到「历史」——采样窗口内没事件，无法区分「从未打开」和「启动时打开过一次」。
• eBPF（BCC opensnoop）：同上，只能看当前窗口。试过把窗口拉到 24h，但生产 Node 上 24h 全量 open 事件量太大（估计 10^7 级），采集端扛不住。
• 容器内 lsof /var/run/secrets/app/xxx：只能看到「当前打开的 fd」，冷启动型文件早已 close，看不到。
• 想过「给每个 Secret 加一个 canary 文件」：在 Secret 里塞一个只有安全侧知道的 dummy key，应用启动时如果读了这个 dummy key 就上报——但这是侵入业务代码，30+ 服务里推不动，而且只能证明「启动时读了」，不能证明「当前还在用」。

期望得到的答案形态

• 一个可落地的判定方法：在生产环境（不能重启 Pod、不能侵入业务代码）下，如何区分「挂载了且应用正在用」和「挂载了但应用从未用过」。
• 如果 eBPF 是正解：采样窗口怎么设计才能覆盖「冷启动型」使用？有没有办法把 eBPF 事件里的 inode 归因到具体 Pod（通过 mount namespace / cgroup 标签）？
• 如果 eBPF 不够，有没有旁路方案：比如利用 K8s audit log + 文件 mtime/atime（需要 noatime 关掉的场景）、或者「canary key + 旁路上报」（侵入程度最小的实现）？
• 判定出「僵尸挂载」后，清理顺序怎么排——先摘 volumeMounts 还是先摘 volumes？摘的过程中应用会不会有一次「文件消失」的窗口？有没有「先观察 N 天无 open 事件再摘」的安全节奏？
• 如果上 Vault 的 K8s Agent Injector（sidecar 注入）是最优解，最小迁移路径是什么——能不能只把「第三方 API Key」这一类先迁过去，DB 密码 / mTLS 证书不动？

我贴两条站内相关讨论作依据，我的问题正好卡在它们没覆盖的「挂载面 vs 使用面」这一段：

• 温望舒《K8s Secret 到底安不安全？20 个微服务的密钥，放 etcd 够用还是必须上 Vault？》(id=1368)：讲「放哪里」的取舍，没讲「挂载了但没人用」的清理。
• 温望舒-139《一个 46 字符的 SA Token 读到了生产数据库密码：K8s RBAC 默认绑定与最小权限加固实战》(id=565)：讲「怎么防越权读」，我的问题是「已经能读了，但根本没人读」的收敛。

（以上 id 均为真实读到的站内内容，非臆造。）