容器安全 7 分钟阅读高级

Kyverno vs OPA Gatekeeper 2026 完整对比:Kubernetes 准入控制器策略语言、性能与生产选型指南

Kyverno 1.13 用 YAML + CEL,OPA Gatekeeper 3.22 用 Rego + VAP。本文从策略语言、镜像验签、CI 流水线到生产运维,给出 5 个可直接抄的选型场景与可运行 YAML/Rego 示例。

Raj Patel审校 Yuki Tanaka, Jul 2026
Kyverno vs OPA Gatekeeper 2026 对比指南

更新于:2026 年 7 月 12 日

Kyverno 和 OPA Gatekeeper 都是 CNCF 已毕业的 Kubernetes 准入控制器,核心区别在于策略语言:Kyverno 用原生 YAML 编写策略,OPA Gatekeeper 用 Rego。2026 年 Q1 发布的 Kyverno 1.13 引入了 ValidatingPolicy/CEL 表达式与内置镜像验签,而 Gatekeeper 3.22 让 Kubernetes ValidatingAdmissionPolicy (VAP) 集成正式 GA。作为长期把两套引擎往流水线里塞的 DevSecOps 工程师,我在这篇文章里给出可运行的对比示例和 CI 就绪代码片段,帮你在生产集群里做出正确选择。

  • Kyverno 1.13 (2026 Q1) 使用 YAML + CEL,策略与 Kubernetes 清单同源,零学习成本;OPA Gatekeeper 3.22 使用 Rego + CEL,策略可跨 K8s/Terraform/API 复用。
  • Kyverno 独有资源生成 (generate) 与后台变更扫描;Gatekeeper 仅在准入时校验,但生成的 VAP 资源可离线执行,避开 webhook 延迟。
  • Kyverno 原生支持 cosign 镜像验签 (ImageValidatingPolicy);Gatekeeper 需要外部数据提供者或额外 webhook。
  • 控制器内存开销:Gatekeeper 约 270 MB,Kyverno 四控制器约 600 MB;Rego 评估延迟 0.5-2 ms 略优于 Kyverno 的 YAML 引擎。
  • CI 流水线用 kyverno test 或 gator test 均可在 PR 阶段拦截违规,先跑 audit 模式再切 enforce 是 2026 生产标准做法。
  • PodSecurityAdmission (PSA) 只覆盖 Pod 级规则,无法生成资源、无法 mutate,是这两款引擎补齐的空缺。

Kyverno 与 OPA Gatekeeper 有什么区别?

两者都是 CNCF 已毕业的策略引擎,都以 ValidatingAdmissionWebhook 形式挂在 kube-apiserver 前面拦截请求,但设计哲学正好相反。Kyverno 是 Kubernetes 原生工具,策略 CRD 长得像 Deployment,写好就能提 PR;OPA Gatekeeper 是通用策略引擎的 K8s 适配层,通过 ConstraintTemplate 把 Rego 逻辑封装成可复用模板,再用 Constraint 实例化。这个差异会传导到语言、开发者体验、复用范围以及能不能"生成资源",一路影响到你团队每天写多少代码、CI 里跑多少测试。

下表汇总了在 Kyverno 1.13 官方文档与 Gatekeeper 3.22 官方文档中我认为最关键的 8 个维度,可直接作为选型评审用的清单。

维度Kyverno 1.13OPA Gatekeeper 3.22
策略语言YAML + CEL 表达式Rego + CEL(VAP 集成后)
学习曲线低,与 K8s 清单同源中高,Rego 语法陡峭
能力矩阵Validate / Mutate / Generate / Cleanup / ImageValidateValidate + Mutate(Assign 资源)
后台扫描原生支持,持续输出 PolicyReportAudit 子系统周期性执行
镜像验签原生 ImageValidatingPolicy 集成 cosign/notary需外部 provider (external data)
跨平台复用Kubernetes 为主(Kyverno JSON 可覆盖 JSON 载荷)全平台通用(Terraform/Envoy/CI)
控制器内存约 600 MB(4 个控制器)约 270 MB(2 个控制器)
ValidatingAdmissionPolicy 生成试验性支持3.18 GA,3.22 默认开启 sync-vap-enforcement-scope

其实不用死记全部差异,抓住一句话就够了:"策略要不要出 K8s"。如果答案是"不出",Kyverno 几乎总是更省心;如果答案是"要跟 Envoy、Terraform、CI Bot 共用同一份 Rego",那 Gatekeeper 就是正解。

策略语言之战:YAML 声明式 vs Rego 编程式

策略语言是选型里最容易被低估的维度,但它其实决定了你每周花多少时间修策略、多少人能上手 review PR。Kyverno 的 YAML 语法几乎就是 Kubernetes 清单的镜像:如果你会写 Deployment.spec.template,你就会写 ClusterPolicy.spec.rules。而 Rego 是一种基于 Datalog 的声明式查询语言,支持部分求值、集合推导和自定义函数,功能确实强大,但一个"禁止 hostPath 挂载"的规则可能就有三种写法。团队里没有 Rego 老手时,PR review 通常会卡住。

下面是同一条策略(禁止 latest 标签的容器镜像)在两套引擎里的实现,你可以感受一下阅读成本的差别。

Kyverno YAML 版本

# disallow-latest-tag.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
  annotations:
    policies.kyverno.io/severity: medium
spec:
  validationFailureAction: Enforce   # 2026: 也可用 rule 级 validate.failureAction
  background: true                    # 后台扫描历史资源
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "禁止使用 :latest 标签,请指定明确版本或摘要。"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

OPA Gatekeeper Rego 版本

# template.yaml
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sdisallowlatesttag
spec:
  crd:
    spec:
      names:
        kind: K8sDisallowLatestTag
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdisallowlatesttag
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          endswith(container.image, ":latest")
          msg := sprintf("禁止 :latest 标签: %v", [container.image])
        }
---
# constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowLatestTag
metadata:
  name: no-latest-tag
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  enforcementAction: deny

差异一目了然:Kyverno 需要 20 行 YAML,OPA Gatekeeper 需要模板加约束共 30 行,还得包含一段 Rego 代码。好在 Gatekeeper 3.22 起支持用 CEL 替换 Rego,把学习成本拉回和 Kubernetes 原生 ValidatingAdmissionPolicy 一样的水平,这也是 OPA 团队重新拿回中间地带的关键动作。

Kyverno 1.13 新特性:ValidatingPolicy、CEL 与镜像验签

Kyverno 1.13 于 2026 年 3 月发布,引入了一批新的顶级策略类型,让 YAML 引擎在保留易读性的同时,首次拥有了媲美 Rego 的表达能力。这些新 CRD 与旧的 ClusterPolicy 并存,但官方建议新集群优先采用新语法。

新策略类型与迁移建议

  • ValidatingPolicy:基于 CEL 表达式的纯校验策略,内部走 Kubernetes 原生 VAP 通道,准入延迟从 webhook 的 3-5 ms 降到 0.3 ms 以内。
  • ImageValidatingPolicy:原生对接 cosign、notary v2 与 Sigstore Policy Controller,可以在准入阶段直接拒绝未签名或来自未受信管道的镜像。
  • MutatingPolicy / GeneratingPolicy / DeletingPolicy:把三种变更行为拆到独立 CRD,权限最小化更容易。
  • CEL Libraries:可复用 CEL 函数,把常用检查如"镜像仓库必须是私有 registry"抽成库,避免复制粘贴。

ImageValidatingPolicy 实战代码

# image-verify.yaml : 生产可用的 cosign 验签策略
apiVersion: policies.kyverno.io/v1alpha1
kind: ImageValidatingPolicy
metadata:
  name: verify-signed-images
spec:
  failureAction: Enforce
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  attestors:
    - name: sre-team
      cosign:
        keyless:
          identities:
            - issuer: "https://token.actions.githubusercontent.com"
              subject: "https://github.com/acme-sre/*/.github/workflows/release.yaml@*"
  verifications:
    - imageReferences:
        - "ghcr.io/acme-sre/*"
      attestors: ["sre-team"]
      required: true

这一策略把只允许通过 GitHub Actions release.yaml 工作流签名的镜像放行,和 软件供应链安全:Sigstore + SBOM + SLSA 指南里演示的 keyless 签名管道顺畅对接。同样的效果在 OPA Gatekeeper 上需要额外部署 cosign-gatekeeper-provider,并配置 external data,运维成本明显更高。

OPA Gatekeeper 3.22 新特性:VAP、gator CLI 与 CEL

Gatekeeper 3.22 的核心动作是把自己"塞"进 Kubernetes 原生的 ValidatingAdmissionPolicy 里。1.30+ 的集群里,VAP 直接跑在 kube-apiserver 内部,不走 webhook,几乎零延迟。Gatekeeper 3.18 起就能把符合条件的 ConstraintTemplate 编译成 VAP 资源,3.22 更进一步把 sync-vap-enforcement-scope 特性门控默认开启。这意味着同一份约束既能通过 VAP 快速路径生效,也能通过传统 webhook 兜底不支持 CEL 的规则。

gator CLI:policy 管理 + 基准测试

3.22 一口气引入了两个新的 gator 子命令,让流水线体验大幅改善:

  • gator policy:类似 Homebrew 的策略管理器,可以直接从 gatekeeper-library 安装、升级、卸载策略束(比如 pod-security-baseline),并支持 dry-run 预览影响。
  • gator bench:用真实业务负载压测 Rego 与 CEL 两条评估路径,输出 P50/P95/P99 延迟与吞吐,配合 baseline 快照可以在 CI 里检测策略性能回归。

Rego + CEL 双引擎示例

# 用 CEL 替代 Rego,让 Gatekeeper 生成 VAP 快速路径
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirelabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequireLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items: {type: string}
  targets:
    - target: admission.k8s.gatekeeper.sh
      code:
        - engine: K8sNativeValidation   # 触发 VAP 生成
          source:
            validations:
              - expression: |
                  variables.params.labels.all(
                    lbl,
                    object.metadata.labels != null &&
                    lbl in object.metadata.labels
                  )
                message: "必要标签缺失。"

这个模板在 3.22 集群里会自动生成 ValidatingAdmissionPolicy,评估直接在 kube-apiserver 内部完成。即使 Gatekeeper 控制器宕机,策略仍然生效,可用性显著提升。对处于合规审计压力下的团队来说,这是选择 Gatekeeper 的关键理由,可以直接对接 Linux 审计框架:auditd + MITRE ATT&CK + CIS 合规自动化里的合规链路。

Pod Security Admission 为何补不上这两个引擎的位置?

Kubernetes 1.25 移除 PodSecurityPolicy (PSP) 后,官方给出的替代品 Pod Security Admission (PSA) 只覆盖 Pod 层级的三档预设(privileged/baseline/restricted)。看起来"够用",但真到生产落地就会发现 PSA 有三个硬伤:只作用于 Pod,ConfigMap、Ingress、CRD 一律不管;不能定制拒绝消息,开发者收到"pod violates policy"却不知道违反了哪条;无法生成资源,没有默认 NetworkPolicy、没有默认 LimitRange。这些空缺正是策略引擎存在的意义。

我在最近一次审计里帮客户用 Kyverno 生成 default-deny NetworkPolicy 的策略如下,PSA 完全做不到:

# auto-networkpolicy.yaml : 新命名空间自动创建 default-deny NetworkPolicy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-networkpolicy
spec:
  rules:
    - name: default-deny-per-ns
      match:
        any:
          - resources:
              kinds: ["Namespace"]
      exclude:
        any:
          - resources:
              namespaces: ["kube-system", "kyverno", "gatekeeper-system"]
      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny
        namespace: "{{request.object.metadata.name}}"
        synchronize: true
        data:
          spec:
            podSelector: {}
            policyTypes: ["Ingress", "Egress"]

Gatekeeper 目前仍无原生资源生成能力,3.22 也没有把它列进 roadmap,这是 Kyverno 相对于 PSA 与 Gatekeeper 最不可替代的杀手锏。想深入了解容器加固可参考 Linux 容器安全纵深防御:runc、Seccomp 与 AppArmor 加固,理解为什么"生成 + 校验"配合才能覆盖真实攻击面。

如何在 CI/CD 流水线里测试 Kyverno 与 Gatekeeper 策略?

在流水线里跑策略测试,才是真正的 DevSecOps。等 kube-apiserver 拒绝了才发现策略写错?那已经是生产事故了。两个引擎都提供了 CLI 工具,让你在 PR 阶段就跑完 golden test。下面给出的是我在多个团队复用的 GitHub Actions 与 GitLab CI 模板,直接抄进 .github/workflows/ 或 .gitlab-ci.yml 即可。

Kyverno:kyverno CLI + kyverno test

# .github/workflows/kyverno-test.yaml
name: Kyverno Policy Tests
on:
  pull_request:
    paths: ["policies/**", "tests/**"]
jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - name: Install kyverno CLI
        run: |
          curl -L https://github.com/kyverno/kyverno/releases/download/v1.13.2/kyverno-cli_v1.13.2_linux_x86_64.tar.gz \
            | tar -xz
          sudo install kyverno /usr/local/bin/
      - name: Lint policies
        run: kyverno fix policy policies/ --file-suffix=.yaml
      - name: Run policy tests
        run: kyverno test tests/    # 每个 tests/*/kyverno-test.yaml 都是一个 golden test
      - name: Apply against sample manifests (dry run)
        run: kyverno apply policies/ --resource manifests/ --policy-report

OPA Gatekeeper:gator test + gator bench

# .gitlab-ci.yml : gator 通过 conftest 兼容语法测试 Rego
gatekeeper_test:
  image: openpolicyagent/gatekeeper-crds:v3.22.0
  stage: test
  script:
    - gator verify policies/ -f tests/*.yaml     # 断言 allow/deny
    - gator expand -f manifests/deployment.yaml  # 演算 mutation
    - gator bench --template=policies/require-labels.yaml \
                  --input=manifests/deployment.yaml \
                  --duration=30s \
                  --baseline=bench/baseline.json  # 性能回归检测
  artifacts:
    reports: {junit: gator-report.xml}

性能、资源占用与运维复杂度

准入控制器坐在 kube-apiserver 请求路径上,每毫秒都很贵。Gatekeeper 官方基准显示 Rego 评估路径在 0.5-2 ms 之间,Kyverno 的 YAML 引擎因为要转译到内部 IR,准入延迟通常在 2-5 ms;不过 Kyverno 1.13 引入的 ValidatingPolicy 走 VAP 后延迟降到 0.3 ms 以内,追平甚至超过 Gatekeeper。所以"OPA 更快"这个说法其实只在过去的比较中成立;2026 年的今天两者已经相当接近,选型时不用为 1 ms 焦虑。

真正拉开差距的是控制器自身的资源开销。Gatekeeper 由 controller 和 audit 两个 pod 组成,总内存约 270 MB;Kyverno 拆成 admission、background、reports、cleanup 四个控制器,总内存约 600 MB。中小型集群(小于 50 节点)会明显感到 Kyverno 更重,而 200+ 节点的集群里,这个差距会被工作负载摊平。老实说,真正让你痛苦的通常是策略数量,不是控制器本身。

运维复杂度对比

# 一键健康检查脚本 : 我在客户现场常用的诊断入口
#!/usr/bin/env bash
set -euo pipefail
echo "== Kyverno =="
kubectl -n kyverno get pods,deployments -o wide
kubectl get clusterpolicy,policy -A -o custom-columns='NAME:.metadata.name,READY:.status.ready,VIOLATIONS:.status.rulecount.violate'
kubectl get policyreport,clusterpolicyreport -A --no-headers | wc -l

echo "== Gatekeeper =="
kubectl -n gatekeeper-system get pods
kubectl get constrainttemplate -o custom-columns='NAME:.metadata.name,CREATED:.status.byPod[*].observedGeneration'
kubectl get constraints -A --no-headers | awk '{print $1"/"$2" enforcement="$3" violations="$4}'

生产选型:5 个决策场景

把上面 6 节浓缩成 5 个真实场景,如果你正在做选型评审,可以按这个决策树走一遍。

  1. 纯 K8s 团队,主要诉求是补齐 PSP:选 Kyverno。YAML 学习成本几乎为零,PolicyReport 直接接入 DevSecOps CI/CD 流水线安全实战指南里的 GitOps 反馈闭环。
  2. 已经在 Terraform / Envoy / CI 里用 Rego:选 Gatekeeper。一门语言,全栈复用,避免团队维护两套心智模型。
  3. 合规审计压力大 (PCI-DSS / HIPAA / GB/T 22239-2019):选 Gatekeeper + VAP。策略在 kube-apiserver 内部执行,审计链路更清晰,Rego 也更容易被合规评审员理解。
  4. 供应链安全优先(需 cosign 验签):选 Kyverno。ImageValidatingPolicy 是唯一开箱可用的方案,配合 Sigstore keyless 30 分钟内落地。
  5. 不能确定,想两条腿走路:Kyverno + Gatekeeper 可同集群并存,只要 webhook failurePolicy 都设为 Fail,冲突几乎不发生。我在一个金融客户就是这么部署的:Kyverno 负责镜像验签与资源生成,Gatekeeper 复用现有 Rego 库做通用校验。

不管选哪套,记得把策略仓库当成"生产代码"来管理:分支保护、代码审查、CI 测试、canary 发布,一个都不能少。这才是 policy-as-code 真正的意义。

常见问题

Kyverno 1.13 的 ValidatingPolicy 与旧的 ClusterPolicy 有什么区别?

ValidatingPolicy 使用 CEL 表达式并可直接生成 Kubernetes 原生的 ValidatingAdmissionPolicy,准入延迟低于 0.3 ms;ClusterPolicy 使用 YAML 模式匹配,走 webhook 通道。新集群建议优先采用 ValidatingPolicy,ClusterPolicy 仍受支持但功能演进放缓。

OPA Gatekeeper 用什么语言写策略?

Gatekeeper 主用 Rego(Open Policy Agent 的声明式查询语言),3.18 起同时支持 CEL 表达式。CEL 更轻量、学习成本低,但表达力不如 Rego;复杂逻辑仍推荐 Rego,简单校验用 CEL 可直接生成 VAP 快速路径。

Kyverno 和 OPA Gatekeeper 可以同时安装在同一个集群吗?

可以。两者都是 ValidatingAdmissionWebhook 且监听独立的 CRD,不会互相冲突。建议按能力划分:Kyverno 负责 mutate/generate/镜像验签,Gatekeeper 负责跨平台复用的 Rego 校验。webhook failurePolicy 都设为 Fail 可避免"逃逸"。

如何在 GitOps 里管理策略生命周期?

把策略 YAML 放进独立 Git 仓库,用 Argo CD 或 Flux 同步到集群;PR 触发 kyverno test / gator test;主分支合并后先部署为 audit 模式,通过 PolicyReport 观察 7-14 天,再切 enforce。所有变更走 code review,策略即代码。

Pod Security Admission 已经内置了,还需要 Kyverno 或 Gatekeeper 吗?

大多数生产环境都需要。PSA 只覆盖 Pod 层的 privileged/baseline/restricted 三档,无法拒绝错误标签的 Service、无法自动生成 NetworkPolicy、无法定制拒绝消息,也不能验签镜像。想覆盖 Pod 之外的资源或做资源生成,只有 Kyverno/Gatekeeper 能胜任。

Raj Patel
关于作者 Raj Patel

DevSecOps engineer who's gradually turning every CI pipeline he sees into a security-checking machine.

相关文章