Workloads mal configuradas continuam chegando à produção porque a revisão manual não escala: pods privilegiados, imagens com tag latest, deployments sem limites de recurso e labels ausentes atravessam pipelines inteiros sem ninguém notar. Quem opera clusters compartilhados pode fechar essa lacuna com Kyverno, projeto graduado na CNCF que aplica políticas como código no admission controller do Kubernetes, antes de o recurso existir. A ação prioritária é implantar as políticas em modo audit, medir o impacto nos PolicyReports e só depois ligar o bloqueio do que a equipe já corrigiu.
O problema antes do deploy
O RBAC do Kubernetes responde quem pode criar recursos, mas não o que pode ser criado. Um usuário com permissão para criar pods consegue subir um container privilegiado, montar caminhos do nó ou referenciar uma imagem sem versão fixa sem violar regra alguma do cluster. O ponto de controle é a camada de admissão: a requisição é interceptada após a autenticação e antes de o recurso ser persistido, segundo a documentação oficial do Kubernetes. Se qualquer controlador de admissão rejeitar, a requisição inteira falha na hora e o autor do deploy recebe o erro — em vez de a equipe descobrir o problema num incidente.
A admissão roda em duas fases: primeiro os controladores que alteram o objeto, depois os que apenas validam. Entender essa ordem evita escrever política de mutação que dependa de um valor que outra política ainda vai modificar. A camada também tem limites que convém registrar: ela não bloqueia operações de leitura (get, watch, list), porque leituras passam direto pela admissão, e não enxerga o que acontece depois da criação. Admissão, portanto, não substitui logging nem detecção em runtime; ela impede que a má configuração entre.
Como a admissão decide
O Kyverno é um motor de políticas que funciona como admission controller dinâmico: recebe os callbacks de webhook do API server, aplica as políticas que casam com o recurso e devolve permitir ou rejeitar, como descreve a documentação oficial do projeto. As políticas são escritas em YAML com expressões CEL — a mesma linguagem que o Kubernetes já adota nativamente — e gerenciadas como recursos declarativos do cluster. O motor valida, altera, gera e limpa recursos, de exigir labels até criar ConfigMaps padrão em namespaces novos, e também roda varreduras em background e via CLI, o que permite auditar o que já existe, não apenas o que chega.
A CNCF promoveu o Kyverno ao nível Graduated em 16 de março de 2026, o maior nível de maturidade da fundação, conforme a página oficial do projeto na CNCF. Na prática, quem adota hoje entra num projeto com API estável e ciclo de release ativo. A documentação de tipos de política marca os tipos baseados em CEL — ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy e ImageValidatingPolicy — como estáveis desde a v1.18, enquanto o ClusterPolicy legado foi oficialmente descontinuado na v1.19, com remoção estimada para a v1.20. A partir da v1.19, criar ou atualizar um tipo legado já retorna um warning de admissão, e o uso dessas APIs é contabilizado na métrica kyverno_deprecated_api_requests_total — sinal direto de quanto trabalho de migração existe no cluster.
O tipo ImageValidatingPolicy cobre verificação de assinaturas e atestações de imagem, tema que o portal já detalhou no guia sobre assinaturas de imagem como controle de admissão.
Política de exemplo comentada
O exemplo abaixo é o caso mínimo publicado na documentação oficial do ValidatingPolicy: exige a label environment em qualquer pod criado ou atualizado.
apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
name: check-labels
spec:
validationActions:
- Deny
matchConstraints:
resourceRules:
- apiGroups: ['']
apiVersions: [v1]
operations: [CREATE, UPDATE]
resources: [pods]
validations:
- message: label 'environment' is required
expression: "'environment' in object.metadata.?labels.orValue([])"Três blocos fazem o trabalho. validationActions decide a consequência: Deny bloqueia a requisição; Audit registra a violação no PolicyReport sem interromper o deploy. matchConstraints delimita o escopo — grupos de API, versões, operações e recursos que a política alcança. validations lista as expressões CEL com a mensagem que o autor do deploy vai receber em caso de falha.
O ValidatingPolicy do Kyverno é um superconjunto do ValidatingAdmissionPolicy nativo do Kubernetes, e a documentação oficial resume as diferenças que importam na escolha:
| Critério | ValidatingAdmissionPolicy (nativo) | ValidatingPolicy (Kyverno) |
|---|---|---|
| Onde aplica | Somente admissão | Admissão, background e pipelines |
| Payload | Recursos Kubernetes | Kubernetes e qualquer JSON ou YAML |
| Vinculação de política | Manual | Automática |
| Exceções | Sem mecanismo dedicado | PolicyException |
| Testes | — | CLI do Kyverno e Chainsaw |
Existem também variantes com escopo de namespace (NamespacedValidatingPolicy), que permitem ao dono do namespace gerenciar regras próprias sem permissão de administrador do cluster — útil em multi-tenancy, com isolamento claro de quem governa o quê.
Do modo audit ao bloqueio
A sequência abaixo evita o erro clássico de ligar o bloqueio no primeiro dia e quebrar a produção alheia:
- Implante com Audit e observe. Aplique as políticas com validationActions em Audit e deixe as varreduras em background popularem os PolicyReports. O relatório mostra quais recursos existentes violam cada regra e quem é o dono de cada correção.
- Priorize o que expõe o nó. As primeiras candidatas a Deny são as políticas que impedem container privilegiado, montagem de caminhos sensíveis do host e imagens sem fixação de versão — o dano dessas configurações ultrapassa o namespace de origem.
- Teste antes de aplicar. A CLI do Kyverno valida e testa o comportamento das políticas contra recursos antes de elas entrarem no cluster; rode esses testes no pipeline, junto do manifest, para que a política mude com revisão de código.
- Ligue o Deny por política. Mude uma política por vez para Deny depois que o PolicyReport estiver limpo, e trate exceções com PolicyException revisado, com dono e motivo registrados.
- Dimensione o webhook. O timeout de admissão padrão do Kyverno é de 10 segundos, com faixa configurável entre 1 e 30; defina também o comportamento de falha do webhook para saber se o cluster rejeita ou aceita requisições quando o motor está indisponível, e monitore a disponibilidade do serviço como dependência crítica do deploy.
Em prioridades: P1 é ter as políticas de exposição de nó em Audit já nesta semana e em Deny após o primeiro ciclo de correção; P2 é expandir para geração automática de recursos padrão e para a varredura de payloads de infraestrutura como código, que o mesmo motor já avalia em modo JSON.
Erros comuns na adoção
- Bloquear antes de auditar. O time perde confiança na primeira quebrada de deploy e a pressão para desligar tudo vira constante.
- Esquecer os pod controllers. Uma política escrita para pods não alcança Deployments; o campo autogen do Kyverno gera cobertura para deployments, jobs, cronjobs e statefulsets a partir da mesma declaração.
- Exceção sem dono. PolicyException sem revisão e sem prazo vira buraco permanente na governança do cluster.
- Tratar admissão como solução completa. Ela não cobre leituras nem comportamento em runtime; combine com varredura contínua de dependências, como no OpenSSF Scorecard para auditar dependências, e com os logs do próprio cluster.