Kubernetes Manifest Linter

Manifestele Kubernetes sunt de obicei revizuite cu ochii într-o cerere de extragere, ceea ce înseamnă că aceleași greșeli de întărire continuă să ajungă în producție: o implementare fără limită de memorie care în cele din urmă este ucisă de OOM și ia un nod cu el, un container care rulează fericit ca root pentru că nimeni nu a stabilit runAsNonRoot sau un Pod fixat pe o etichetă de imagine de genul ăsta. Acest linter prinde acea clasă de probleme în momentul în care lipiți un manifest, fără a avea nevoie de un cluster care rulează, context kubectl sau orice acreditări.

Sub capotă include un mic parser YAML rulat manual, scris special pentru subsetul realist de YAML pe care Kubernetes îl folosește de fapt: `---`-documente separate, imbricare bazată pe indentație, `cheie: valoare` și mapări bloc imbricate, `-` articole de secvență care includ liste de hărți, cotate și `` blocuri, `` și>` comentate` scalari pentru lucruri precum valorile sau adnotările ConfigMap pe mai multe linii. Nu este implicată nicio bibliotecă YAML externă - analizatorul și motorul de reguli sunt ambele incluse cu instrumentul și rulează în întregime în browser.

Tabelul de reguli este modelat pe îndrumări bine-cunoscute de consolidare a cluster-ului - benchmark-ul CIS Kubernetes, scorul kube și profilul „Restricționat” al standardelor de securitate Pod - și verifică fiecare container pentru solicitări/limite de resurse lipsă, containere care pot rula ca rădăcină sau în mod privilegiat, sonde lipsă de viabilitate și pregătire pe setări care rulează îndelungat, setări de lucru, încărcături de lucru îndelungate Se montează volumul hostPath care expun sistemul de fișiere gazdă, utilizarea rețelei gazdă și imaginile containerului nereproducibile `:latest` sau neetichetate. Constatările sunt grupate în funcție de document și de container, cu o severitate clară a erorii/avertismentelor pe fiecare, astfel încât să puteți spune ce este de fapt riscant din ceea ce este doar o bună practică.

Funcționează pe manifeste individuale sau fișiere întregi cu mai multe documente lipite direct dintr-un șablon Helm de randare sau o ieșire „customize build”, înțelegerea resurselor Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet și CronJob. Deoarece totul rulează local, este sigur să lipiți manifeste care conțin nume de servicii interne, dimensionarea reală a resurselor sau orice altceva pe care nu ați dori să trimiteți la un API terță parte - util pentru o verificare rapidă a stării de spirit înainte de comitere, un ajutor pentru revizuirea codului sau doar pentru a învăța cum arată de fapt „întărit” în practică.