Pod安全准入如何平稳切换到拦截?

把命名空间的 enforce 标签从无到有，是 Pod 安全准入里风险最高的一次变更。它最容易让人误判的地方在于：PSA 不会追溯已经运行的 Pod，只在新 Pod 创建或重建时生效。于是变更当天一切正常，直到某次发布、扩缩容或节点故障触发重建，旧配置才被拦下，故障延迟爆发。平稳切换的关键，不是把标签改对，而是让这次变更的后果在被拦之前就暴露出来。

让审计数据替你决策

切换前不该直接改 enforce，而应让 audit 和 warn 先跑足够长的观察周期。审计记录会告出哪些工作负载会被拒、拒绝发生在哪个命名空间、属于哪类规则。这一步需要区分真正的违规与审计噪声：面向外部流量、处理凭据或挂载敏感卷的负载，与内部批处理任务的风险权重完全不同，优先处理前者。

盘点的粒度也要够细。PSS 检查的是普通容器、初始化容器和临时容器三类字段，逐一看 YAML 容易漏。用结构化扫描一次性拉出所有显式配置，比肉眼翻清单可靠；像 procMount 的 Unmasked 这种字段，既不显眼也不一定导致启动失败，最容易被跳过。

在模板层收敛，而不是在运行中的 Pod 上

确认违规后，改动必须落在 Helm、Kustomize 或平台控制器的模板里。只修补运行中的 Pod 没有意义，下一次发布会把旧配置原样带回来，问题只是被推迟。模板改完再逐条做服务端 dry-run 验证，这是唯一能在切换前预知拒绝结果的手段，不要靠记忆判断某个基线版本一定放行。

确实需要放宽的负载，也不该把整个命名空间降到特权级别。用独立命名空间承载、配合豁免策略和审批记录，把例外的范围压到最小，是更可控的做法。

保留回退路径，但别把它当终点

切换窗口内保存变更前的原始清单，出问题时能直接应用回去，而不是在运行中的 Pod 上手工修补。如果回退被准入层挡住，说明策略正在按预期工作，此时可以在受控时间窗内临时退到 warn 或 audit，并记录原因、范围与恢复时间。

切换是否成功，衡量标准不是标签改成了什么，而是重建后的应用错误率、重启次数、诊断工具是否仍在正常工作，以及每一条准入拒绝事件是否都有明确的解释。回滚只恢复可用性，不取消加固目标；事后仍要查清应用为什么依赖那些被收窄的配置，再决定是改造应用还是保留一个有边界的例外。