TL;DR

Kyverno ist eine Kubernetes-native Policy Engine, die Policies als YAML-Ressourcen definiert — ohne Rego oder andere Programmiersprachen. Du kannst damit Ressourcen validieren, mutieren und automatisch generieren. Die Einstiegshürde ist deutlich niedriger als bei OPA Gatekeeper, und für die meisten Governance-Anforderungen reicht Kyverno vollständig aus.

Kyverno: Policy Engine für Kubernetes

Wer Kubernetes im Team betreibt, kennt das Problem: Deployments ohne Labels, Container mit Root-Rechten, fehlende Resource Limits. Manuelle Reviews skalieren nicht. Policy Engines lösen das — und Kyverno macht es ohne eigene Sprache.

Kyverno installieren

Die Installation läuft über Helm. Kyverno besteht aus einem Admission Controller, der sich als Webhook in den API-Server einklinkt.

# Helm-Repo hinzufügen
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

# Kyverno installieren
helm install kyverno kyverno/kyverno \
  --namespace kyverno \
  --create-namespace \
  --set replicaCount=3

Prüfe, ob die Pods laufen:

kubectl get pods -n kyverno

ClusterPolicy: Validierung

Die häufigste Anwendung ist Validierung — Ressourcen ablehnen, die bestimmte Kriterien nicht erfüllen. Eine ClusterPolicy gilt cluster-weit, eine Policy nur im jeweiligen Namespace.

Labels erzwingen

Diese Policy lehnt jedes Deployment ab, das kein Label app.kubernetes.io/name trägt:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-app-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-app-label
      match:
        any:
          - resources:
              kinds:
                - Deployment
      validate:
        message: "Label 'app.kubernetes.io/name' ist erforderlich."
        pattern:
          metadata:
            labels:
              app.kubernetes.io/name: "?*"

Der Wert ?* bedeutet: mindestens ein Zeichen, also nicht leer. validationFailureAction: Enforce blockiert die Ressource aktiv. Mit Audit wird nur geloggt.

Resource Limits erzwingen

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "CPU und Memory Limits müssen gesetzt sein."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

Mutation: Ressourcen automatisch anpassen

Mutation verändert Ressourcen beim Erstellen. Das ist nützlich für Defaults oder Sidecar-Injection.

Default-Labels injizieren

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-labels
spec:
  rules:
    - name: add-team-label
      match:
        any:
          - resources:
              kinds:
                - Deployment
                - StatefulSet
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              managed-by: kyverno
              environment: "{{request.namespace}}"

Die Variable {{request.namespace}} wird zur Laufzeit aufgelöst. Kyverno unterstützt diverse Kontext-Variablen wie request.userInfo, request.object und API-Lookups.

Sidecar-Container injizieren

Ein typischer Use Case: Logging-Sidecar automatisch in alle Pods eines Namespaces einfügen.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: inject-logging-sidecar
spec:
  rules:
    - name: inject-fluentbit
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - production
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - name: fluentbit-sidecar
                image: fluent/fluent-bit:3.2
                resources:
                  limits:
                    cpu: 100m
                    memory: 128Mi

Generation: Ressourcen automatisch erstellen

Generate-Rules erstellen neue Ressourcen, wenn bestimmte Trigger eintreten. Beispiel: Bei jedem neuen Namespace automatisch eine NetworkPolicy anlegen.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-default-netpol
spec:
  rules:
    - name: default-deny-ingress
      match:
        any:
          - resources:
              kinds:
                - Namespace
      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny-ingress
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            podSelector: {}
            policyTypes:
              - Ingress

Jeder neue Namespace bekommt damit automatisch eine Default-Deny-NetworkPolicy. Das ist deutlich zuverlässiger als darauf zu hoffen, dass Teams sie manuell anlegen.

Kyverno vs. OPA Gatekeeper

Beide Tools lösen dasselbe Problem, aber auf grundlegend verschiedene Weise.

Wann OPA Gatekeeper? Wenn du bereits Rego-Erfahrung hast, komplexe Cross-Resource-Logik brauchst oder OPA auch außerhalb von Kubernetes einsetzt (z.B. API-Gateway-Policies).

Wann Kyverno? Wenn dein Team YAML kennt, aber keine neue Sprache lernen will. Wenn du Mutation und Generation brauchst. Für die meisten Kubernetes-Governance-Anforderungen ist Kyverno die pragmatischere Wahl.

Policies testen

Kyverno bringt ein CLI-Tool mit, um Policies lokal zu testen — ohne laufenden Cluster:

# Kyverno CLI installieren
kubectl krew install kyverno

# Policy gegen eine Ressource testen
kubectl kyverno apply require-app-label.yaml \
  --resource deployment.yaml

Die Ausgabe zeigt, ob die Ressource die Policy besteht oder abgelehnt wird. Das lässt sich in CI/CD-Pipelines integrieren, sodass fehlerhafte Manifeste gar nicht erst committet werden.

FAQ

Kann Kyverno bestehende Ressourcen prüfen?

Ja. Mit validationFailureAction: Audit und dem Kyverno Policy Reporter siehst du, welche bestehenden Ressourcen gegen Policies verstoßen. Background-Scans laufen automatisch im Hintergrund.

Was passiert, wenn Kyverno ausfällt?

Mit der Einstellung failurePolicy: Ignore im Webhook werden Ressourcen bei einem Kyverno-Ausfall durchgelassen. Bei Fail werden alle Requests blockiert. Für Production empfiehlt sich Ignore mit drei Replicas.

Wie viele Policies sind sinnvoll?

Starte mit 5-10 grundlegenden Policies (Labels, Limits, Security Context) und erweitere schrittweise. Die Kyverno Policy Library auf GitHub enthält über 200 fertige Policies als Vorlage.

Beeinflusst Kyverno die API-Server-Latenz?

Minimal. Kyverno verarbeitet Admission-Requests typischerweise in unter 10ms. Bei sehr vielen gleichzeitigen Requests hilft die Skalierung auf mehrere Replicas.

Nächster Schritt: Beginne mit einer Audit-Policy für Labels und beobachte die Policy Reports. Sobald alle Verstöße behoben sind, schalte auf Enforce um. Die Kyverno Policy Library bietet über 200 fertige Policies für gängige Anforderungen.