Kubernetes Manifest Linter

A Kubernetes jegyzékeit általában szemmel ellenőrzik egy lehívási kérelemben, ami azt jelenti, hogy ugyanaz a maroknyi keményítési hiba kerül a termelésbe: egy memóriakorlát nélküli telepítés, amely végül OOM-kiölést kap, és magával visz egy csomópontot, egy tároló, amely boldogan fut rootként, mert senki sem állította be a runAsNonRoot-ot, vagy egy Pod, amely egy olyan képcímkéhez van rögzítve, amely a rollane változásait, például a következőt: Ez a linter azonnal felismeri ezt a problémaosztályt, amint beilleszt egy manifestet, anélkül, hogy futó fürtre, kubectl-környezetre vagy bármilyen hitelesítő adatra lenne szüksége.

A motorháztető alatt található egy kis, kézzel görgetett YAML-elemző, amelyet kifejezetten a YAML valósághű részhalmazához írtak, amelyet a Kubernetes manifest valójában használ: `---`-elválasztott dokumentumok, behúzás alapú egymásba ágyazás, `kulcs: érték` és beágyazott blokkleképezések, `- ` sorozatelemek, beleértve a térképek listáját, idézőjeles és idézőjel nélküli blokkok, megjegyzések/>ar`. skalárokat olyan dolgokhoz, mint a többsoros ConfigMap értékek vagy megjegyzések. Nincs külső YAML-könyvtár – az elemző és a szabálymotor egyaránt az eszközhöz van kötve, és teljes egészében a böngészőben fut.

A szabálytáblázat jól ismert fürtkeményítési útmutató alapján készült – a CIS Kubernetes Benchmark, a kube-score és a Pod Security Standards „Restricted” profilja –, és minden tárolóban ellenőrzi a hiányzó erőforráskéréseket/korlátokat, a gyökérként vagy privilegizált módban futtatható tárolókat, a hiányzó élőképességet és a készenléti próbákat, a long-etrunning munkaterheléseket. DaemonSets), hostPath kötetcsatlakozások, amelyek felfedik a gazdagép fájlrendszerét, a hostNetwork használatát és a nem reprodukálható ":legújabb" vagy címkézetlen tárolóképeket. A megállapítások dokumentumonként és tárolónként vannak csoportosítva, mindegyiken egyértelmű hiba/figyelmeztetés súlyosság szerepel, így pusztán egy bevált gyakorlati bökkenőből meg tudja állapítani, hogy mi a kockázatos.

Működik egyetlen manifest vagy teljes több dokumentumból álló fájlokon, amelyeket közvetlenül egy Helm sablon renderelésből vagy egy "kustomize build" kimenetből illesztenek be, megértve a Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet és CronJob erőforrásokat. Mivel minden helyileg fut, biztonságosan beilleszthet olyan jegyzékeket, amelyek belső szolgáltatásneveket, valós erőforrás-méretezést vagy bármi mást tartalmaznak, amit nem szeretnének elküldeni egy harmadik fél API-nak – hasznos lehet egy gyors elfogadás előtti józansági ellenőrzéshez, egy kód-ellenőrzési segédlethez, vagy egyszerűen csak megtudhatja, hogyan is néz ki a „megerősített” a gyakorlatban.