Verificador de Manifestos Kubernetes

Os manifestos Kubernetes são normalmente revistos a olho nu num pull request, o que significa que os mesmos erros de hardening continuam a chegar a produção: um Deployment sem limite de memória que acaba por ser eliminado por OOM e leva um nó com ele, um contentor que executa alegremente como root porque ninguém definiu runAsNonRoot, ou um Pod fixado a uma tag de imagem como `:latest` que muda silenciosamente a meio de um rollout. Este linter deteta essa classe de problemas no momento em que cola um manifesto, sem precisar de um cluster a correr, de contexto kubectl ou de quaisquer credenciais.

Internamente, inclui um pequeno parser YAML desenvolvido à mão, escrito especificamente para o subconjunto realista de YAML que os manifestos Kubernetes realmente usam: documentos separados por `---`, aninhamento baseado em indentação, mapeamentos `key: value` e blocos aninhados, itens de sequência `- ` incluindo listas de mapas, escalares com e sem aspas, comentários e escalares de bloco `|`/`>` para coisas como valores multi-linha em ConfigMaps ou anotações. Não há nenhuma biblioteca YAML externa envolvida — o parser e o motor de regras estão ambos integrados na ferramenta e executam totalmente no seu navegador.

A tabela de regras baseia-se em orientações de hardening de clusters bem conhecidas — o CIS Kubernetes Benchmark, o kube-score e o perfil "Restricted" dos Pod Security Standards — e verifica cada contentor quanto a pedidos/limites de recursos em falta, contentores que podem executar como root ou em modo privilegiado, probes de liveness e readiness em falta em cargas de trabalho de longa duração (Deployments, StatefulSets, DaemonSets), montagens de volumes hostPath que expõem o sistema de ficheiros do anfitrião, utilização de hostNetwork e imagens de contentor não reproduzíveis `:latest` ou sem tag. As conclusões são agrupadas por documento e por contentor, com uma gravidade clara de erro/aviso em cada uma, para que possa distinguir o que é realmente arriscado do que é apenas um lembrete de boa prática.

Funciona em manifestos únicos ou em ficheiros inteiros com múltiplos documentos colados diretamente do resultado de um Helm template render ou de um `kustomize build`, compreendendo recursos de Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet e CronJob. Como tudo corre localmente, é seguro colar manifestos que contenham nomes de serviços internos, dimensionamento real de recursos ou qualquer outra coisa que não queira enviar para uma API de terceiros — útil para uma verificação rápida de sanidade antes de um commit, um auxiliar de revisão de código ou simplesmente para aprender como é que "hardened" realmente se parece na prática.