Kyverno: Die Referenz-Architektur für Kubernetes-native Policy Management

TL;DR

Kubernetes ist standardmäßig permissiv: Es erlaubt Entwicklern fast alles, auch unsichere Konfigurationen (z.B. Container als “Root” laufen lassen). Um dies zu verhindern, brauchte man bisher Policy-Engines wie OPA Gatekeeper, die eine steile Lernkurve erfordern (Programmiersprache Rego). Kyverno demokratisiert Sicherheit. Es ist eine Policy-Engine, die für Kubernetes gebaut wurde. Policies sind einfaches YAML. Kyverno kann nicht nur blockieren (Validierung), sondern Ressourcen aktiv reparieren (Mutation) und Standard-Konfigurationen erzeugen (Generation) – ohne dass Entwickler ihren Workflow ändern müssen.

1. Das Architektur-Prinzip: Policy as YAML (No Rego!)

Die größte Hürde für Governance in Kubernetes war bisher die Sprache. Der Industriestandard Open Policy Agent (OPA) nutzt Rego, eine komplexe Abfragesprache. Wer eine Regel schreiben wollte (“Keine LoadBalancer ohne Kostenstelle”), musste programmieren lernen.

Kyverno ändert das Paradigma: Kubernetes-native Policies.

• YAML-basiert: Wenn Sie einen Pod definieren können, können Sie auch eine Kyverno-Policy schreiben. Es nutzt dieselben Strukturen und Muster wie Kubernetes selbst.
• Admission Controller: Kyverno klinkt sich als Webhook in den API-Server ein. Jeder Request (z.B. kubectl apply) wird von Kyverno geprüft, bevor er in die Datenbank (etcd) geschrieben wird.

2. Kern-Feature: Mutation & Generation (Automation statt Blockade)

Die meisten Policy-Tools können nur “Nein” sagen (Validierung). Das frustriert Entwickler (“Deployment failed”). Kyverno ist konstruktiver.

• Mutation (Silent Fixing): Ein Entwickler vergisst das Label team: marketing? Anstatt das Deployment abzulehnen, fügt Kyverno das Label automatisch hinzu. Ein Image hat kein Tag (:latest)? Kyverno ändert es zur Laufzeit auf den spezifischen Digest SHA.
• Generation (Self-Service): Das ist die Superkraft von Kyverno. Ein Entwickler erstellt einen neuen Namespace? Kyverno generiert automatisch die passenden NetworkPolicies, ResourceQuotas und Secrets für die Image-Registry hinein. Das ermöglicht echten Self-Service ohne Sicherheitslücken.

3. Supply Chain Security

Kyverno ist der Wächter Ihrer Software-Lieferkette. In Kombination mit Tools wie Cosign (Sigstore) prüft Kyverno kryptografische Signaturen.

Sie können eine Policy definieren: “Starte nur Images, die von unserer CI-Pipeline signiert wurden.”

Selbst wenn ein Angreifer Zugriff auf den Cluster hat und versucht, einen bösartigen Container zu starten, blockiert Kyverno den Request, weil die Signatur fehlt.

4. Betriebsmodelle im Vergleich: OPA Gatekeeper vs. ayedo Managed Kyverno

Hier entscheidet sich, ob Governance ein theoretisches Konzept bleibt oder gelebte Praxis wird.

Szenario A: OPA Gatekeeper (Die Experten-Hürde)

Gatekeeper ist mächtig, aber sperrig.

• Die Rego-Barriere: Um eine Policy zu schreiben oder zu debuggen, brauchen Sie Spezialisten. Ops-Teams scheuen oft den Aufwand, eigene Regeln zu schreiben, und verlassen sich auf Standard-Bibliotheken, die oft nicht genau passen.
• Keine Generation: Gatekeeper kann primär validieren. Es kann keine neuen Ressourcen (wie Default Network Policies) erstellen. Dafür brauchen Sie zusätzliche Tools oder Operatoren.
• Debugging-Schmerz: Wenn ein Deployment blockiert wird, ist die Fehlermeldung aus Rego oft kryptisch für den Endanwender.

Szenario B: Kyverno mit Managed Kubernetes von ayedo

Im ayedo App-Katalog ist Kyverno der Standard für Sicherheit.

• Lesbarkeit: Jeder im Team kann kubectl get clusterpolicy machen und versteht sofort, was erlaubt ist und was nicht. Sicherheit wird transparent.
• Best-Practice Library: Ayedo liefert Kyverno mit einem Set an bewährten Policies aus (Pod Security Standards), die sofort aktiv sind (z.B. “Disallow Privileged Containers”).
• Background Scanning: Kyverno prüft nicht nur neue Requests, sondern scannt auch bestehende Workloads. Es erstellt Reports (“Policy Reports”), die Ihnen zeigen, wo Sie Compliance Verstöße im Cluster haben, ohne sofort alles kaputt zu machen.

5. Technischer Vergleich der Betriebsmodelle

FAQ: Kyverno & Governance Strategy

Verlangsamt Kyverno meinen Cluster?

Kyverno arbeitet als Webhook. Ja, es fügt eine winzige Latenz (Millisekunden) beim Erstellen von Ressourcen hinzu. Auf die laufende Performance der Applikation hat es null Einfluss. Kyverno ist hochoptimiert und nutzt Caching, um API-Calls nicht auszubremsen.

Kann ich Kyverno einführen, ohne alles zu blockieren?

Ja, das ist der empfohlene Weg. Sie stellen Policies erst auf den Modus Audit. Kyverno lässt dann alles durch, erstellt aber Reports über Verstöße. So sehen Sie, welche Deployments fehlschlagen würden. Erst wenn Sie sicher sind, schalten Sie auf Enforce.

Ersetzt Kyverno die Pod Security Policies (PSP)?

Ja. Pod Security Policies wurden in Kubernetes v1.25 entfernt. Kyverno (oder der integrierte Pod Security Admission Controller) ist der offizielle Nachfolger. Kyverno ist dabei deutlich flexibler und granularer als die alten PSPs.

Was passiert bei einem Notfall (Break Glass)?

Man kann Kyverno so konfigurieren, dass bestimmte User (z.B. cluster-admin in einer Notfall-Gruppe) von den Policies ausgenommen sind. Zudem kann der Webhook so eingestellt werden (failurePolicy: Ignore), dass bei einem Totalausfall von Kyverno der Cluster trotzdem noch Deployments annimmt (Fail Open), um den Betrieb zu sichern.

Fazit

Sicherheit muss einfach sein, sonst wird sie umgangen. OPA Gatekeeper hat jahrelang gute Dienste geleistet, ist aber für viele Teams zu komplex (“Over-Engineering”). Kyverno bringt Governance zurück auf den Boden der Tatsachen – mit verständlichem YAML und mächtigen Features wie Mutation und Generation. Mit dem ayedo Managed Stack erhalten Sie eine Policy-Engine, die nicht nur “Nein” sagt, sondern Ihren Cluster aktiv sauber, sicher und standardkonform hält – automatisch und transparent.