Kubernetes kann schnell zu einer komplexen und zeitraubenden Angelegenheit werden. Zum Glück gibt es jedoch einige praktische Werkzeuge, die dir den Alltag erheblich erleichtern können. Heute möchte ich drei meiner Lieblings-Helferlein genauer vorstellen. Mit diesen Werkzeugen wirst du Zeit und Nerven sparen sowie die Automatisierung deiner Umgebung weiter vorantreiben.
Konkret wirst du in diesem Artikel lernen, wie du deine YAML-Manifeste parametrisieren kannst, die Einhaltung aller Sicherheitsrichtlinien automatisch überwachen kannst und wie dich fehlende Leerzeichen nie mehr zur Weißglut bringen werden. Du merkst also schon, heute bringen wir mal so richtig Schwung in deine Arbeit!
Kyverno – Top Policy Manager:
Das Festlegen und Durchsetzen von Richtlinien ist ein zentraler Bestandteil von DevSecOps. Genau hier kommt die Policy-Engine Kyverno ins Spiel. Speziell für Kubernetes Plattform Engineering Teams entwickelt, ermöglicht das Tool durch den Einsatz von Policy-as-Code umfassende Sicherheit, Automatisierung, Compliance und Governance.
Kyverno überprüft und kann die Einhaltung von Richtlinien überprüfen, bevor Ressourcen überhaupt in das Cluster aufgenommen werden. Es gibt dabei zwei Hauptmodi, in denen Policies definiert und implementiert werden können. Da wäre einerseits überwachend (audit) und andererseits durchsetzend (enforce). Im Überwachungsmodus werden Verstöße zwar erkannt, aber nur protokolliert.
Dies ermöglicht eine sanfte Einführung neuer Richtlinien und das Erkennen potenzieller Probleme, ohne die laufenden Prozesse zu beeinträchtigen. Im Durchsetzungsmodus hingegen werden Ressourcen, die den definierten Richtlinien nicht entsprechen, abgelehnt. Dies stellt sicher, dass nur konforme Ressourcen im Cluster bereitgestellt werden, was die Sicherheit der Umgebung erhöht.
Dabei ist zu beachten, dass auch bereits bestehende und damit produktive Ressourcen überprüft werden. Wenn man beispielsweise nur die hauseigene Registry als sichere Quelle definiert, kann ein gewöhnliches Kubernetes-Cluster in sich zusammen brechen, da die Images der Systembestandteile aus öffentlichen und damit untersagten Container-Registries stammen.
Zusammenfassend betrachtet sprechen für Kyverno folgende Punkte:
- Policies werden als Kubernetes-Ressourcen verwaltet, sodass keine neue Programmiersprache erforderlich ist, um Policies zu schreiben.
- Dies ermöglicht die Verwendung vertrauter Werkzeuge wie Kubectl, Git und Kustomize zur Verwaltung aller Policies.
- Kyverno-Policies können Kubernetes-Ressourcen validieren, ändern, erzeugen und bereinigen sowie Image-Signaturen und Artefakte überprüfen, um die Sicherheit der Software-Lieferkette zu gewährleisten.
Besonders interessant finde ich dabei die eigene CLI, die innerhalb der CI/CD-Pipeline in einem Skript genutzt werden kann, um die Manifeste auf Policy-Verstöße überprüfen zu können. Darüber hinaus lässt sich die CLI nicht nur eigenständig verwenden, sondern auch als Kubectl-Plugin einsetzen. Wie es sich für ein solches Tool gehört, gibt es daneben auch noch ein eigens Container-Image.
KubeLinter – 1A Code Analyzer:
Kubernetes-Manifeste werden in YAML geschrieben, wodurch die korrekte Einrückung von größter Bedeutung ist. Schon ein kleiner Flüchtigkeitsfehler kann dazu führen, dass das Objekt entweder gar nicht erst im ETCD landet oder fehlerhaft in Betrieb geht. Aufgrund dessen empfiehlt sich der Einsatz eines sogenannten Linters.
Diese können aber noch weit mehr als nur die YAML-Syntax der Manifeste zu prüfen. So werden beispielsweise Hinweise gegeben, wenn man sich nicht an bewährten Sicherheitskonfigurationen bei Helm Charts oder YAML-Dateien hält. Zu den häufigsten Beispielen hierfür gehören die Ausführung von Containern als Nicht-Root-Benutzer oder das Vergeben von zu vielen Privilegien.
Mein derzeitiges Lieblings-Tool ist dabei KubeLinter. Hier können eigene Checks erstellt oder bereits vorhandene Prüfungen erweitert und sogar vollständig deaktiviert werden. Besonders praktisch finde ich den Non-Zero-Exit-Code bei Syntax-Fehlern oder Verstößen gegen Richtlinien, wodurch sich das Tool sinnvoll in bestehende CI/CD-Pipelines integrieren lässt.
Im Großen und Ganzen ist KubeLinter ein patentes Werkzeug zur Analyse von YAML-Manifesten. Es dient dazu, potenzielle Fehler, Sicherheitslücken und Abweichungen von bewährten Praktiken in Kubernetes-Konfigurationsdateien frühzeitig zu erkennen und so die Qualität und Zuverlässigkeit der deployten Ressourcen zu erhöhen.
Linting-Tools können sowohl innerhalb der CI-Pipeline als auch auf dem Entwickler-Rechner eingesetzt werden, um Manifeste zu validieren. Zudem geben sie in einer Pull-Request-Pipeline eine sehr gute Figur ab. An dieser Stelle liefern sie nämlich schnell und unkompliziert direkte Hinweise zur Code-Qualität. Neben KubeLinter habe ich auch sehr gute Erfahrungen mit Kubeconform gemacht.
Kustomize – Simples Templating:
Um eine Kubernetes-native Anwendung einheitlich und fehlerfrei in verschiedenen Umgebungen wie Entwicklung, Staging und Produktion bereitzustellen, wird oft eine beträchtliche Menge Code im Git hin- und herkopiert. Dieses Vorgehen ist nicht nur zeitaufwändig, sondern auch fehleranfällig. Hier kommt Kustomize mit seiner genialen wie simplen Overlay-Struktur ins Spiel.
Durch das Konzept der Parametrisierung werden hier Änderungen auf Basis-YAML-Dateien angewendet. Dabei bleibt die ursprüngliche Datei unberührt und man muss auch keine komplexe Template-Syntax wie bei Helm erlernen. Stattdessen genügt es, sich etwas mit Kubectl auszukennen. Das Tool ist darin nämlich bereits enthalten.
Darüber hinaus sprechen noch folgende Punkte für Kustomize:
- Die Basiskonfigurationen können zudem in unterschiedlichen Projekten oder Kontexten wieder verwendet werden. Das spart Zeit und fördert zudem die Modularität ungemein.
- In herkömmlichen CI/CD-Pipelines wird üblicherweise auf eine imperativ gesteuerte Vorgehensweise gesetzt, um vom Rohcode zur betriebsbereiten Anwendung zu gelangen. Für Administratoren, die Kubernetes zur Bereitstellung von fertigen Anwendungen nutzen, bietet sich jedoch die Kombination aus Kustomize und GitOps als effektivere Lösung an.
- Kustomize setzt ausschließlich auf YAML. Aufgrund dessen können die erstellen Manifeste direkt validiert und von Kubernetes verarbeitet werden. Die Handhabung ist so natürlich besonders einfach und muss nicht wie bei Helm extra erlernt werden. Zudem spart man sich hier die Chart- und Values-Datei.
- Natürlich können nicht nur Parameter bestimmter Manifeste geändert werden. So kann man mit Kustomize auch Massenanpassungen durchzuführen. Man denke dabei an einen typischen Use-Case wie alle Ressourcen in einem Namespace brauchen ein bestimmtes Label.
Zusammenfassend gesagt bietet Kustomize eine gute Möglichkeit, mit wenig Aufwand Manifeste für mehrere Umgebungen bereitzustellen, ohne sich dabei langwierig in ein neues Tool einarbeiten zu müssen. In Kombination mit Git zur zentralen Codeverwaltung und einem darauf aufbauen Deployment-Tool wie Argo CD kann man damit das Bereitstellen fertiger Anwendungen zentralisieren.