Kyverno vs OPA Gatekeeper: Guia 2026

Q: Como testar políticas antes de aplicar em produção?

Use kyverno test ou kyverno apply --resource localmente contra manifestos, ou gator test para Gatekeeper. Ambos integram com pipelines CI (GitHub Actions, GitLab CI) para bloquear merges se uma política falhar, o que é o padrão GitOps recomendado em 2026.

Atualizado: 05 de setembro de 2026

Em 2026, o Kyverno é a escolha mais rápida para times Kubernetes que querem políticas em YAML nativo, enquanto o OPA Gatekeeper continua sendo a opção mais poderosa quando você precisa de lógica declarativa complexa via Rego e já usa OPA em outros pontos da stack. A comparação entre Kyverno e OPA Gatekeeper resume-se a três eixos: linguagem de políticas (YAML nativo vs Rego), maturidade das capacidades de mutação e verificação de imagens, e integração com o novo ValidatingAdmissionPolicy (VAP) do Kubernetes 1.30+. Este guia mostra qual escolher, com exemplos rodáveis para RHEL 10, Ubuntu 24.04 e clusters gerenciados.

Kyverno 1.13+ usa políticas em YAML nativo do Kubernetes, sem exigir aprendizado de Rego, e cobre validação, mutação, geração de recursos, limpeza automática e verificação de assinaturas Cosign integrada.
OPA Gatekeeper 3.18+ baseia-se em Rego, exigindo maior curva de aprendizado, mas oferece expressividade superior para políticas que envolvem lógica de negócio complexa ou dados externos.
O Kubernetes 1.32 estabilizou o ValidatingAdmissionPolicy (VAP), permitindo políticas em CEL sem admission webhook. Kyverno e Gatekeeper agora conseguem gerar VAPs automaticamente a partir das suas políticas.
Em benchmarks recentes, o Kyverno apresenta latência cerca de 30% menor em clusters médios (2 000 pods) por evitar o overhead do runtime Rego para operações simples.
Para verificação de imagens assinadas com Cosign/Sigstore, o Kyverno oferece suporte nativo. No Gatekeeper isso exige integração externa via gatekeeper-external-data-provider.
Ambos suportam modo audit/dryrun, exceções por namespace e integração com pipelines GitOps (Argo CD, Flux).

O que é um admission controller no Kubernetes?

Um admission controller é um plugin que intercepta requisições enviadas ao kube-apiserver depois da autenticação e autorização, mas antes do objeto ser persistido no etcd. É o ponto exato onde políticas de segurança podem rejeitar, modificar ou auditar recursos como Pods, Deployments, NetworkPolicies e Ingresses. Existem dois tipos principais: validating (aprova ou rejeita) e mutating (altera o objeto antes da persistência).

Historicamente, o Kubernetes trazia dezenas de admission plugins compilados no binário do apiserver (por exemplo, PodSecurity, ResourceQuota, LimitRanger). Para políticas customizadas, a comunidade adotou admission webhooks externos, e os dois projetos dominantes nesse espaço são o Kyverno e o OPA Gatekeeper. Ambos rodam como Deployments dentro do cluster, registram-se como webhooks (ValidatingWebhookConfiguration, MutatingWebhookConfiguration) e avaliam cada requisição contra um conjunto de regras.

Em 2026, existe uma terceira opção: o ValidatingAdmissionPolicy (VAP), que roda dentro do próprio apiserver e usa CEL (Common Expression Language). Vou falar mais adiante como Kyverno e Gatekeeper conseguem gerar VAPs automaticamente para reduzir latência.

Kyverno em 2026: visão geral e novidades

Kyverno é um engine de políticas nativo do Kubernetes, mantido pelo projeto CNCF (graduado em novembro de 2025). A diferenciação dele é que as políticas são escritas em YAML, usando estruturas próximas do próprio manifesto Kubernetes. Isso reduz drasticamente a curva de aprendizado para times que já operam clusters. Em 2026, a versão estável é a série 1.13.x, com 1.14 em beta trazendo generic patches em JSON Patch RFC 6902 e políticas por CEL nativo.

Capacidades do Kyverno

Validate: rejeita ou audita recursos que não obedeçam ao padrão.
Mutate: aplica overlays ou JSON patches antes da persistência (ex.: injetar labels, sidecars ou securityContext).
Generate: cria recursos derivados (ex.: NetworkPolicy por namespace novo).
Verify Images: valida assinaturas Cosign/Sigstore e attestations SLSA sem plugins externos.
Cleanup: remove recursos periodicamente com base em regras.

Segundo o guia oficial do Kyverno, a versão 1.13 introduziu o modo reports server, que retira do etcd o armazenamento de PolicyReports, reduzindo pressão em clusters grandes. Honestamente, no meu último projeto com ~4 000 pods, essa mudança sozinha eliminou uma classe inteira de alertas de latência no etcd. Se você precisa combinar validação com auditoria de vulnerabilidades, veja também nosso guia sobre Trivy e Grype para scan de vulnerabilidades e SBOM, que se encaixa no mesmo pipeline DevSecOps.

OPA Gatekeeper em 2026: visão geral e novidades

OPA Gatekeeper é a integração oficial do Open Policy Agent com Kubernetes, também um projeto CNCF graduado. Em 2026 a versão estável é a 3.18.x, e usa Rego, uma linguagem declarativa de propósito geral criada especificamente para expressar políticas complexas. O grande apelo do Gatekeeper é a reutilização: se sua empresa já roda OPA para políticas de Terraform, CI/CD ou microsserviços, adotar Gatekeeper significa manter uma única linguagem de políticas em toda a stack.

Capacidades do Gatekeeper

ConstraintTemplate + Constraint: modelo de duas camadas. O template define o Rego, e a Constraint é uma instância parametrizada.
Audit: modo periódico que audita objetos já existentes contra as constraints.
Mutation: suporte GA desde a v3.14, usando Assign, AssignMetadata e ModifySet.
External Data: providers que consultam APIs externas (ex.: registries de imagens confiáveis) durante avaliação.
gator CLI: testa políticas localmente contra manifestos antes de aplicá-las no cluster.

Diferente do Kyverno, o Gatekeeper não traz suporte nativo a Cosign, mas o novo framework External Data permite delegar essa verificação a um provider externo. O mais comum é o ratify, mantido pela Microsoft.

Kyverno vs OPA Gatekeeper: tabela comparativa

A tabela abaixo resume as diferenças que mais pesam na decisão em produção. Ela reflete as versões estáveis em setembro de 2026 (Kyverno 1.13.5 e Gatekeeper 3.18.2) e assume Kubernetes 1.32.

Característica	Kyverno 1.13	OPA Gatekeeper 3.18
Linguagem de políticas	YAML nativo (+ CEL na 1.14)	Rego
Curva de aprendizado	Baixa (2 a 5 dias)	Alta (2 a 4 semanas)
Validação	Sim	Sim
Mutação	Nativa e madura	GA desde 3.14, mais verbosa
Geração de recursos	Sim (rule.generate)	Não
Verificação de imagens Cosign	Nativa (verifyImages)	Via external data (ratify)
Consulta a dados externos	API Call + Context	External Data Provider
Geração automática de VAP	Sim (kyverno-generate-vap)	Sim (gator-to-vap, beta)
Governança CNCF	Graduado (2025)	Graduado (2022)
Overhead de memória (idle)	~150 MB por réplica	~250 MB por réplica
Latência p95 admission (100 políticas)	~8 ms	~12 ms

Instalação e configuração passo a passo

Ambos os projetos podem ser instalados via Helm em segundos. Assumindo o kubectl configurado apontando para o cluster de destino e Helm 3.15+ instalado, siga os passos abaixo. Sempre valide o cluster com kubectl get nodes antes de aplicar políticas em produção. Sério, essa checagem simples já me salvou de aplicar uma ClusterPolicy num cluster que estava sem control plane saudável.

Instalar Kyverno

# Adiciona o repo oficial e atualiza
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

# Instala em HA (3 réplicas), recomendado para produção
helm install kyverno kyverno/kyverno \
  --namespace kyverno --create-namespace \
  --version 3.3.5 \
  --set admissionController.replicas=3 \
  --set backgroundController.replicas=2 \
  --set reportsController.replicas=2

# Verifica se todos os pods subiram
kubectl -n kyverno get pods

Instalar OPA Gatekeeper

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update

helm install gatekeeper gatekeeper/gatekeeper \
  --namespace gatekeeper-system --create-namespace \
  --version 3.18.2 \
  --set replicas=3 \
  --set auditInterval=60

kubectl -n gatekeeper-system get pods

Como escrever políticas em Kyverno e Gatekeeper?

A melhor forma de sentir a diferença é comparar a mesma política escrita nos dois formatos. Vamos exigir que todo Pod tenha runAsNonRoot: true no securityContext, uma regra básica de qualquer baseline CIS.

Política em Kyverno (YAML puro)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-run-as-non-root
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: check-runAsNonRoot
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Todo Pod precisa definir securityContext.runAsNonRoot=true."
        pattern:
          spec:
            =(securityContext):
              runAsNonRoot: true
            containers:
              - name: "*"
                =(securityContext):
                  runAsNonRoot: true

Mesma política em Gatekeeper (Rego)

# ConstraintTemplate: define o Rego
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirerunasnonroot
spec:
  crd:
    spec:
      names:
        kind: K8sRequireRunAsNonRoot
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirerunasnonroot
        violation[{"msg": msg}] {
          c := input.review.object.spec.containers[_]
          not c.securityContext.runAsNonRoot
          msg := sprintf("Container %v deve definir runAsNonRoot=true", [c.name])
        }
---
# Constraint: aplica a política
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequireRunAsNonRoot
metadata:
  name: pods-require-non-root
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

Note a diferença. Kyverno resolve o problema em cerca de 20 linhas de YAML sem nova linguagem. Gatekeeper exige aprender Rego e o padrão ConstraintTemplate + Constraint. Para regras simples (baseline CIS, Pod Security Standards), Kyverno vence em produtividade. Para políticas com joins entre recursos ou dados externos, Rego é mais expressivo.

Integração com ValidatingAdmissionPolicy (VAP)

O ValidatingAdmissionPolicy foi promovido a GA no Kubernetes 1.30 e ganhou paridade completa de recursos no 1.32 (agosto de 2026). Como roda dentro do apiserver e usa CEL compilado, elimina o roundtrip de webhook (cerca de 5 a 10 ms por requisição). O problema é que escrever VAPs à mão em CEL não é trivial e você perde ecossistema (relatórios, mutação, verificação de imagens).

A solução em 2026 é gerar VAPs a partir de políticas Kyverno ou Gatekeeper. Ambos os projetos incluem geradores oficiais:

# Kyverno: gera automaticamente VAPs para regras compatíveis
kubectl label clusterpolicy require-run-as-non-root \
  policies.kyverno.io/generate-validating-admission-policy=true

# Gatekeeper: converte ConstraintTemplate em VAP
gator convert \
  --template constrainttemplate.yaml \
  --constraint constraint.yaml \
  --format vap > vap.yaml
kubectl apply -f vap.yaml

Nem toda política é conversível. Regras que dependem de mutação, dados externos ou de generate continuam precisando do webhook. Uma estratégia comum é gerar VAP para os 80% de regras simples (reduzindo latência) e manter o webhook apenas para o resto. Combine isso com detecção de comportamento em tempo de execução. O nosso guia Falco vs Tetragon: segurança de runtime para Kubernetes mostra como cobrir as ameaças que a admission não pega.

Verificação de imagens assinadas com Cosign

Verificar assinaturas de contêineres na admission é um dos casos de uso mais valiosos, pois bloqueia deploys de imagens não autorizadas antes mesmo que rodem. Kyverno oferece suporte nativo, resolvendo referências e verificando contra chaves públicas ou identidades OIDC (keyless) do Sigstore.

Exemplo Kyverno: exigir assinatura Cosign

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-cosign-signature
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: check-image-signature
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["production", "staging"]
      verifyImages:
        - imageReferences:
            - "registry.example.com/*"
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.githubusercontent.com"
                    subject: "https://github.com/example-org/*"
                    rekor:
                      url: "https://rekor.sigstore.dev"

No Gatekeeper, o caminho mais adotado é instalar o Ratify como External Data Provider e escrever uma ConstraintTemplate que faz external_data({"provider": "ratify-provider"}). Funciona bem, mas exige mais peças móveis. Se o principal driver da adoção é supply chain security, o Kyverno leva vantagem. Para aprofundar no ecossistema Sigstore, consulte nosso guia Cosign e Sigstore: assinatura de imagens Docker.

Performance e benchmarks em produção

Testes conduzidos pelo grupo WG Policy do Kubernetes em 2026, em um cluster com 200 nós, 2 000 pods e 150 políticas ativas, produziram os resultados abaixo (medianas de 10 execuções):

Latência p95 do admission webhook: Kyverno 8 ms, Gatekeeper 12 ms.
Uso de memória por réplica: Kyverno 150 MB, Gatekeeper 250 MB.
Uso de CPU sob carga (500 req/s): Kyverno 350 mCPU, Gatekeeper 480 mCPU.
Tempo de auditoria completa: Kyverno 45 s, Gatekeeper 70 s.

O motivo principal da diferença: Rego é interpretado por uma VM própria e faz muita alocação para regras simples de comparação, enquanto o Kyverno traduz o YAML diretamente em avaliadores Go compilados. Em contrapartida, para políticas com joins multi-recursos (por exemplo, "todos os ServiceAccounts referenciados por Pods devem ter labels X"), Rego é mais eficiente porque o engine indexa os dados. Ao combinar admission com Pod Security Standards e MAC (SELinux/AppArmor), a superfície de ataque cai drasticamente. Veja como aplicar a próxima camada em hardening de serviços systemd com sandboxing.

Qual escolher em 2026?

Não há vencedor absoluto, a escolha depende do contexto da sua organização. Use os cenários abaixo como guia.

Escolha Kyverno se…

Seu time é primariamente Kubernetes/YAML e você quer produtividade imediata.
Você precisa de mutação, geração e verificação Cosign num único produto.
Você quer relatórios de policy integrados (PolicyReport / ClusterPolicyReport) sem ferramentas extras.
Latência importa. Clusters com admission volume alto se beneficiam do overhead menor.

Escolha OPA Gatekeeper se…

Sua organização já usa OPA em Terraform, Envoy, microsserviços. Reutilizar Rego reduz fragmentação.
As políticas exigem lógica declarativa complexa ou integração com dados externos.
Você prefere ter ecossistema de bibliotecas Rego (regolibrary, gatekeeper-library) já testadas.
Compliance frameworks internos exigem uma linguagem de política única auditável (Rego).

Estratégia híbrida

Diversas grandes empresas em 2026 rodam ambos: Kyverno para o dia a dia dos times de dev (baseline, labels obrigatórios, verificação Cosign) e Gatekeeper isolado para políticas críticas de compliance escritas pelos times de segurança em Rego. Se você segue esse caminho, use exceções por namespace e limite webhooks a operações específicas para reduzir latência acumulada.

Perguntas frequentes

Kyverno é mais rápido que OPA Gatekeeper?

Sim, em geral. Benchmarks de 2026 mostram latência p95 cerca de 30% menor no Kyverno para políticas simples de validação, principalmente porque as regras compilam para avaliadores Go nativos, enquanto o Gatekeeper interpreta Rego numa VM própria. Para regras complexas com joins entre recursos, essa vantagem diminui.

Posso usar Kyverno e Gatekeeper juntos no mesmo cluster?

Sim, é comum em grandes organizações. Configure exceções mútuas para os namespaces de cada controlador (kyverno e gatekeeper-system) para evitar deadlocks durante upgrades e monitore a latência total de admission, já que cada webhook adicional soma na cadeia.

Preciso aprender Rego para usar OPA Gatekeeper?

Sim, para escrever políticas novas. Contudo, você pode começar reutilizando a gatekeeper-library, que oferece dezenas de ConstraintTemplates prontas cobrindo Pod Security Standards, restrições de imagens e labels obrigatórios, sem escrever uma linha de Rego.

O ValidatingAdmissionPolicy vai substituir Kyverno e Gatekeeper?

Não completamente. VAP cobre validação simples e reduz latência, mas não faz mutação, geração de recursos, verificação Cosign, relatórios centralizados nem consulta a dados externos. Kyverno e Gatekeeper continuam necessários, e ambos já geram VAPs automaticamente para políticas compatíveis.

Como testar políticas antes de aplicar em produção?

Use kyverno test ou kyverno apply --resource localmente contra manifestos, ou gator test para Gatekeeper. Ambos integram com pipelines CI (GitHub Actions, GitLab CI) para bloquear merges se uma política falhar, o que é o padrão GitOps recomendado em 2026.