Kubernetes Manifest Linter

Kubernetes-manifesten worden meestal met het oog beoordeeld in een pull-verzoek, wat betekent dat dezelfde handvol verhardingsfouten de productie blijven bereiken: een implementatie zonder geheugenlimiet die uiteindelijk door OOM wordt gedood en een knooppunt meeneemt, een container die met plezier als root draait omdat niemand runAsNonRoot heeft ingesteld, of een pod die is vastgemaakt aan een afbeeldingstag zoals `:latest` die stil verandert tijdens een uitrol. Met deze linter wordt dat type probleem onderschept op het moment dat u een manifest erin plakt, zonder dat u een actief cluster, kubectl-context of enige inloggegevens nodig hebt.

Onder de motorkap bevat het een kleine handgerolde YAML-parser die speciaal is geschreven voor de realistische subset van YAML die Kubernetes-manifesten feitelijk gebruiken: `---`-gescheiden documenten, op inspringingen gebaseerde nesting, `sleutel: waarde` en geneste bloktoewijzingen, `- ` reeksitems inclusief lijsten met kaarten, geciteerde en niet-geciteerde scalaires, opmerkingen en `|`/`>` blokscalaire waarden voor zaken als ConfigMap-waarden met meerdere regels of annotaties. Er is geen externe YAML-bibliotheek bij betrokken: de parser en de regelengine worden beide bij de tool geleverd en draaien volledig in uw browser.

De regeltabel is gemodelleerd op bekende richtlijnen voor clusterverharding – de CIS Kubernetes Benchmark, kube-score en het Pod Security Standards ‘Restricted’ profiel – en controleert elke container op ontbrekende resourceverzoeken/-limieten, containers die als root of in geprivilegieerde modus kunnen worden uitgevoerd, ontbrekende liveness- en gereedheidstests op langlopende workloads (Deployments, StatefulSets, DaemonSets), hostPath-volumekoppelingen die het hostbestandssysteem blootleggen, hostNetwork-gebruik en niet-reproduceerbare `:latest` of niet-gelabelde containerimages. De bevindingen zijn gegroepeerd per document en per container, met bij elk document een duidelijke fout-/waarschuwingsernst, zodat u kunt zien wat feitelijk riskant is aan de hand van wat slechts een duwtje in de rug is.

Het werkt op afzonderlijke manifesten of volledige bestanden met meerdere documenten die rechtstreeks vanuit een Helm-sjabloonweergave of een `kustomize build`-uitvoer zijn geplakt, waarbij Pod-, Deployment-, StatefulSet-, DaemonSet-, Job-, ReplicaSet- en CronJob-bronnen worden begrepen. Omdat alles lokaal draait, is het veilig om manifesten te plakken die interne servicenamen, echte brongroottes of iets anders bevatten dat je niet naar een API van derden wilt sturen. Handig voor een snelle controle vooraf, als hulp bij het beoordelen van de code, of om gewoon te leren hoe 'verhard' er in de praktijk uitziet.