Kubernetes Manifest Linter

Manifesti Kubernetes se običajno pregledajo na oko v zahtevi za vleko, kar pomeni, da ista peščica utrjevalnih napak še naprej prihaja do produkcije: uvedba brez omejitve pomnilnika, ki jo na koncu uniči OOM in s seboj vzame vozlišče, vsebnik, ki se srečno izvaja kot root, ker nihče ni nastavil runAsNonRoot, ali Pod, pripet na slikovno oznako, kot je `:latest`, ki se tiho spremeni pod uvajanje. Ta linter ujame ta razred težav v trenutku, ko prilepite manifest, ne da bi potrebovali delujočo gručo, kontekst kubectl ali kakršne koli poverilnice.

Pod pokrovom vključuje majhen ročno zvit razčlenjevalec YAML, napisan posebej za realistično podmnožico YAML, ki jo manifesti Kubernetes dejansko uporabljajo: `---`-ločeni dokumenti, gnezdenje na podlagi zamikov, `ključ: vrednost` in ugnezdene preslikave blokov, `-` postavke zaporedja, vključno s seznami zemljevidov, skalarji v narekovajih in brez narekovajev, komentarji in skalarji blokov `|`/`>` za stvari, kot so večvrstične vrednosti ConfigMap ali opombe. Zunanja knjižnica YAML ni vključena — razčlenjevalnik in mehanizem pravil sta priložena orodju in se v celoti izvajata v vašem brskalniku.

Tabela pravil je oblikovana po dobro znanih navodilih za utrjevanje gruč — merilo CIS Kubernetes Benchmark, kube-score in profil Pod Security Standards »Restricted« — in preveri vsak vsebnik glede manjkajočih zahtev/omejitev virov, vsebnikov, ki se lahko izvajajo kot root ali v privilegiranem načinu, manjkajočih sond živahnosti in pripravljenosti pri dolgotrajnih delovnih obremenitvah (razmestitve, StatefulSets, DaemonSets), namestitve nosilca hostPath, ki razkrijejo gostiteljski datotečni sistem, uporabo gostiteljskega omrežja in neponovljive `:latest` ali neoznačene slike vsebnika. Ugotovitve so razvrščene po dokumentih in vsebnikih z jasno izraženo resnostjo napake/opozorila, tako da lahko ločite, kaj je dejansko tvegano, od tistega, kar je le spodbuda najboljše prakse.

Deluje na posameznih manifestih ali celotnih datotekah z več dokumenti, ki so prilepljene naravnost iz upodobitve predloge Helm ali izhoda `kustomize build`, pri čemer razume vire Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet in CronJob. Ker se vse izvaja lokalno, je varno prilepiti manifeste, ki vsebujejo imena notranjih storitev, pravo velikost vira ali karkoli drugega, česar ne bi želeli poslati v API tretje osebe – uporabno za hitro preverjanje razumnosti pred potrditvijo, pomoč pri pregledu kode ali samo učenje, kako "utrjeno" dejansko izgleda v praksi.