Validatore di manifest Kubernetes

I manifest Kubernetes vengono solitamente rivisti a occhio in una pull request, il che significa che gli stessi pochi errori di hardening continuano ad arrivare in produzione: un Deployment senza limiti di memoria che alla fine viene terminato per OOM portandosi dietro un nodo, un container che viene eseguito tranquillamente come root perché nessuno ha impostato runAsNonRoot, o un Pod fissato a un tag immagine come `:latest` che cambia silenziosamente durante un rollout. Questo linter individua questa classe di problemi nel momento stesso in cui incolli un manifest, senza bisogno di un cluster in esecuzione, di un contesto kubectl o di alcuna credenziale.

Al suo interno include un piccolo parser YAML scritto a mano, specifico per il sottoinsieme realistico di YAML che i manifest Kubernetes utilizzano effettivamente: documenti separati da `---`, nidificazione basata sull'indentazione, `key: value` e mappature di blocchi annidati, elementi di sequenza `- ` comprese liste di mappe, scalari con e senza virgolette, commenti e scalari di blocco `|`/`>` per cose come valori ConfigMap multi-riga o annotazioni. Non è coinvolta alcuna libreria YAML esterna: sia il parser che il motore delle regole sono inclusi nello strumento e vengono eseguiti interamente nel browser.

La tabella delle regole è modellata su linee guida di hardening del cluster ben note — CIS Kubernetes Benchmark, kube-score e il profilo "Restricted" dei Pod Security Standards — e verifica ogni container per: richieste/limiti di risorse mancanti, container che possono essere eseguiti come root o in modalità privilegiata, probe di liveness e readiness mancanti su carichi di lavoro a lunga esecuzione (Deployment, StatefulSet, DaemonSet), montaggi di volumi hostPath che espongono il filesystem dell'host, utilizzo di hostNetwork e immagini container non riproducibili con tag `:latest` o senza tag. I rilievi sono raggruppati per documento e per container, con una chiara indicazione di gravità errore/avviso su ciascuno, in modo da poter distinguere ciò che è realmente rischioso da ciò che è semplicemente un suggerimento di best practice.

Funziona su singoli manifest o su interi file multi-documento incollati direttamente dall'output di un render di template Helm o di una `kustomize build`, comprendendo risorse Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet e CronJob. Poiché tutto viene eseguito localmente, è sicuro incollare manifest che contengono nomi di servizi interni, dimensionamenti reali delle risorse o qualsiasi altra cosa non vorresti inviare a un'API di terze parti — utile per un rapido controllo di sanity pre-commit, come supporto alla code review o semplicemente per imparare come appare nella pratica un sistema "hardened".