Die GitOps-Politik Kubernetes wird verwaltbar, wenn die Durchsetzung in den Lieferprozess integriert ist. Die Kombination aus Kyverno und Argo CD schließt diese Lücke auf der Ebene der Zulassung.
Das Problem tritt nicht sofort auf – bis der Cluster beginnt, Ressourcen zu akzeptieren, die außerhalb des kontrollierten Prozesses erstellt wurden. Argo CD löst das Problem des deklarativen Zustandsmanagements, validiert jedoch nicht die Manifestdateien selbst auf Übereinstimmung mit den Richtlinien. Infolgedessen gelangen Fehlkonfigurationen und unsichere Einstellungen in die Produktion, wenn sie syntaktisch korrekt sind. Dies ist besonders in Multi-Tenant-Umgebungen auffällig, in denen verschiedene Teams Änderungen mit unterschiedlichem Reifegrad einpflegen.
Die Lösung basiert auf Kyverno als Policy-Engine für Kubernetes. Es arbeitet auf der Ebene des Admission Controllers und überprüft jede Ressource vor ihrer Erstellung. Der Schlüsselpunkt ist, dass die Richtlinien im standardmäßigen Kubernetes YAML beschrieben werden. Dies schließt die Lücke zwischen Konfiguration und Governance: dieselben GitOps-Prozesse werden sowohl auf die Infrastruktur als auch auf die Regeln angewendet. In Kombination mit Argo CD ergibt sich ein einheitlicher Prozess: Richtlinien werden versioniert, durchlaufen Reviews und werden automatisch angewendet. Der Kompromiss ist hier offensichtlich: Strenge Richtlinien können Deployments blockieren und die Lieferung verlangsamen, weshalb ein Audit-Modus als Zwischenstufe eingeführt wird.
Die Implementierung stützt sich auf das App-of-Apps-Muster in Argo CD. Eine Root-Anwendung verwaltet eine Reihe von untergeordneten Anwendungen, von denen jede eine separate Komponente über Helm bereitstellt. Kyverno wird als separate Anwendung mit dem offiziellen Helm-Chart installiert, das in ein lokales Chart eingebettet ist. Wichtig ist, dass die Sync-Wave-Annotation angewendet wird: Zuerst wird Kyverno selbst bereitgestellt, dann die Richtlinien. Ohne dies wird die Reihenfolge gestört, und die Richtlinien werden nicht angewendet.
Es gibt mehrere technische Nuancen, die die Stabilität beeinflussen:
- ServerSideApply=true wird aufgrund der großen Größe des CRD Kyverno verwendet, die die Grenzen des Client-Side Apply überschreiten kann
- IncludeMutationWebhook=true verhindert falsche OutOfSync-Zustände, da Kyverno Ressourcen mutieren kann
- ServerSideDiff=true verbessert den Vergleich von Zuständen, indem Änderungen auf der Seite der Zulassung berücksichtigt werden
Die Richtlinien werden als separate Anwendung ebenfalls über Helm bereitgestellt. Das offizielle kyverno-policies-Chart wird als Abhängigkeit verwendet. Die Grundkonfiguration umfasst den Pod Security Standard auf Baseline-Ebene. Dies ist eine Kompromisswahl: Offensichtliche Risiken wie privilegierte Container oder Host-Netzwerke werden blockiert, aber die Kompatibilität mit den meisten Workloads bleibt erhalten. Der Modus validationFailureAction wird zunächst auf Audit gesetzt, um Signale über Verstöße zu sammeln, ohne zu blockieren.
Zusätzlich ist eine Schicht benutzerdefinierter Richtlinien über das Verzeichnis templates/ vorgesehen. Dies ist ein wichtiger architektonischer Punkt: Standardrichtlinien und organisationsspezifische Regeln sind getrennt, durchlaufen jedoch dasselbe Pipeline. Nach dem Commit synchronisiert Argo CD automatisch die Änderungen, und Kyverno beginnt, sie ohne manuelle Eingriffe anzuwenden.
Ein gutes Beispiel ist das Verbot der Verwendung von externalIPs in Services. Dies ist ein bekannter Angriffsvektor (CVE-2020-8554), der es ermöglicht, den Datenverkehr abzufangen. Die Kyverno-Richtlinie validiert das Fehlen dieses Feldes. Im Enforce-Modus wird eine solche Ressource einfach nicht erstellt. Im Audit-Modus wird sie als Verstoß in den Bericht aufgenommen.
Das Ergebnis ist eine Verschiebung der Kontrolle nach links (shift-left), ohne den gewohnten GitOps-Workflow zu ändern. Wenn eine Richtlinie im Enforce-Modus verletzt wird, markiert Argo CD die Anwendung als OutOfSync oder Degraded und zeigt einen Validierungsfehler an. Dies macht Probleme in der Synchronisationsphase sichtbar und nicht erst nach einem Vorfall. Im Audit-Modus erhalten die Teams Berichte über PolicyReport und ClusterPolicyReport, was es ermöglicht, die Auswirkungen vor einer Verschärfung der Regeln zu bewerten.
Im Ausgangsmaterial werden keine Metriken angegeben, aber der verhaltensbezogene Effekt ist offensichtlich: Das System hört auf, inkonsistente oder unsichere Ressourcen zu akzeptieren. Dabei bleibt die Transparenz der Änderungen über Git erhalten. Dieser Ansatz erscheint als evolutionäre Verstärkung von GitOps, bei der die Richtlinie Teil des deklarativen Zustands wird und nicht ein externer Kontrollprozess ist.