▸ saaro:~/blog ▊ Notizen & Artikel
← zurück

📷 "17° Server Room @ Work" by Leonardo Rizzi is licensed under CC BY-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/2.0/.

Policy-as-Code für Kubernetes 2026: Kyverno nach CNCF-Graduierung im Vergleich mit OPA Gatekeeper

27. Juli 2026 · 4 min · Martin Jochum #Kubernetes#Sicherheit#Policy-as-Code#Kyverno#OPA#Gatekeeper#CNCF#Cloud Native#DevOps

Policy-as-Code für Kubernetes 2026: Kyverno nach CNCF-Graduierung im Vergleich mit OPA Gatekeeper

Spätestens seit der NIS2-Richtlinie reicht es nicht mehr, Sicherheitsrichtlinien in einem Confluence-Dokument zu beschreiben. Prüfer fragen zunehmend nach dem Mechanismus, der Regeln durchsetzt. Genau hier setzt Policy-as-Code an: Statt Richtlinien in PDFs zu verwalten, werden sie als ausführbare Regeln direkt in den Kubernetes-Admission-Controller integriert. Zwei Projekte dominieren diesen Bereich: Kyverno und OPA Gatekeeper. Im März 2026 erreichte Kyverno als jüngstes den CNCF-Graduiertenstatus – ein guter Anlass, die beiden Ansätze zu vergleichen.

Warum Policy-as-Code? Der Compliance-Druck wächst

Wer drei oder mehr Kubernetes-Cluster auf verschiedenen Clouds (EKS, AKS, GKE) betreibt, kennt das Problem: Jeder Cloud-Anbieter hat leicht abweichende Defaults für Pod Security Standards. Mal ist runAsNonRoot anders voreingestellt, mal das Verhalten von Service-Account-Tokens. Einzeln betrachtet harmlos, entsteht über die Zeit ein Compliance-Profil, das niemand mehr vollständig dokumentiert hat.

Policy-as-Code verschiebt die Regeldefinition dorthin, wo Kubernetes ohnehin jede Ressource prüft: in den Admission Controller. Jeder kubectl apply-Aufruf durchläuft eine Pipeline von Authentifizierung über Mutating- bis Validating-Admission-Webhooks. Hier greifen Kyverno und OPA Gatekeeper ein und machen Compliance zum Teil des Build-Prozesses – nicht nur zum Thema des nächsten Quartalsmeetings.

Kyverno: Kubernetes-native Policies in YAML

Kyverno (griechisch für „regieren") wurde von Nirmata entwickelt und 2020 an die CNCF übergeben. Im März 2026 gab die CNCF auf der KubeCon Europe in Amsterdam die Graduierung bekannt – die höchste Reifstufe nach erfolgreichem Security-Audit und formeller Governance-Prüfung. Das Projekt wuchs von 574 auf über 9.000 GitHub-Sterne und wird unter anderem von Bloomberg, Coinbase, Deutsche Telekom, LinkedIn, Spotify, Vodafone und Wayfair in Produktion eingesetzt.

Der entscheidende Vorteil von Kyverno: Policies werden in nativem Kubernetes-YAML geschrieben. Wer eine Pod-Spezifikation formulieren kann, kann auch eine Kyverno-Policy schreiben. Die Lernkurve ist flach. Kyverno beherrscht drei Policy-Typen:

  • Validate: Prüft, ob eine Ressource den Regeln entspricht, und blockiert sie bei Verstößen.
  • Mutate: Ändert eingehende Ressourcen automatisch – zum Beispiel das Hinzufügen von Labels oder das Injizieren eines Sidecar-Containers.
  • Generate: Erzeugt neue Ressourcen bei bestimmten Ereignissen, etwa automatische NetworkPolicies bei neuen Namespaces.

Kyverno hat zudem die Common Expression Language (CEL) vollständig übernommen, die sich auch in Kubernetes selbst als Standard für Admisssion-Regeln etabliert.

OPA Gatekeeper: Der universelle Policy-Motor

OPA (Open Policy Agent) Gatekeeper ist der etablierte Gegenpart. Statt YAML verwendet es Rego, eine eigens entwickelte deklarative Abfragesprache. Rego ist extrem mächtig, aber die Lernkurve ist steil. Eine Policy in Rego zu debuggen, erfordert ein grundlegendes Umdenken: Man schreibt keine Prozeduren, sondern Assertionen.

Der große Vorteil von OPA: Es ist nicht auf Kubernetes beschränkt. Derselbe Rego-Code kann Terraform-Pläne, CI/CD-Pipelines, API-Gateway-Traffic und IAM-Richtlinien prüfen. Wer also in einem großen Unternehmen eine einheitliche Policy-Sprache über den gesamten Stack braucht, ist mit OPA gut beraten.

Kyverno vs. OPA Gatekeeper: Die Entscheidungsmatrix

Kriterium Kyverno OPA Gatekeeper
Sprache Kubernetes-YAML Rego (eigene DSL)
Lernkurve Niedrig (YAML-Kenntnisse reichen) Steil
Einsatzbereich Nur Kubernetes Universell (K8s, CI/CD, Cloud, Terraform)
Mutation Nativ, einfache YAML-Patches Komplex, erfordert fortgeschrittenes Rego
CNCF-Status Graduiert (März 2026) Graduiert
IDEAL FÜR Pragmatische K8s-Plattformteams Große Unternehmen mit einheitlicher Policy

Was plattformteams 2026 wirklich entscheiden sollten

Drei Fragen helfen bei der Wahl:

1. Gibt es Policy-Bedarf außerhalb von Kubernetes? Wenn bereits Terraform-Pläne, IAM-Richtlinien oder CI-Pipelines geprüft werden müssen, ist OPA die natürliche Wahl. Beschränkt sich die Compliance-Welt auf Kubernetes, bringt Kyverno weniger Komplexität.

2. Wie groß und erfahren ist das Team? In einem Team, in dem nur eine Person sicher Rego schreibt, wird die Policy-Pflege zum Flaschenhals, sobald diese Person im Urlaub ist oder das Team verlässt. Kyverno-YAML überlebt personelle Wechsel deutlich besser.

3. Welche Sicherheitstools sind bereits im Einsatz? Wenn Falco, Trivy oder Pod Security Standards etabliert sind, lassen sich Berichtsanforderungen mit Kyvernos nativen PolicyReport-CRDs oft out of the box erfüllen.

Fazit

Policy-as-Code ist 2026 kein Nice-to-have mehr, sondern eine betriebliche Notwendigkeit – nicht zuletzt wegen regulatorischer Vorgaben wie NIS2. Kyvernos CNCF-Graduierung im März 2026 unterstreicht, dass der YAML-basierte Ansatz in der Praxis angekommen ist. Für die Mehrheit der Plattformteams, die Kubernetes absichern und standardisieren wollen, ist Kyverno der pragmatischere Einstieg. OPA Gatekeeper bleibt die erste Wahl, wenn eine einheitliche Policy-Sprache über den gesamten Technologie-Stack hinweg benötigt wird. Beide Projekte sind CNCF-graduiert und produktionserprobt – die Qual der Wahl ist letztlich eine Frage der Team-Struktur und des Einsatzbereichs.

Quellen