准入控制器故障时如何平衡发布与安全?

准入控制器故障时，最先暴露的往往是一个早已存在、只是平时被忽略的配置项：failurePolicy。webhook 不可用，设为 Fail 会阻断 Pod 创建，发布流水线整条停住；设为 Ignore 则放行未经验证的工作负载，安全门禁形同虚设。很多团队在故障发生的那一刻才第一次认真讨论这个取舍，而这时留给判断的时间通常只有几分钟。

真正需要先厘清的是两种失败模式的性质不同。Fail 换来的是可用性风险，业务明确感知，压力直接；Ignore 换来的是安全风险，静默、延迟、难以追溯。二者无法用一句“更安全”来排序，能做的只有把风险按策略类型分级。签名与摘要校验属于供应链的根，一旦失效，等于允许任意镜像进入集群；而清单字段的兜底校验，在故障期放行的后果相对可收敛，因为运行时的策略与审计仍能补位。因此“所有策略共用一个 failurePolicy”本身就是设计缺陷，需要按规则拆开设定。

比选择更关键的是预案是否提前写好。故障恢复动作应当明确到可执行：是临时把策略切回 Audit，还是调整 failurePolicy，二者都会放行未验证工作负载，区别在于前者保留了策略报告，后者连证据都不留。无论选哪种，都要限定时间窗口、记录操作人，并在恢复后补做验证——把故障期创建的负载重新纳入检查。手工在集群里直接改资源配置应当被明确禁止，回滚统一走 Git revert 到上一版可用策略。

平时的准备决定了故障时的余量。新策略先在 Audit 模式运行，观察命中对象与拒绝原因是否合理，再切到 Enforce；签名密钥轮换采用新旧公钥并存的过渡窗口，避免旧镜像因轮换瞬间全部验签失败；策略仓库保留最近若干个可用版本，让回滚目标清晰。监控上，准入拒绝率的突增和 webhook 延迟的变化是最直接的信号，前者可能是策略过严，也可能是有人绕过 CI 直接提交清单，两者处理方式完全不同。

还需要承认边界：这条门禁链解决的是“进入集群前是否可验证、是否按既定策略被强制”，并不等于供应链安全的全部。故障期放行本身不可怕，可怕的是放行之后没有补偿动作。把 failurePolicy 的取舍当作一次性配置，还是当作需要演练的运行预案，决定了下一次 webhook 抖动时，团队是在慌乱中二选一，还是按既定路径稳稳走完。