Kubernetes Manifest Linter

A Kubernetes leírófájlokat általában pull request-ekben, szemmel vizsgálják át, így ugyanazok a védelmi hibák újra és újra kijutnak a productionbe: egy Deployment memóriakorlát nélkül, amit végül OOM-kill ér, és magával visz egy node-ot; egy konténer, ami boldogan fut root-ként, mert senki sem állította be a runAsNonRoot-ot; vagy egy Pod, ami egy `:latest`-hez hasonló képcímkére van rögzítve, ami észrevétlenül változik egy rollout során. Ez az ellenőrző pontosan ezt a hibacsoportot kapja el, amint beillesztesz egy leírófájlt, anélkül hogy futó clusterre, kubectl contextre vagy bármilyen hitelesítő adatra szükség lenne.

A motorháztető alatt egy kis, saját YAML elemző található, amelyet kifejezetten a Kubernetes leírófájlok által ténylegesen használt YAML valósághű részhalmazára írtak: `---`-elválasztású dokumentumok, behúzásalapú egymásba ágyazás, `key: value` és beágyazott blokk-mapstruktúrák, `- ` szekvenciaelemek – beleértve a map-ek listáit –, idézőjeles és idézőjel nélküli skalárok, megjegyzések, valamint `|`/`>` blokk-skalárok többsoros ConfigMap értékekhez vagy annotációkhoz. Nincs semmilyen külső YAML könyvtár – az elemző és a szabálymotor egyaránt a tool része, és teljes mértékben a böngésződben fut.

A szabálylista ismert cluster-védelmi útmutatásokra – a CIS Kubernetes Benchmark, a kube-score és a Pod Security Standards „Restricted” profilja – épül, és konténerenként ellenőrzi a következőket: hiányzó erőforrás-kérelmek/korlátok; root-ként vagy privileged módban futó konténerek; hiányzó liveness és readiness próbák hosszan futó terheléseknél (Deployment, StatefulSet, DaemonSet); hostPath kötetcsatolások, amelyek kitárják a host fájlrendszerét; hostNetwork használat; valamint a nem reprodukálható `:latest` vagy címkézetlen konténerképek. A találatok dokumentumonként és konténerenként vannak csoportosítva, egyértelmű hiba/figyelmeztetés súlyossággal minden egyes elemnél, így meg tudod ítélni, mi valóban kockázatos, és mi csupán egy bevált gyakorlat szerinti emlékeztető.

Működik egyedi leírófájlokkal vagy akár teljes, többdokumentumos fájlokkal is, amelyeket közvetlenül egy Helm template renderből vagy egy `kustomize build` kimenetből illesztesz be, és felismeri a Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet és CronJob erőforrásokat. Mivel minden helyben fut, biztonságosan beilleszthetők olyan leírófájlok, amelyek belső szolgáltatásneveket, valós erőforrás-méretezést vagy bármi mást tartalmaznak, amit nem küldenél ki egy külső API-nak – hasznos egy gyors pre-commit ellenőrzéshez, code review segédletként vagy egyszerűen csak ahhoz, hogy a gyakorlatban is lásd, mit takar a „védett” állapot.