Kubernetes Manifest Linter

Kubernetes-Manifests werden meist im Pull Request mit bloßem Auge geprüft – deshalb schaffen es immer dieselben Härtungsfehler in die Produktion: ein Deployment ohne Memory-Limit, das schließlich OOM-gekillt wird und einen Knoten mitreißt; ein Container, der munter als root läuft, weil niemand runAsNonRoot gesetzt hat; oder ein Pod, der auf ein Image-Tag wie `:latest` festgenagelt ist, das sich bei einem Rollout stillschweigend ändert. Dieser Linter fängt genau diese Problemklasse ab, sobald Sie ein Manifest einfügen – ohne laufenden Cluster, kubectl-Kontext oder irgendwelche Zugangsdaten.

Unter der Haube steckt ein schlanker, selbst geschriebener YAML-Parser, speziell für die realistische YAML-Teilmenge, die Kubernetes-Manifests tatsächlich nutzen: `---`-getrennte Dokumente, einrückungsbasierte Verschachtelung, `key: value` und verschachtelte Block-Mappings, `- `-Sequenzen inklusive Listen von Maps, gequotete und ungequotete Skalare, Kommentare sowie `|`/`>`-Block-Skalare für Dinge wie mehrzeilige ConfigMap-Werte oder Annotationen. Keine externe YAML-Bibliothek im Spiel – sowohl der Parser als auch die Regel-Engine sind im Tool gebündelt und laufen komplett in Ihrem Browser.

Die Regeltabelle orientiert sich an etablierten Cluster-Härtungsleitfäden – dem CIS Kubernetes Benchmark, kube-score und dem „Restricted“-Profil der Pod Security Standards – und prüft jeden Container auf fehlende Ressourcen-Requests/Limits, Container, die als root oder im privilegierten Modus laufen dürfen, fehlende Liveness- und Readiness-Probes bei langlebigen Workloads (Deployments, StatefulSets, DaemonSets), hostPath-Volume-Mounts, die das Host-Dateisystem exponieren, hostNetwork-Nutzung und nicht reproduzierbare `:latest`- oder ungetaggte Container-Images. Die Ergebnisse werden nach Dokument und nach Container gruppiert, mit klarer Fehler-/Warnungs-Schweregradeinstufung, sodass Sie auf Anhieb erkennen, was wirklich riskant ist und was lediglich ein Best-Practice-Hinweis.

Das Tool funktioniert mit einzelnen Manifests oder ganzen Multi-Document-Dateien, wie sie etwa direkt aus einem Helm-Template-Render oder einem `kustomize build`-Output stammen, und versteht Pod-, Deployment-, StatefulSet-, DaemonSet-, Job-, ReplicaSet- und CronJob-Ressourcen. Da alles lokal ausgeführt wird, können Sie bedenkenlos Manifests mit internen Servicenamen, echten Ressourcengrößen oder anderen Daten einfügen, die Sie nicht an eine Drittanbieter-API senden möchten – nützlich für einen schnellen Pre-Commit-Plausibilitätscheck, als Code-Review-Hilfe oder einfach, um zu lernen, wie „gehärtet“ in der Praxis tatsächlich aussieht.