Kubernetes Manifest Linter

Kubernetes-Manifeste werden normalerweise in einem Pull-Request nach Augenmaß überprüft, was bedeutet, dass immer wieder dieselben Härtungsfehler in die Produktion gelangen: ein Deployment ohne Speicherbeschränkung, das schließlich durch OOM beendet wird und einen Knoten mitnimmt, ein Container, der gerne als Root ausgeführt wird, weil niemand runAsNonRoot festgelegt hat, oder ein Pod, der an ein Image-Tag wie „:latest“ angeheftet ist und sich im Laufe eines Rollouts stillschweigend ändert. Dieser Linter fängt diese Art von Problem ab, sobald Sie ein Manifest einfügen, ohne dass ein laufender Cluster, ein Kubectl-Kontext oder irgendwelche Anmeldeinformationen erforderlich sind.

Unter der Haube befindet sich ein kleiner handgerollter YAML-Parser, der speziell für die realistische Teilmenge von YAML geschrieben wurde, die Kubernetes-Manifeste tatsächlich verwenden: „---“-getrennte Dokumente, einrückungsbasierte Verschachtelung, „key: value“ und verschachtelte Blockzuordnungen, „-“-Sequenzelemente einschließlich Listen von Zuordnungen, Skalare in Anführungszeichen und ohne Anführungszeichen, Kommentare und „|`/`>“-Blockskalare für Dinge wie Mehrzeilen ConfigMap-Werte oder Anmerkungen. Es ist keine externe YAML-Bibliothek beteiligt – der Parser und die Regel-Engine sind beide im Lieferumfang des Tools enthalten und werden vollständig in Ihrem Browser ausgeführt.

Die Regeltabelle basiert auf bekannten Cluster-Hardening-Anleitungen – dem CIS Kubernetes Benchmark, kube-score und dem „Restricted“-Profil der Pod Security Standards – und überprüft jeden Container auf fehlende Ressourcenanforderungen/-limits, Container, die als Root oder im privilegierten Modus ausgeführt werden können, fehlende Liveness- und Bereitschaftsprüfungen für lang laufende Workloads (Bereitstellungen, StatefulSets, DaemonSets), hostPath-Volume-Mounts, die das Host-Dateisystem offenlegen, hostNetwork Nutzung und nicht reproduzierbare „:latest“- oder nicht getaggte Container-Images. Die Ergebnisse werden nach Dokument und Container gruppiert, mit einem klaren Fehler-/Warnungsschweregrad für jedes einzelne, sodass Sie erkennen können, was tatsächlich riskant ist und was lediglich ein Best-Practice-Anstoß ist.

Es funktioniert mit einzelnen Manifesten oder ganzen Dateien mit mehreren Dokumenten, die direkt aus einem Helm-Vorlagenrendering oder einer Kustomize-Build-Ausgabe eingefügt werden, und versteht Pod-, Deployment-, StatefulSet-, DaemonSet-, Job-, ReplicaSet- und CronJob-Ressourcen. Da alles lokal ausgeführt wird, ist es sicher, Manifeste einzufügen, die interne Dienstnamen, tatsächliche Ressourcengrößen oder alles andere enthalten, was Sie nicht an eine API eines Drittanbieters senden möchten – nützlich für eine schnelle Überprüfung der Integrität vor dem Commit, als Hilfe bei der Codeüberprüfung oder einfach nur, um zu lernen, wie „gehärtet“ in der Praxis tatsächlich aussieht.