Kyverno ist nicht nur ein Sicherheitstool, sondern eine zentrale Plattformkomponente

Koray Oksay, CNCF-Botschafter, ist der Ansicht, dass Unternehmen Kyverno häufig in die Verantwortung von Sicherheitsteams geben. Sie verwenden es, um Kubernetes-Konfigurationen zu validieren, Container zu blockieren, die mit Root-Berechtigungen ausgeführt werden, oder Sicherheitsstandards für Container durchzusetzen, und lassen anschließend einen großen Teil seiner Möglichkeiten ungenutzt. Laut Oksays Argumentation beschränkt diese gedankliche Einordnung Kyverno auf die Rolle eines „Gateways“, das fehlerhafte Konfigurationen verhindert. Es kann jedoch als grundlegender Baustein eingesetzt werden, auf dem Plattformteams ihre Services und Betriebsregeln aufbauen.

Diese Einschätzung beruht auf der Erfahrung des Autors, die mit einem Vortrag auf der KCD Munich im Jahr 2023 unter dem Titel „Sicherung von Kubernetes-Workloads mit Kyverno“ begann. Nach drei Jahren Arbeit in Produktionsumgebungen erklärt er, dass sich sein Interesse auf Governance, CEL und Self-Service für Plattformen verlagert habe und dass die Bezeichnung Kyvernos als „Policy Engine“ nicht mehr ausreiche, um seine Reichweite abzudecken.

Warum reicht die Sicherheitseinordnung nicht aus?

Oksay bestreitet nicht die Sicherheitsfunktionen von Kyverno. Die Plattform kann unsichere Konfigurationen blockieren, Pod Security Standards durchsetzen und Signaturen von Container-Images validieren. Ihre ausschließliche Verbindung mit Sicherheit verfestigt jedoch ein Modell, in dem Richtlinien als Barriere verstanden werden, deren Hauptzweck die Ablehnung ist und deren Erfolg an der Anzahl verhinderter Deployments gemessen wird.

Demgegenüber definiert der Autor vier zentrale Funktionen von Kyverno: Validierung, Änderung, Generierung und Image-Validierung. Die Validierungsfunktion gehört unmittelbar zum Barrierenmodell. Die Änderung verändert Ressourcen, bevor sie in den Cluster aufgenommen werden, die Generierung erstellt als Reaktion auf bestimmte Ereignisse neue Ressourcen, während sich die Image-Validierung auf den Aufbau von Vertrauen in die Images konzentriert und nicht nur auf die Abwehr von Bedrohungen. Daher ist er der Ansicht, dass drei der vier Funktionen einen konstruktiven Charakter haben, viele Unternehmen jedoch nur Validierungsrichtlinien einsetzen.

Was ist mit einer zentralen Plattformkomponente gemeint?

Oksay verwendet den Ausdruck „zentrale Komponente“ in einem Sinn, der seiner Verwendung in Programmiersprachen nahekommt: ein kleiner, verständlicher Baustein, der sich zum Aufbau größerer Systeme kombinieren lässt. Damit dieser Baustein tatsächlich eine Rolle in der Plattform spielt, sollte er Komplexität vor Entwicklern verbergen, automatische Garantien bieten, sich in andere Bausteine integrieren lassen und per Self-Service verfügbar sein, statt von manuellen Anfragen oder Support-Warteschlangen abzuhängen.

In diesem Sinne ähneln Kyverno-Richtlinien Komponenten wie Pods, Services, ConfigMaps und Crossplane-Kompositionen. Sie verwandeln die von der Organisation übernommenen Regeln in automatisches Verhalten innerhalb der Plattform.

Wie setzen Plattformteams es ein?

• Vorbereitung von Namespaces: Beim Erstellen eines Namespaces kann Kyverno standardmäßige NetworkPolicies, ResourceQuotas, LimitRanges und RoleBindings generieren, sodass der Namespace ohne weitere Vorbereitung bereitsteht und der Entwickler nicht daran denken muss, eine Liste manueller Schritte abzuarbeiten.
• Injektion von Sidecar-Containern: Überwachungsagenten, Netzwerkagenten oder Container zur Geheimnissynchronisierung können während der Admission-Phase in Pod-Spezifikationen eingefügt werden, während die Deployment-Datei einfach bleibt.
• Umschreiben von Image-Referenzen: Eine Referenz wie nginx:1.25 kann in mirror.internal/nginx:1.25 umgewandelt werden, damit Pull-Vorgänge über einen internen Mirror laufen, statt von jedem Entwickler die manuelle Ergänzung des Präfixes zu verlangen.
• Hinzufügen standardmäßiger Ressourcenanforderungen: Statt Pods zu blockieren, die keine CPU- und Speicheranforderungen festlegen, können geeignete Werte injiziert und bei Bedarf angepasst werden.
• Zuweisen von Eigentums-Tags: Team-, Kostenstellen- und Umgebungs-Tags können hinzugefügt werden, wenn die Werte eindeutig sind, oder erzwungen werden, wenn die Unklarheit Auswirkungen hat.

Was ändert sich in der Praxis?

Diese Anwendungsfälle verbinden eine gemeinsame Idee: eine organisatorische Überzeugung in eine unsichtbare automatische Garantie zu verwandeln. Die Regel kann sicherheitsbezogen sein, etwa das Verhindern von Containern mit hohen Berechtigungen, betrieblich, etwa das Durchsetzen von Ressourcenlimits, oder finanziell, etwa das Verknüpfen jeder Ressource mit einem Kostenstellen-Tag. Statt dass diese Regeln im Wiki, in Checklisten oder im Wissen eines einzelnen Ingenieurs verbleiben, werden sie zu als Code geschriebenen Richtlinien, in Git gespeichert und über GitOps-Tools und Kyverno angewendet.

Diese Perspektive schlägt vor, Richtlinien als Schnittstelle der Plattform zu betrachten, über die sich die Absicht der Organisation ausdrücken lässt. Bei ihrer Umsetzung werden Kyvernos Funktionen zu unterschiedlichen Ebenen: Die Validierung bietet Leitplanken, die Änderung schafft „vorgebahnte Wege“ für Entwickler, die Generierung liefert Vorlagen oder Grundkonfigurationen, und die Image-Validierung baut Vertrauen auf.

Die Teams werden Richtlinien außerdem als Produkte mit Versionen, Nutzern, Ausmusterungszyklen und nachvollziehbaren Ausnahmen behandeln. Die Einführung einer Richtlinie kann zunächst mit einer Prüfung, anschließend mit einer Warnung und schließlich mit einer schrittweisen Durchsetzung beginnen. Der Autor weist außerdem auf mögliche Koordinationsprobleme hin, wenn eine Richtlinie eine Ressource ändert, die Argo CD oder Flux als eigene Ressource betrachtet, was zu Synchronisierungsschleifen führen kann.

Oksays Schlussfolgerung lautet, dass die ausschließliche Betrachtung von Kyverno als Sicherheitswerkzeug einen großen Teil seiner Schnittstelle und seiner Möglichkeiten verdeckt. Seiner Ansicht nach ist es kein Wächter, der am Eingang des Clusters steht, sondern eine Schicht, die die Ansichten des Plattformteams mit dem tatsächlichen Verhalten von Ressourcen und Anwendungen verbindet.