策略在哪里执行

一句话总结

Pipeline 提供快速反馈，admission 执行 API 请求策略，持续检查发现既有资源违规。存在策略与实际检查过请求不是一回事。

为什么一处不够

支付团队 CI 拒绝未签名镜像，但运维从其他路径部署时 CI 不运行；只用 admission 又会到构建结束才发现错误；新策略也不会自动修正既有 workload。应连接三个位置，但不要复制三份规则，而要管理公共规则版本、例外清单及每处实际检查输入，并观测适用对象数、违规数、检查错误和例外过期。

工作原理

位置	证据	单凭它不知道
CI	digest、规则版本、退出码	绕过 CI 的 API 请求
admission	请求、范围、允许或拒绝	旧资源当前违规
持续检查	时间、对象总数、违规列表	下一请求是否一定被拒绝

admission 保证只覆盖匹配请求和配置范围。要检查 namespaceSelector、资源与操作 selector、例外和 Webhook 错误处理。failurePolicy: Ignore 只在调用错误时放行，不会把 Webhook 正常返回的明确拒绝改为允许；Fail 在错误时也拒绝，因此必须设计可用性与恢复路径。参阅Kubernetes 动态 admission。

mutating 先于 validating。若变更补齐必要标签，验证会检查变更后的最终对象并允许，这不表示验证未运行。

策略 Audit 模式不等于 API audit log

策略引擎 Audit 用于观察违规和评估引入影响，功能及旧资源范围依引擎而异；Kubernetes API audit log 记录请求活动，开启日志不会阻止违规，也不会重扫所有旧资源。

引入计划要写观察期、修复负责人、转强制条件。例外要有对象、原因、批准者、到期日，并确认到期真实执行。不要把紧急例外变成永久 Namespace 排除。

NetworkPolicy 与 mTLS 不互相替代

标准 NetworkPolicy 主要限制 L3/L4 连接范围，用标签、IP、端口选择对象，不提供 TLS 加密或证书双向认证。Service mesh 或应用 mTLS 认证身份并加密；能执行什么仍需 authorization policy。参阅Kubernetes NetworkPolicy 范围与限制。

还需要能执行 NetworkPolicy 的网络插件。标准语义下，某方向未被策略选择的 Pod 在该方向不隔离，实际可达性还受其他防火墙和平台策略影响。引入默认拒绝前要列出 DNS 与必要依赖流量，在隔离环境测试，不能直接全局切断连接当作验证。

现场表现

签名验证持续成功，但策略只选择 team-a，真实服务在 team-b；只读成功报告会漏掉空范围。应先建测试表：应允许请求必须成功，同目标未签名请求必须拒绝，范围外请求如何处理也要记录。timeout 只在自有隔离环境测试。网络也必须同时验证允许客户端成功与非允许客户端失败，避免把服务器宕机导致“全部失败”误作安全成功。

下一步

下一篇区分 digest、签名、SBOM、provenance，并讨论不复制秘密正文仍保留审计证据。本单元是设计判断理论与测验，不代表已验证所有策略引擎行为。