Koray Oksay, embaixador da CNCF, considera que as organizações frequentemente colocam o Kyverno sob a responsabilidade das equipes de segurança. Elas o utilizam para validar configurações do Kubernetes, bloquear contêineres executados com privilégios de root ou impor padrões de segurança de contêineres, deixando de lado grande parte de seus recursos. Segundo a perspectiva de Oksay, essa classificação mental limita o Kyverno ao papel de um «gate» que impede configurações inadequadas, quando ele poderia ser utilizado como um bloco fundamental sobre o qual as equipes de plataforma constroem seus serviços e regras operacionais.
Essa opinião baseia-se na experiência do autor, que começou com uma apresentação na conferência KCD Munich em 2023, intitulada «Protegendo cargas de trabalho do Kubernetes com Kyverno». Após três anos trabalhando em ambientes de produção, ele afirma que seu interesse se voltou para governança, CEL e autoatendimento de plataformas, e que descrever o Kyverno como um «mecanismo de políticas» já não é suficiente para abranger seu escopo.
Por que a classificação como ferramenta de segurança não é suficiente?
Oksay não nega as funções de segurança do Kyverno. A plataforma pode bloquear configurações inseguras, impor Pod Security Standards e validar assinaturas de imagens de contêineres. No entanto, associá-la apenas à segurança consolida um modelo que vê a política como uma barreira cujo principal objetivo é rejeitar, medindo o sucesso pelo número de implantações impedidas.
Em contrapartida, o autor identifica quatro funções principais do Kyverno: validação, mutação, geração e validação de imagens. A função de validação pertence diretamente ao modelo de barreira; a mutação altera os recursos antes que eles sejam inseridos no cluster; a geração cria novos recursos em resposta a determinados eventos; e a validação de imagens concentra-se em estabelecer confiança nelas, não apenas em bloquear ameaças. Por isso, ele considera que três das quatro funções têm natureza construtiva, mas muitas organizações utilizam apenas políticas de validação.
O que significa ser um componente essencial da plataforma?
Oksay usa a expressão «componente essencial» em um sentido próximo ao seu uso nas linguagens de programação: um bloco pequeno e compreensível que pode ser combinado para construir sistemas maiores. Para que esse bloco desempenhe um papel efetivo na plataforma, ele deve ocultar a complexidade dos desenvolvedores, oferecer garantias automáticas, integrar-se a outros blocos e estar disponível por autoatendimento, em vez de depender de solicitações manuais ou filas de suporte.
Nesse sentido, as políticas do Kyverno se assemelham a componentes como Pods, Services, ConfigMaps e composições do Crossplane. Elas transformam as regras adotadas pela organização em comportamento automático dentro da plataforma.
Como as equipes de plataforma o utilizam?
- Preparação de namespaces: ao criar um namespace, o Kyverno pode gerar NetworkPolicy, ResourceQuota, LimitRange e RoleBindings padrão, de modo que o namespace apareça preparado sem exigir que o desenvolvedor se lembre de uma lista de etapas manuais.
- Injeção de contêineres sidecar: agentes de monitoramento, agentes de rede ou contêineres de sincronização de segredos podem ser adicionados às especificações dos Pods durante a fase de admissão, mantendo simples o arquivo de Deployment.
- Reescrita de referências de imagens: uma referência como nginx:1.25 pode ser convertida em mirror.internal/nginx:1.25 para que os downloads passem por um espelho interno, em vez de exigir que cada desenvolvedor adicione o prefixo manualmente.
- Adição de solicitações de recursos padrão: em vez de bloquear Pods que não definem solicitações de CPU e memória, é possível injetar valores adequados e ajustá-los quando necessário.
- Atribuição de etiquetas de propriedade: etiquetas da equipe, do centro de custo e do ambiente podem ser adicionadas quando os valores forem claros ou impostas quando a ambiguidade tiver impacto.
O que muda na prática?
Esses usos reúnem uma ideia: transformar uma convicção organizacional em uma garantia automática e invisível. A regra pode ser de segurança, como impedir contêineres com privilégios elevados; operacional, como impor limites de recursos; ou financeira, como associar cada recurso a uma etiqueta de centro de custo. Em vez de permanecerem na wiki, em listas de verificação ou no conhecimento de um único engenheiro, essas regras tornam-se uma política escrita como código, armazenada no Git e aplicada por meio de ferramentas de GitOps e do Kyverno.
Essa perspectiva propõe tratar a política como a interface da plataforma para expressar a intenção da organização. Quando aplicada, as funções do Kyverno passam a representar níveis diferentes: a validação fornece barreiras de proteção; a mutação traça «caminhos pavimentados» para os desenvolvedores; a geração oferece modelos ou preparações iniciais; e a validação de imagens constrói confiança.
As equipes também tratarão as políticas como produtos com versões, usuários, ciclos de descontinuação e exceções rastreáveis. A implantação da política pode começar com auditoria, passar por advertência e chegar à imposição gradual. O autor também aponta possíveis desafios de coordenação quando uma política modifica um recurso que o Argo CD ou o Flux considera sob sua propriedade, o que pode levar a ciclos de sincronização.
A conclusão apresentada por Oksay é que interpretar o Kyverno apenas como um mecanismo de segurança oculta grande parte de sua interface e de seus recursos. Na visão dele, não se trata de um guardião parado na entrada do cluster, mas de uma camada que conecta as opiniões da equipe de plataforma ao comportamento efetivo dos recursos e das aplicações.