O que muda com o lançamento do Kyverno 1.18 no ecossistema Kubernetes?
O Kyverno 1.18 chega como a primeira atualização após sua graduação na CNCF, equilibrando segurança robusta e eficiência operacional. Com melhorias críticas contra riscos de SSRF, expansão da CLI para testes de políticas e migração progressiva para o padrão CEL, este release é essencial para times que buscam estabilidade. A principal conclusão é a necessidade de planejamento imediato para a migração de ClusterPolicies e a adoção do novo modelo de suporte N-1, visando sustentabilidade e segurança a longo prazo.
O Kyverno consolidou sua posição como a engine de políticas nativa do Kubernetes. Esta versão 1.18 não traz apenas correções, mas sinaliza a direção estratégica do projeto: segurança por padrão, observabilidade e maturidade técnica.
Segurança no nível de execução: O que mudou?
A segurança em ambientes cloud-native é frequentemente desafiada por configurações de permissão excessiva. O 1.18 introduz salvaguardas essenciais para a execução de políticas via HTTP:
- Mitigação de SSRF: Agora, endereços sensíveis (loopback, metadados) são bloqueados por padrão. O controle via allowlist e blocklist traz granularidade necessária para cenários multi-tenant.
- Scoped Token Authorization: Reduz o raio de explosão em caso de comprometimento, garantindo que os tokens utilizados em chamadas externas não possam ser reutilizados para impersonar controllers do Kyverno (CVE-2026-41323).
Melhorias na experiência de desenvolvimento e automação
Para times que aplicam práticas de Shift-Left e CI/CD, a evolução da CLI é um diferencial. Agora, os comandos apply e test suportam Cleanup policies e autorizações Envoy, permitindo que o ciclo de feedback de políticas validado em CI seja muito mais próximo do comportamento real em produção.
Otimização operacional e suporte
A introdução de Memory-based HPA para o admission controller e a melhoria na concorrência são respostas diretas às dores de escala em clusters massivos. No entanto, a mudança mais impactante para gestores de TI é o novo modelo de suporte N-1.
Essa mudança força uma cadência de atualização que, embora exija disciplina, aumenta a segurança ao diminuir a dívida técnica acumulada. Para empresas brasileiras dependentes de alta disponibilidade, é o momento de revisar pipelines de deployment para automatizar testes de upgrade seguindo a nova política de suporte de 3 meses.
O caminho para o futuro: Migração de ClusterPolicies
A mensagem sobre a descontinuação das ClusterPolicy é clara. Embora não seja mandatória neste exato momento, a transição para ValidatingPolicy, MutatingPolicy e similares deve ser priorizada no backlog de engenharia para este ano. Ignorar essa etapa tornará migrações futuras traumáticas.
Perguntas Frequentes
-
Quais são as principais mudanças de segurança no Kyverno 1.18?
O release introduz restrições rígidas contra abusos do tipo SSRF, implementando bloqueios padrão para loopback e serviços de metadados em chamadas HTTP. Além disso, a autorização de tokens foi refinada com tokens de escopo para evitar privilégios excessivos nas comunicações do controller. -
O que a adoção do modelo de suporte 'N-1' significa para a operação?
Significa que o time de manutenção proverá patches (correção de falhas críticas/CVEs) apenas para a versão atual e a imediatamente anterior. Para empresas brasileiras, isso exige um plano de upgrade trimestral ou a adoção de uma distribuição comercial com suporte de longo prazo. -
Devo me preocupar com a descontinuação das ClusterPolicies?
Sim, é um movimento estratégico. Embora não haja breaking changes imediatas no 1.18, a depreciação das ClusterPolicies é certa para o final do ano. É altamente recomendado iniciar a migração para os novos tipos de recursos, como ValidatingPolicy e MutatingPolicy, para evitar retrabalho futuro.
Artigo originalmente publicado por Cortney Nickerson, Kyverno Contributor em Cloud Native Computing Foundation.
