Kubernetes Manifest Linter

Kubernetes manifesti parasti tiek pārskatīti ar aci izvilkšanas pieprasījumā, kas nozīmē, ka ražošanas procesā tiek pieļautas tās pašas kļūdas: izvietošana bez atmiņas ierobežojuma, kas galu galā tiek iznīcināta ar OOM un paņem līdzi mezglu, konteiners, kas laimīgi darbojas kā root, jo neviens nav iestatījis runAsNonRoot, vai Pod, kas ir piesprausts attēlam, kas tiek mainīts, piemēram, klusi. Šī līkne uztver šo problēmu klasi brīdī, kad ielīmējat manifestu, un nav nepieciešams darboties klasteris, kubectl konteksts vai nekādi akreditācijas dati.

Zem pārsega ir iekļauts neliels, ar roku velmēts YAML parsētājs, kas rakstīts īpaši reālistiskajai YAML apakškopai, ko Kubernetes manifestā faktiski izmanto: "---" - atdalīti dokumenti, uz atkāpēm balstīta ligzdošana, "atslēga: vērtība" un ligzdotu bloku kartējumi, "-" secības vienumi, tostarp karšu saraksti, citēti un nekotēti bloki, komentāri un | skalāri tādām lietām kā vairāku rindu ConfigMap vērtības vai anotācijas. Nav iesaistīta ārēja YAML bibliotēka — gan parsētājs, gan kārtulu programma ir komplektā ar rīku un pilnībā darbojas jūsu pārlūkprogrammā.

Noteikumu tabula ir veidota pēc labi zināmām klasteru sacietēšanas vadlīnijām — CIS Kubernetes etalons, kube score un Pod drošības standartu "Ierobežotais" profils, un pārbauda, vai katrā konteinerā trūkst resursu pieprasījumu/ierobežojumu, konteinerus, kurus var palaist kā saknes vai priviliģētā režīmā, trūkst dzīvības un gatavības darba slodzes, ilgstošas izvietošanas darba slodzes. DaemonSets), hostPath sējuma stiprinājumi, kas atklāj resursdatora failu sistēmu, resursdatora tīkla lietojumu un neatkārtojamus “:jaunākos” vai nemarķētus konteinera attēlus. Rezultāti ir sagrupēti pēc dokumenta un konteinera, katram no tiem norādot skaidru kļūdu/brīdinājuma nopietnību, lai jūs varētu noteikt, kas patiesībā ir riskants, pamatojoties uz tikai paraugprakses pamudinājumu.

Tas darbojas ar atsevišķiem manifestiem vai veseliem vairāku dokumentu failiem, kas ielīmēti tieši no Helm veidnes renderēšanas vai "kustomize build" izvades, izprotot Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet un CronJob resursus. Tā kā viss darbojas lokāli, ir droši ielīmēt manifestus, kuros ir iekšējie pakalpojumu nosaukumi, reālie resursu lielumi vai jebkas cits, ko nevēlaties sūtīt uz trešās puses API — tas ir noderīgs ātrai saprāta pārbaudei pirms apņemšanās, koda pārskatīšanas palīglīdzeklim vai vienkārši mācībām, kā “sacietināts” patiesībā izskatās praksē.