用命名空间隔离PSA例外工作负载

把 restricted 推进到生产环境时，真正卡住的往往不是核心业务，而是那些看起来不该出现在业务命名空间里的工作负载：日志采集器、监控代理、网络插件，或者某个以特权模式运行的旧组件。此时最常见的处理方式，是把整个业务命名空间的 enforce 调低，让少数 Pod 得到通过。这是 PSA 落地过程中最容易被低估的失败模式。一旦这么做，原本用于区分信任级别的边界就会失效，而且几乎无法重新收紧。

PSA 的策略粒度只有命名空间，没有工作负载级的例外机制。这个限制与其说是缺陷，不如说是设计意图：它要求把“谁需要更高权限”显式表达为命名空间边界，而不是在同一个命名空间里维护一份不一致的豁免清单。

先分清改不动和不想改

restricted 触发的告警大致分两类，处理方式完全不同。

一类是工作负载自身的配置问题：未声明以非 root 运行、未关闭权限提升、未丢弃全部能力、缺少 seccomp 配置。这些属于改造项，调整镜像的运行用户、文件属主或挂载卷权限即可解决。它们不该被当成例外，把它们放进宽松命名空间，等于用边界掩盖配置债。

另一类是结构性依赖：hostNetwork、hostPID、hostIPC、hostPath 卷，以及 privileged: true。这类工作负载本质上是节点级组件，改造它约等于重写运行模型。只有这一部分才构成真正的例外。

例外命名空间按隔离强度分层

不建议只建一个 exception 命名空间来容纳所有例外工作负载。依赖主机命名空间的采集类组件，baseline 通常已经够用；真正需要 privileged 的系统组件才应单独承载。按隔离强度分层，例外的范围才可控。

每个例外命名空间都应显式设置 enforce，同时保留 audit 和 warn 指向同一层级。显式设置比留空更安全：留空意味着使用集群默认策略，而这个默认值会随版本演进而漂移，原本合规的工作负载可能在某次升级后突然被拒绝，而且没人知道该改哪里。

还要考虑准入侧。谁能往例外命名空间提交工作负载，需要额外的审批或准入约束，否则它很快会变成什么都能塞进去的收集点，restricted 的覆盖面被一点点侵蚀，而这个过程通常没有告警。

例外命名空间的数量和其中工作负载的规模，本身就值得当作指标来观察。每新增一个都应有明确理由，并在评审时被追问：这个依赖是暂时的，还是永久的。

命名空间隔离的价值不在于给例外开绿灯，而在于让例外可见、有边界、可回滚。撤销一个标签就能恢复强制，不必翻遍清单去找哪个 Pod 多拿了一项能力。做到这一点，PSA 才从一次性的加固动作，变成能长期维护的策略。