安全上下文审查别只盯procMount

集群安全上下文检查里，有一幕挺常见：搜出 procMount 字段，看到 Unmasked 就改回 Default，然后觉得这一项算是结案了。这状态有点像出门查门窗，只伸手按了按其中一扇窗——按过了，不代表整栋房子都关严了。

先得弄清楚这个字段管的事有多大。容器里的 /proc 是内核暴露给进程的窗口，Kubernetes 默认挂载的是带掩码的版本，把一部分敏感节点遮住，缩小攻击面。当工作负载在 securityContext.procMount 里写了 Unmasked，这层遮罩就被绕开，容器会看到更接近宿主机的视图。Pod Security Standards 的 baseline 与 restricted 对它只有一种许可：未定义、nil 或 Default。所以 Unmasked 确实是个该单独解释的例外，改了它也确实有意义。

但掩码不是隔离边界。它主要减少 /proc 里敏感信息的暴露面，替代不了最小权限、只读根文件系统、seccomp、能力裁剪、运行时沙箱和节点隔离。反过来更值得记一句：移除 Unmasked 不等于这个工作负载就安全了，只是把一个容易被忽略的细节收回到默认基线而已。

真正该做的，是把 procMount 放回它所在的那一格里，和同一个容器的 privileged、hostPID、hostPath、能力集合一起看。一个容器的 procMount 老老实实是 Default，可特权模式开着、宿主机路径挂着，风险等级完全是另一码事。反过来，那些特别显眼的开关，反而容易被"一直这么跑也没出过事"磨掉警惕心。

审计时容易漏的两块

一是容器类型。PSS 对普通容器、初始化容器、临时容器三处的 procMount 都有限制，只扫 spec.containers 会漏掉后两类，而这两类恰恰最不常被人翻开看。

二是准入层的实际行为。围绕 Unmasked 和用户命名空间条件，上游社区做过准入层面的调整，不同集群版本、特性门控和 PSA 配置下表现可能不一样。凭记忆断定"baseline 一定拦"或者"restricted 一定放行"，风险不小；更稳的做法是在目标集群上用 dry-run 或审计模式先看真实结果。

还有一个容易走偏的地方在命名空间标签上。只挂了 warn 或 audit 的命名空间，违规配置可能只是被记录，并没有被真拦住。而且 PSA 不会回头修改已经跑着的 Pod，配置收敛之后得靠重建让新 Pod 生效，否则改了清单也等于没改。

说到底，procMount 只是安全上下文这张清单里的一项。它值得查，但不该是查完就收工的那一项。