Kyverno vs OPA Gatekeeper 的选择，不应从“哪个功能更多”开始，而应从组织问题开始：策略主要由平台工程师维护，还是安全合规团队维护？规则只作用于 Kubernetes，还是要延伸到 CI、镜像仓库和云资源？例外是否要可审计、可过期、可复盘？这些边界应结合准入控制、Kyverno 策略和 Gatekeeper 约束模型判断[1][2][3]。
Kubernetes 准入控制发生在 API 请求持久化之前，可用于验证或修改对象[1]。Kyverno 策略、Gatekeeper 约束和 OPA 策略语言分别对应不同的策略表达方式[2][3][4]。这意味着策略引擎会影响每一次资源创建和更新。选型错误不只是工具替换成本，还可能导致误拦截、例外失控和发布体验下降。
如果你还在搭建准入控制基础，可以先阅读 Kubernetes准入控制策略治理 理解 Admission Webhook 和强阻断边界；涉及审计留痕时，可结合 Kubernetes审计日志配置 设计证据链。
图1：Kyverno vs OPA Gatekeeper 在策
先回答“谁写策略”：语言只是协作成本的表现
Kyverno 更贴近 Kubernetes YAML，策略以 Kubernetes 资源形式组织，并支持 validate、mutate、generate 等能力[2]。这让平台团队更容易把镜像来源、标签、资源限制、安全上下文等规则纳入 GitOps 流程。
OPA Gatekeeper 使用 ConstraintTemplate 和 Constraint 组织 Rego 策略，并通过 admission webhook 对 Kubernetes 资源进行校验[3]。Rego 学习成本更高，但适合安全团队统一建模复杂约束，也便于与 Open Policy Agent 在其他系统中的策略语言保持一致[4]。
如果策略作者不同，选型也会不同：
- 平台团队主导、规则贴近 Kubernetes YAML：Kyverno 启动成本更低[2]。
- 安全团队主导、规则要跨系统复用：Gatekeeper 更有长期一致性[3][4]。
- 两类团队共同维护：需要先定义策略分层，而不是让两个工具重复拦截同一规则。
决策矩阵：把工具差异映射到治理问题
| 治理问题 | Kyverno 更自然 | Gatekeeper 更自然 |
|---|---|---|
| 策略作者 | 平台工程师、应用平台团队 | 安全合规团队、策略平台团队 |
| 规则表达 | Kubernetes YAML 风格 | Rego 声明式策略语言 |
| 变更能力 | validate、mutate、generate[2] | 以复杂校验约束为主[3] |
| 跨系统复用 | Kubernetes 内复用更直接 | OPA 生态内复用空间更大[4] |
| 例外治理 | 适合快速落地命名空间/资源级规则 | 适合沉淀统一约束模型 |
| 学习曲线 | 更低 | 更高但表达能力更系统 |
能拦截不代表适合强阻断
两个工具都能拒绝不合规资源。真正决定落地质量的是：规则是否有人维护、误拦截是否能快速回滚、例外是否有过期时间、历史工作负载是否先观察再治理。
规则分层：不要让一个工具承担所有策略
无论选择 Kyverno 还是 Gatekeeper，策略都应先分层。平台基线、安全底线、业务规范和临时例外，生命周期并不相同。
建议分成四类规则：
- 安全底线：特权容器、禁止镜像源、危险能力，适合强阻断。
- 平台基线：资源限制、标签、命名规范，适合先审计再收敛。
- 业务规范：团队自定义约定，适合命名空间或项目内治理。
- 临时例外：有原因、负责人、过期时间和复审记录。
图2：Kyverno 策略从审计、告警、软阻断到强阻断的上线流
落地路线：先做策略生命周期，再做工具铺开
不管选择哪一个工具，都不建议安装后马上全量强阻断。Kubernetes Admission Webhook 位于 API 请求链路中，超时、证书或服务可用性都会影响资源变更[1]；因此策略生命周期应包括规则来源、测试样例、灰度范围、例外审批、审计报表和回滚方式。
推荐按下面顺序推进：
- 第 1 阶段：审计模式。收集命中情况，识别历史负债。
- 第 2 阶段：新增资源软阻断。先限制新创建资源，避免影响存量。
- 第 3 阶段：安全底线强阻断。只对少数高风险规则强制执行。
- 第 4 阶段：例外复审。定期清理过期例外和重复规则。
- 第 5 阶段：策略测试。每条规则保留通过样例和失败样例。
图3：策略引擎从规则来源、测试、发布、例外到复审的生命周期闭环
组合使用：可以，但要避免重复规则
Kyverno 与 Gatekeeper 可以在同一集群中承担不同职责。例如 Kyverno 处理贴近 Kubernetes YAML 的 mutate、generate 和简单校验；Gatekeeper 处理复杂约束、跨字段判断和统一合规模型[2][3][4]。
组合使用时要明确：
- 同一条规则只能有一个主执行工具。
- 例外审批入口不能分裂。
- 审计报表要能合并到同一风险视图。
- 误拦截回滚要能定位到具体工具和规则。
- 策略命名、Owner 和测试样例要统一。
小结
Kyverno vs OPA Gatekeeper 没有固定答案。Kyverno 更适合以 Kubernetes 原生体验快速落地平台规则；OPA Gatekeeper 更适合需要统一策略语言、复杂约束和跨系统策略复用的组织。
更重要的是，策略治理要把规则分级、例外、审计和回滚一起设计。工具只能执行策略，不能替代团队对风险边界和协作方式的判断。
参考资料
- [1] Kubernetes Admission Controllers
- [2] Kyverno Documentation: Policies
- [3] Gatekeeper Documentation
- [4] Open Policy Agent: Policy Language
常见问题
1. Kyverno vs OPA Gatekeeper 可以同时使用吗？
可以，但要分清职责。常见做法是让 Kyverno 处理贴近 Kubernetes 的变更和简单校验，让 Gatekeeper 处理复杂约束。不要让两个工具重复实现同一条规则。
2. 中小团队应该先选 Kyverno 还是 Gatekeeper？
如果团队没有 Rego 经验、主要目标是补齐 Kubernetes 安全基线，Kyverno 通常更容易起步。如果组织已经有统一策略团队，或者未来要把策略扩展到多系统，Gatekeeper 更适合作为长期底座。
3. 策略引擎会不会影响 API Server 可用性？
会有影响边界。准入 Webhook 位于 API 请求链路中，超时、证书异常或服务不可用都可能影响资源创建[1]。生产环境应设置合理超时、failurePolicy、监控和灰度范围。
4. 哪些规则适合一开始就强阻断？
只建议把少数高风险底线设为强阻断，例如特权容器、禁止镜像源、明显越权的安全上下文。命名规范、标签完整性、资源限制更适合先审计和告警，再逐步升级。
5. Rego 学习成本高是不是就不该选 Gatekeeper？
不一定。如果团队需要统一策略语言、复杂约束表达或跨系统复用，Rego 的学习成本可能换来长期一致性。关键是配套测试、评审和策略 Owner，而不是只看语法难度。
