Linter de manifesto do Kubernetes

Os manifestos do Kubernetes geralmente são revisados ​​a olho nu em uma solicitação pull, o que significa que o mesmo punhado de erros de proteção continua chegando à produção: uma implantação sem limite de memória que eventualmente é eliminado pelo OOM e leva um nó com ele, um contêiner que funciona alegremente como root porque ninguém configurou runAsNonRoot ou um pod fixado em uma tag de imagem como `:latest` que muda silenciosamente sob uma implementação. Este linter detecta esse tipo de problema no momento em que você cola um manifesto, sem precisar de um cluster em execução, contexto kubectl ou qualquer credencial.

Nos bastidores, ele inclui um pequeno analisador YAML feito à mão, escrito especificamente para o subconjunto realista de YAML que os manifestos do Kubernetes realmente usam: documentos separados `---`, aninhamento baseado em indentação, `chave: valor` e mapeamentos de blocos aninhados, itens de sequência `- ` incluindo listas de mapas, escalares entre aspas e não citados, comentários e escalares de bloco `|`/`>` para itens como valores ConfigMap multilinhas ou anotações. Não há nenhuma biblioteca YAML externa envolvida — o analisador e o mecanismo de regras são fornecidos com a ferramenta e executados inteiramente em seu navegador.

A tabela de regras é modelada com base em orientações bem conhecidas de fortalecimento de cluster - o CIS Kubernetes Benchmark, kube-score e o perfil "Restricted" dos padrões de segurança do pod - e verifica cada contêiner em busca de solicitações/limites de recursos ausentes, contêineres que podem ser executados como root ou em modo privilegiado, testes de atividade e prontidão ausentes em cargas de trabalho de longa execução (implantações, StatefulSets, DaemonSets), montagens de volume hostPath que expõem o sistema de arquivos do host, uso de hostNetwork e imagens de contêiner `:latest` ou não reproduzíveis não reproduzíveis. As descobertas são agrupadas por documento e por contêiner, com uma gravidade clara de erro/aviso em cada uma, para que você possa distinguir o que é realmente arriscado daquilo que é apenas um empurrãozinho de práticas recomendadas.

Ele funciona em manifestos únicos ou arquivos inteiros de vários documentos colados diretamente de uma renderização de modelo Helm ou uma saída `kustomize build`, entendendo os recursos Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet e CronJob. Como tudo é executado localmente, é seguro colar manifestos que contenham nomes de serviços internos, dimensionamento real de recursos ou qualquer outra coisa que você não gostaria de enviar para uma API de terceiros - útil para uma rápida verificação de integridade pré-confirmação, um auxílio de revisão de código ou apenas aprender como realmente é "endurecido" na prática.