Linter manifesto di Kubernetes

I manifest di Kubernetes vengono solitamente esaminati visivamente in una richiesta pull, il che significa che gli stessi pochi errori di rafforzamento continuano ad arrivare alla produzione: una distribuzione senza limiti di memoria che alla fine viene uccisa da OOM e porta con sé un nodo, un contenitore che funziona felicemente come root perché nessuno ha impostato runAsNonRoot o un pod bloccato su un tag immagine come ":latest" che cambia silenziosamente durante un rollout. Questo linter rileva quella classe di problemi nel momento in cui incolli un manifest, senza bisogno di un cluster in esecuzione, di un contesto kubectl o di qualsiasi credenziale.

Sotto il cofano include un piccolo parser YAML scritto a mano scritto specificamente per il sottoinsieme realistico di YAML che i manifesti Kubernetes utilizzano effettivamente: documenti `---`-separati, nidificazione basata su indentazione, `chiave: valore` e mappature di blocchi nidificati, elementi di sequenza `- ` inclusi elenchi di mappe, scalari tra virgolette e senza virgolette, commenti e scalari a blocchi `|`/`>` per elementi come valori o annotazioni ConfigMap multilinea. Non è coinvolta alcuna libreria YAML esterna: il parser e il motore delle regole sono entrambi forniti in bundle con lo strumento e vengono eseguiti interamente nel tuo browser.

La tabella delle regole è modellata su linee guida ben note per il rafforzamento dei cluster (CIS Kubernetes Benchmark, kube-score e il profilo "Restricted" degli standard di sicurezza dei pod) e controlla in ogni contenitore eventuali richieste/limiti di risorse mancanti, contenitori che possono essere eseguiti come root o in modalità privilegiata, sonde di attività e disponibilità mancanti su carichi di lavoro a lunga esecuzione (deployment, StatefulSets, DaemonSets), montaggi di volumi hostPath che espongono il file system host, utilizzo di hostNetwork e immagini contenitore `:latest` o senza tag non riproducibili. I risultati sono raggruppati per documento e per contenitore, con una chiara gravità di errore/avviso su ciascuno di essi in modo da poter distinguere ciò che è effettivamente rischioso da ciò che è semplicemente una spintarella relativa alle migliori pratiche.

Funziona su singoli manifest o interi file multi-documento incollati direttamente da un rendering di modello Helm o da un output di `kustomize build`, comprendendo le risorse Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet e CronJob. Poiché tutto viene eseguito localmente, è sicuro incollare manifest che contengono nomi di servizi interni, dimensionamento reale delle risorse o qualsiasi altra cosa che non vorresti inviare a un'API di terze parti: utile per un rapido controllo di integrità pre-commit, un aiuto per la revisione del codice o semplicemente per imparare cosa significa effettivamente "hardened" nella pratica.