把准入拒绝信息写成可操作的修复指引

策略生效之后，开发者看到的第一条反馈往往只有一句“policy violated”。这句话解释不了任何事：他不知道该重新签名、把镜像引用改成 digest，还是删掉清单里某个字段。于是最省事的路径就是申请例外，例外攒多了，准入层就名存实亡。准入拒绝信息其实是策略系统里最少被评审、却直接影响执行效果的产物。

按失败类型分开表述

一条可操作的拒绝信息，首先要让人判断出失败属于哪一类。在门禁链里至少存在四种互不相同的拒绝：镜像用了可变 tag、签名身份不受信任、签名与摘要不匹配、清单字段越权。它们的修复动作完全不同——前者改清单更新流程，中间两者回到 CI 重新签名或重新附加证明，最后一类改 YAML。把这些混成一句“验证失败”，等于要求开发者自己去猜。

给出定位所需的键

有效的信息需要能被检索。规则名应当与 Git 中策略仓库里的命名保持一致，让值班人员从错误信息直接跳到策略文件；同时给出被拒的资源、具体字段路径、期望值与实际值。这样“签名身份不匹配”才不是一句结论，而是一个可以核对的差异。反过来，不要把公钥内容、整段策略或完整扫描报告塞进拒绝信息——准入位于关键路径上，消息越长，Pod 创建延迟和排查噪声越高。

解释性的部分应当留在 CI：Trivy 的报告、KubeSec 给出的修改建议放在流水线日志里，开发者在那里能看到完整上下文；准入层只保留最小可行动作和一个指向内部策略文档的规则标识。两层各司其职，信息才不会重复到互相稀释。

用 Audit 预演文案

拒绝信息的质量可以在切换 Enforce 之前检验。策略以 Audit 模式运行时，报告里的原因描述就是将来拒绝信息的预演；如果报告里的措辞自己团队都读不懂，说明文案还没准备好，不该急着收紧。同样需要区分的是策略拒绝与 webhook 不可用导致的失败，两者报错形态相近但处置完全不同，混在一起会让排查方向偏掉。

拒绝信息和策略本身一样应该进 Git、走评审、可回滚。措辞的改动会改变团队下一步的行为路径，它属于策略契约的一部分，而不是事后补的一句提示。