Kyverno: Policy-as-Code für Kubernetes ohne Rego (2026)

Pexon Consulting | 8 Min. Lesezeit | 16.08.2026

TL;DR

Kyverno ist eine Kubernetes-native Policy-Engine, die Regeln in YAML statt in einer Extra-Sprache formuliert. Sie validiert, mutiert und generiert Ressourcen über den Admission Controller. Seit März 2026 ist Kyverno ein graduiertes CNCF-Projekt, auf Augenhöhe mit Kubernetes und Prometheus. Wir bei Pexon Consulting setzen es für Security- und Compliance-Guardrails in regulierten Cluster-Umgebungen ein.

Was Kyverno ist und welches Problem es löst

Kyverno ist ein Admission Controller für Kubernetes, der Richtlinien direkt beim Deployen von Ressourcen durchsetzt. Die kurze Definition: Policy-as-Code für Kubernetes, geschrieben in YAML. Damit lassen sich Regeln erzwingen wie „kein Container läuft als root“, „jedes Deployment braucht ein Kostenstellen-Label“ oder „Images nur aus der eigenen Registry“.

Das eigentliche Problem, das Kyverno löst, ist Governance ohne Gatekeeping-Meetings. In einem Cluster mit 20 Teams kann niemand jedes Manifest per Review prüfen. Ohne automatisch durchgesetzte Policies landen privilegierte Container, fehlende Resource-Limits und ungeprüfte Images in der Produktion, bis der erste Vorfall kommt. Kyverno verschiebt diese Kontrolle nach links: Die Regel greift, bevor die Ressource überhaupt im Cluster landet.

Kyverno wurde am 16. März 2026 von der CNCF auf den Graduated-Status gehoben, die höchste Reifestufe. Das Projekt steht bei über 9.000 GitHub-Stars (Abruf 16. August 2026), Adopter sind unter anderem LinkedIn, Bloomberg und die Deutsche Telekom. Die aktuelle stabile Version ist Kyverno v1.18.2 vom 10. Juli 2026, die v1.19.0 steht als Release Candidate bereit.

Wie eine Kyverno-Policy aussieht

Der größte praktische Unterschied zu anderen Engines: Eine Kyverno-Policy ist eine normale Kubernetes-Ressource. Wer YAML-Manifeste schreibt, kann Kyverno-Policies schreiben, ohne eine neue Sprache zu lernen. Hier eine Regel, die privilegierte Container blockiert:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce   # Verstoss wird hart abgelehnt
  rules:
    - name: privileged-check
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Privilegierte Container sind nicht erlaubt."
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false"

Kyverno kann mehr als nur ablehnen. Es kennt vier Aktionstypen: validieren (Verstoß blocken), mutieren (fehlende Felder automatisch ergänzen, etwa Default-Labels oder Security-Contexts), generieren (Ressourcen automatisch anlegen, etwa NetworkPolicies pro neuem Namespace) und aufräumen (veraltete Ressourcen entfernen). Diese Mutation-Fähigkeit ist der Punkt, an dem Kyverno in der Praxis am meisten Arbeit spart: Statt Deployments abzulehnen, korrigiert es sie still im Hintergrund.

Kyverno vs OPA Gatekeeper: die eigentliche Entscheidung

Die Auswahlfrage ist selten „Kyverno ja oder nein“, sondern „Kyverno oder OPA Gatekeeper“. Unsere klare Empfehlung für die meisten Kubernetes-Teams: Kyverno, wegen der niedrigeren Einstiegshürde. OPA Gatekeeper nutzt Rego, eine mächtige, aber eigenständige Policy-Sprache mit spürbarer Lernkurve. Kyverno bleibt in YAML.

Wann ist OPA Gatekeeper trotzdem die bessere Wahl? Wenn im Unternehmen bereits eine OPA-Landschaft existiert (etwa für API-Autorisierung oder Terraform-Policies) und die Policy-Logik über Kubernetes hinausgeht. Rego ist ausdrucksstärker als Kyvernos YAML-Muster, wenn wirklich komplexe, verschachtelte Bedingungen nötig sind. Für 80 Prozent der Kubernetes-Guardrails (Security-Baselines, Labels, Registry-Zwang, Resource-Limits) ist das aber Overkill, und die Rego-Lernkurve kostet mehr, als sie bringt.

Ein häufiger Fehler beim Rollout: Teams schalten Policies sofort auf Enforce und legen damit am ersten Tag laufende Workloads lahm. Der bessere Weg ist zweistufig. Erst Audit-Modus, um zu sehen, was alles verletzt würde, ohne zu blocken. Dann pro Policy schrittweise auf Enforce, wenn die Altlasten bereinigt sind. Wer diese Reihenfolge überspringt, verbrennt das Vertrauen der Dev-Teams in das Policy-System.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Kyverno und OPA Gatekeeper?

Kyverno schreibt Policies in YAML, OPA Gatekeeper in der Sprache Rego. Kyverno ist Kubernetes-spezifisch und schneller einzuführen, OPA ist universeller und mächtiger bei komplexer Logik, aber mit steilerer Lernkurve. Für reine Kubernetes-Guardrails ist Kyverno meist die pragmatischere Wahl.

Braucht Kyverno eine eigene Sprache wie Rego?

Nein. Genau das ist der Kernvorteil. Kyverno-Policies sind normale Kubernetes-Manifeste in YAML. Teams, die bereits mit Kubernetes arbeiten, können ohne neue Sprache loslegen.

Ist Kyverno produktionsreif?

Ja. Kyverno ist seit März 2026 ein graduiertes CNCF-Projekt, die höchste Reifestufe, gemeinsam mit Kubernetes und Prometheus. Große Organisationen wie LinkedIn und die Deutsche Telekom setzen es produktiv ein.

Was kostet Kyverno?

Kyverno selbst ist Open Source und kostenlos. Kosten entstehen im Betrieb: Policy-Design, Rollout ohne Ausfall, Ausnahme-Management und laufende Pflege. Für den Enterprise-Support gibt es kommerzielle Angebote von Nirmata, dem Hauptsponsor des Projekts.

Kann Kyverno für Compliance-Nachweise genutzt werden?

Ja. Kyverno erzeugt PolicyReports, die dokumentieren, welche Ressourcen gegen welche Regeln verstoßen. Das ist für Audits nach BSI, ISO 27001 oder DORA nutzbar, weil sich damit belegen lässt, dass Security-Baselines technisch durchgesetzt und nicht nur dokumentiert sind.

Nächster Schritt

Du willst Kyverno nicht nur testen, sondern als durchgesetzte Security-Baseline über deine Cluster ausrollen, ohne die Produktion zu blockieren? Wir planen den Audit-zu-Enforce-Rollout mit dir und definieren die Policy-Baseline für deine Compliance-Anforderungen.

Verwandte Themen

Die offiziellen Policy-Beispiele stehen in der Kyverno Policy Library.