LLMs geram manifestos Kubernetes que funcionam, mas têm falhas: como pegá-las antes do deploy

O manifesto que a rede neural entregou parece impecável: indentação correta, campos conhecidos, o `kubectl apply` não reclama e o pod passa para Running. É nisso, segundo o anúncio da análise no Habr, que está a armadilha. Os problemas aparecem depois, já em produção. A causa é que as LLMs reproduzem configurações obsoletas e inseguras, das quais os dados de treinamento têm de sobra. Para ter uma noção de escala: o Ingress de `extensions/v1beta1` foi removido no Kubernetes 1.22, e a PodSecurityPolicy desapareceu na 1.25. Tutoriais antigos com esses objetos continuam na internet, e o modelo os cita sem hesitar.

Ressalva: o anúncio disponível não traz detalhes, apenas teses. A seguir, usamos essas teses e as características já conhecidas do Kubernetes.

Por que um YAML plausível é perigoso

O modelo otimiza a probabilidade do próximo token, não a segurança do cluster. Anos de exemplos públicos, respostas em fóruns e repositórios com configurações de demonstração ensinam a ele o manifesto "típico". O manifesto típico da documentação é minimalista de propósito: sem limites de recursos, sem restrições de segurança e, muitas vezes, com a tag `latest`. Para um ambiente de estudo, isso é normal. Para um cluster de produção, não.

A validação de esquema não enxerga esse problema. Ela verifica a forma: os campos existem e os tipos coincidem. Um contêiner executado como root com `privileged: true` é formalmente correto. Um manifesto sem readiness probes também é correto, só que o tráfego chega ao pod antes de a aplicação estar pronta para recebê-lo.

O conjunto clássico de defeitos encontrados na revisão desse tipo de YAML:

• `apiVersion` de APIs removidas ou declaradas obsoletas, o que quebra o manifesto na atualização do cluster;
• imagens com a tag `latest` em vez de uma versão fixa ou digest;
• ausência de `resources.requests` e `limits`, ou seja, risco de "vizinho barulhento" e de OOM kills;
• execução como root, sem `runAsNonRoot`, `allowPrivilegeEscalation: false` e `readOnlyRootFilesystem`;
• ausência de liveness e readiness probes;
• segredos direto em `env`, em vez de Secret ou de um armazenamento externo;
• `hostNetwork`, `hostPath` e `privileged` herdados de exemplos de depuração;
• serviços expostos para fora e ausência de NetworkPolicy.

Onde colocar as barreiras

O primeiro nível é a validação do esquema para a versão específica do cluster. Para isso servem o kubeconform e o `kubectl apply --dry-run=server`: o dry-run no servidor passa o manifesto pelo API server e pelos admission controllers sem criar objetos. Para encontrar APIs obsoletas, há o Pluto.

O segundo nível é a análise estática de segurança e boas práticas: kube-linter, Checkov, Trivy (modo config) e Kubescape. Essas ferramentas pegam contêineres root, falta de limites e modos privilegiados. Tudo isso roda no CI a cada pull request, independentemente de o arquivo ter sido escrito por uma pessoa ou por um modelo.

O terceiro nível são as políticas no próprio cluster. O Pod Security Admission com o perfil `restricted` barra pods inseguros na entrada. Kyverno ou OPA Gatekeeper acrescentam regras próprias: proibição de `latest`, limites obrigatórios e registries permitidos. Se o autor do manifesto deixou algo passar, o cluster não aceita esse objeto.

Como trabalhar com geração por IA na prática

Trate a resposta do modelo como um pull request de estagiário: rápido, confiante e sem entender o seu ambiente. No prompt, informe explicitamente a versão do Kubernetes, os requisitos de segurança e as políticas da organização. Peça que o modelo explique cada parâmetro não trivial e depois confira a explicação na documentação.

Não deixe manifestos gerados irem direto para o cluster. O caminho deve ser um só: repositório, CI com linters, revisão humana, deploy via GitOps e rollout gradual com acompanhamento de métricas. Assim, a velocidade da geração continua sendo uma vantagem, e não um incidente adiado.

Por fim: se a equipe não tem políticas que rejeitem automaticamente configurações ruins, a IA apenas acelera o surgimento dessas configurações. Primeiro vêm as barreiras, depois a automação.