Kubernetes Policies mit Kyverno: Sicherheit als Code

Wer Kubernetes im Unternehmen betreibt, stößt früher oder später auf die Frage: Wie verhindere ich, dass Teams Container ohne Resource Limits deployen, privilegierte Pods starten oder Images aus nicht-vertrauenswürdigen Registries ziehen? Manuelle Reviews skalieren nicht. Kyverno ist die Antwort — ein Kubernetes-nativer Policy-Controller, der Regeln direkt als Custom Resources definiert, ohne eine eigene Policy-Sprache wie Rego zu erlernen.

Was ist Kyverno?

Kyverno ist ein Admission Controller für Kubernetes, entwickelt unter dem Dach der CNCF. Er operiert als Validating und Mutating Webhook: Jede API-Anfrage an den Kubernetes-API-Server durchläuft Kyverno, bevor sie persistiert wird. Kyverno entscheidet dann anhand definierter ClusterPolicy- oderPolicy-Ressourcen, ob eine Anfrage abgelehnt, verändert oder durchgelassen wird.

Der entscheidende Unterschied zu OPA/Gatekeeper: Policies sind YAML. Wer Kubernetes-Manifeste schreiben kann, kann Kyverno-Policies schreiben. Kein Rego, keine separate DSL. Das reduziert die Einstiegshürde erheblich und macht Policies für das gesamte Team lesbar — nicht nur für Security-Spezialisten.

Die drei Kernfunktionen im Überblick

Kyverno deckt drei Anwendungsfälle ab, die in der Praxis eng zusammenhängen:

Validierung: Policies prüfen, ob ein Manifest bestimmten Anforderungen entspricht. Beispiel: Jeder Pod muss ein runAsNonRoot: true in seinem Security Context setzen. Verstößt ein Deployment dagegen, wird die Anfrage mit einer verständlichen Fehlermeldung abgelehnt.

Mutation: Kyverno kann Manifeste automatisch anpassen, bevor sie gespeichert werden. Fehlt ein imagePullPolicy: Always, wird es ergänzt. Fehlt ein Standard-Label, wird es hinzugefügt. Mutation ist besonders nützlich, um Legacy-Workloads schrittweise zu migrieren, ohne alle Teams gleichzeitig schulen zu müssen.

Generierung: Kyverno kann beim Anlegen eines Namespace automatisch begleitende Ressourcen erstellen — etwa eine vorausgefüllte NetworkPolicy, ein Standard-ResourceQuotaoder ein LimitRange. Damit wird Namespace-Isolation zum automatischen Default, nicht zur manuellen Aufgabe.

Eine Kyverno-Policy in der Praxis

Folgendes Beispiel zeigt eine Policy, die verhindert, dass Container mit Root-Rechten gestartet werden:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root-containers
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-runAsNonRoot
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Container müssen als Non-Root-User laufen (runAsNonRoot: true)."
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

Der validationFailureAction: Enforce-Modus blockiert die Anfrage sofort. Wer zunächst nur beobachten will, ohne Deployments zu unterbrechen, setzt Audit — Kyverno protokolliert Verstöße dann als PolicyReport-Ressourcen im Cluster, ohne sie zu blockieren.

PolicyReports: Sicherheitsstatus auf einen Blick

Kyverno erzeugt automatisch PolicyReport- und ClusterPolicyReport-Ressourcen. Diese folgen dem CNCF Policy Working Group Standard und können von Tools wie Policy Reporter oder Grafana visualisiert werden. Jeder Report enthält Status, betroffene Ressource und die verletzte Regel — ideal als Input für ein Security-Dashboard oder als Grundlage für Compliance-Nachweise.

Für Unternehmen mit ISO-27001- oder BSI-IT-Grundschutz-Anforderungen ist das ein handfester Vorteil: Der aktuelle Policy-Compliance-Stand des Clusters lässt sich jederzeit maschinell abfragen und dokumentieren, ohne manuellen Aufwand.

Kyverno und Pod Security Standards

Seit Kubernetes 1.25 sind PodSecurityPolicies (PSP) entfernt. Der offizielle Nachfolger sind die Pod Security Standards (PSS), die über den integrierten Pod Security Admission Controller enforced werden. Kyverno ergänzt PSS, wo der eingebaute Controller zu grobkörnig ist: PSS kennt nur drei Profile (Privileged, Baseline, Restricted) auf Namespace-Ebene. Kyverno erlaubt feingranulare Ausnahmen, kontextabhängige Regeln und Mutations, die PSS nicht bietet.

Ein typisches Setup kombiniert PSS für die Grundabsicherung auf Namespace-Ebene mit Kyverno-Policies für workload-spezifische Anforderungen: Image-Registry-Beschränkungen, Label-Pflichtfelder für Kostenverrechnung oder automatische Sidecar-Injection für bestimmte Namespaces.

Image Verification mit Kyverno

Kyverno unterstützt seit Version 1.7 die Verifikation von signierten Container-Images via Sigstore/Cosign. Eine Policy kann erzwingen, dass nur Images deployed werden dürfen, die mit einem bekannten Schlüssel signiert sind. Damit schließt man eine kritische Supply-Chain-Lücke: Selbst wenn ein Angreifer Zugriff auf eine Registry erlangt und ein manipuliertes Image hochlädt, verhindert die Signaturprüfung dessen Ausführung im Cluster.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-image-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "registry.example.com/*"
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYH...
                      -----END PUBLIC KEY-----

Kyverno in einer GitOps-Pipeline

Kyverno-Policies sind YAML-Ressourcen — sie lassen sich wie jede andere Kubernetes-Ressource über Git verwalten und via FluxCD oder ArgoCD deployen. Das bedeutet: Jede Policy-Änderung hat einen Git-Commit, einen Review-Prozess und ein Audit-Log. Sicherheitsregeln werden damit zu einem versionierten, nachvollziehbaren Teil der Cluster-Konfiguration.

Zusätzlich bietet Kyverno ein CLI-Tool, das Policies lokal oder in der CI-Pipeline gegen Manifeste testen kann — noch bevor ein Deployment den Cluster erreicht:

kyverno apply ./policies/ --resource ./manifests/deployment.yaml

Dieses frühe Feedback im Entwicklungsprozess verhindert, dass Policy-Verstöße erst beim Deploy sichtbar werden und dort für Frustration sorgen.

Wann Kyverno, wann OPA/Gatekeeper?

OPA/Gatekeeper ist mächtiger, wenn Policies komplexe externe Datenabrufe oder sehr dynamische Regellogik benötigen. Für die überwiegende Mehrheit der Unternehmensanforderungen — Ressourcenlimits, Image-Whitelists, Label-Pflichtfelder, Non-Root-Enforcement, NetworkPolicy-Generierung — ist Kyverno die pragmatischere Wahl: weniger Operationsaufwand, bessere Lesbarkeit, niedrigere Lernkurve.

Im Mittelstand, wo Plattform-Teams klein sind und breite Zuständigkeiten haben, hat sich Kyverno als de-facto-Standard für cluster-weite Policies etabliert. Die CNCF-Graduierung (2023) unterstreicht die Produktionsreife.

Typische Policy-Bibliothek für den Einstieg

Die Kyverno-Community pflegt eine umfangreiche Policy-Bibliothek mit sofort einsatzbereiten Regeln. Folgende Policies sind für produktive Cluster ein sinnvoller Ausgangspunkt:

• disallow-latest-tag — verhindert :latest-Images in der Produktion
• require-pod-requests-limits — erzwingt CPU/Memory Requests und Limits
• disallow-privilege-escalation — blockiert allowPrivilegeEscalation: true
• require-labels — erzwingt Standard-Labels (app, team, env) für Observability und Kostenverrechnung
• add-default-securitycontext — mutiert fehlende Security Context Felder auf sichere Defaults
• generate-networkpolicy — erstellt automatisch eine Default-Deny NetworkPolicy für neue Namespaces

Fazit

Kyverno ist kein optionales Add-on, sondern ein Basisbaustein für jeden produktionsreifen Kubernetes-Cluster. Policy-as-Code löst das fundamentale Problem, dass manuelle Sicherheitsreviews nicht mit der Deployment-Frequenz moderner Teams mithalten können. Mit Kyverno werden Sicherheitsregeln zu Code: versioniert, testbar, automatisch enforced.

Der Einstieg ist niedrigschwellig — ein Helm-Install, eine erste Policy im Audit-Modus, und ein PolicyReport zeigt binnen Minuten, wo der Cluster steht. Der Schritt von Audit zu Enforce erfordert dann Sorgfalt: bestehende Workloads müssen geprüft, Ausnahmen definiert und Teams informiert werden. Genau hier entscheidet sich, ob Kyverno ein Sicherheitsgewinn oder ein Betriebsproblem wird.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.