Kyverno: Policy Enforcement in Kubernetes ohne Kompromisse

Kubernetes gibt Entwicklerteams viel Freiheit — zu viel, wenn es keine durchgesetzten Standards gibt. Ohne Policy Enforcement landen Container mit privileged: true in der Produktion, Images kommen aus nicht verifizierten Registries, und Resource Limits fehlen cluster-weit. Kyverno ist das Werkzeug, das dieses Problem strukturell löst — ohne dass Entwickler eine neue Sprache lernen müssen.

Was Kyverno ist — und was nicht

Kyverno ist ein Kubernetes-nativer Policy Controller. Policies sind selbst Kubernetes-Ressourcen (Custom Resources), geschrieben in YAML. Es gibt keine eigene Policy-Sprache wie bei Open Policy Agent (OPA) mit Rego. Das senkt die Einstiegshürde erheblich und macht Policies für Plattformteams wartbar, die keine spezialisierten Policy-Entwickler haben.

Kyverno operiert als Admission Webhook. Jede Ressource, die der Kubernetes API-Server empfängt, durchläuft Kyverno — bevor sie im etcd landet. Kyverno kann:

• Validieren: Ressourcen ablehnen, die gegen Policies verstoßen.
• Mutieren: Ressourcen automatisch korrigieren (z. B. Labels hinzufügen, Defaults setzen).
• Generieren: Automatisch neue Ressourcen erstellen (z. B. NetworkPolicies bei neuen Namespaces).
• Verifizieren: Image-Signaturen prüfen (Cosign/Notary-Integration).

ClusterPolicy vs. Policy

Kyverno unterscheidet zwischen zwei Geltungsbereichen:

• ClusterPolicy: Gilt cluster-weit, über alle Namespaces. Geeignet für Baseline-Regeln, die ausnahmslos gelten sollen — z. B. das Verbot vonhostNetwork: true oder das Erzwingen von Resource Limits.
• Policy: Gilt nur im Namespace, in dem sie deployed ist. Sinnvoll für team- oder applikationsspezifische Regeln.

In der Praxis beginnen die meisten Teams mit wenigen ClusterPolicies im Audit-Modus (Verstöße werden geloggt, aber nicht geblockt) und schalten schrittweise aufEnforce um, wenn die Baseline stabil ist.

Drei Policies, die jeder Cluster braucht

1. Require Resource Limits

Ohne Memory Limits kann ein einzelner Pod einen Node destabilisieren. Diese Policy lehnt jeden Pod ab, der keine CPU- und Memory-Limits definiert:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-container-limits
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Resource limits für CPU und Memory sind Pflicht."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

2. Disallow Privileged Containers

Privilegierte Container haben nahezu uneingeschränkten Zugriff auf den Host-Kernel. In Produktionsumgebungen gibt es keinen legitimen Anwendungsfall außerhalb spezialisierter Systemkomponenten — und die werden explizit ausgenommen:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-privileged
      match:
        any:
          - resources:
              kinds: [Pod]
      exclude:
        any:
          - resources:
              namespaces: [kube-system, monitoring]
      validate:
        message: "Privilegierte Container sind nicht erlaubt."
        pattern:
          spec:
            containers:
              - =(securityContext):
                  =(privileged): "false"

3. Require Approved Image Registries

Images aus öffentlichen Registries ohne Vetting sind ein erhebliches Supply-Chain-Risiko. Diese Policy stellt sicher, dass nur Images aus der eigenen Harbor-Instanz oder einem definierten Set an Registries verwendet werden:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-registry
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Nur Images aus registry.intern.example.com sind erlaubt."
        pattern:
          spec:
            containers:
              - image: "registry.intern.example.com/*"

Image Verification mit Cosign

Ab Kyverno 1.7+ ist Image Verification direkt integriert. Wer Images mit Cosign signiert, kann erzwingen, dass nur verifizierte Images deployed werden:

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.intern.example.com/*"
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----

In Verbindung mit einer CI/CD-Pipeline, die Images nach dem Build automatisch signiert, entsteht damit eine durchgehende Supply-Chain-Integrität vom Build bis zum Deployment.

Policy Reports auswerten

Kyverno erstellt nach jeder Audit-Prüfung PolicyReport- undClusterPolicyReport-Ressourcen. Diese können direkt mit kubectlausgewertet werden:

kubectl get policyreport -A
kubectl get clusterpolicyreport

# Detaillierter Report für einen Namespace:
kubectl get policyreport -n production -o yaml

Für eine kontinuierliche Übersicht empfiehlt sich die Integration in Grafana via Policy Reporter — ein Open-Source-Dashboard, das PolicyReports visualisiert und Alerting über Prometheus ermöglicht.

Kyverno vs. OPA Gatekeeper

Die häufigste Frage in Evaluierungen: Kyverno oder OPA Gatekeeper? Beide lösen dasselbe Problem, mit unterschiedlichen Trade-offs:

• OPA Gatekeeper verwendet Rego — eine funktionale Sprache, die mächtig, aber anspruchsvoll ist. Für Teams mit starken Golang- oder funktionalen Programmierkenntnissen geeignet. Policies sind flexibler, aber schwerer wartbar.
• Kyverno verwendet YAML-Patterns. Für Plattformteams ohne Policy-Spezialisten ist das der realistischere Ansatz. Die Einstiegshürde ist deutlich niedriger, und die CNCF-Graduation (2023) bestätigt die Produktionsreife.

In der Beratungspraxis wählen Teams im DACH-Mittelstand fast immer Kyverno, weil der Betrieb ohne spezialisierte Rego-Kenntnisse funktioniert.

Rollout-Strategie für bestehende Cluster

Ein Kyverno-Rollout in einem bestehenden Produktionscluster folgt typischerweise diesem Muster:

1. Woche 1–2: Kyverno installieren (Helm), alle Policies imAudit-Modus deployen. PolicyReports auswerten.
2. Woche 3: Bestehende Violations mit den verantwortlichen Teams beheben. Hotfix-Workloads dokumentieren und ggf. temporär exkludieren.
3. Woche 4+: Policies schrittweise auf Enforce umstellen, beginnend mit den kritischsten (privileged containers, image registries).

Fazit

Kyverno ist heute der pragmatischste Weg, um in Kubernetes-Clustern durchsetzbare Sicherheitsstandards zu etablieren. Die YAML-native Policy-Sprache macht es für Plattformteams ohne Policy-Spezialisten operierbar, die Integration in bestehende GitOps-Workflows ist direkt. Der entscheidende Schritt ist nicht die Toolwahl — sondern der strukturierte Rollout, der bestehende Workloads nicht destabilisiert.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.