Was ist Kubernetes Policy Management?

In modernen Kubernetes-Clustern reicht es nicht aus, RBAC (Role-Based Access Control) zu konfigurieren. Mit zunehmendem Cluster-Wachstum braucht man ein Policy Management System, das sicherstellt, dass Workloads definierten Standards entsprechen: Keine Pods ohne Resource Limits, keine privilegierten Container, nur Images aus vertrauenswürdigen Registries.

Für diesen Anwendungsfall haben sich zwei Tools als Standard etabliert: Kyverno und OPA/Gatekeeper (Open Policy Agent mit dem Kubernetes-Admission-Controller Gatekeeper). Beide setzen auf Kubernetes Admission Webhooks, um Ressourcen beim Erstellen oder Bearbeiten zu validieren, zu mutieren oder zu erzeugen – sie unterscheiden sich aber grundlegend in Ansatz, Komplexität und Anwendungsfall.

Kyverno: Kubernetes-native Policy Engine

Kyverno wurde speziell für Kubernetes entwickelt – der Name leitet sich vom griechischen Wort für "steuern" ab. Policies werden als Kubernetes Custom Resources (CRDs) in YAML definiert, ohne eine eigene Policy-Sprache lernen zu müssen.

Installation

# Installation via Helm
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

Beispiel: Pods müssen Resource Limits haben

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-pod-resources
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-resource-limits
      match:
        any:
        - resources:
            kinds:
            - Pod
      validate:
        message: "Resource limits sind Pflicht."
        pattern:
          spec:
            containers:
            - resources:
                limits:
                  memory: "?*"
                  cpu: "?*"

Kyverno unterstützt drei Policy-Typen:

  • Validate: Ressourcen ablehnen, die nicht den Regeln entsprechen
  • Mutate: Ressourcen automatisch anpassen (z.B. Labels hinzufügen)
  • Generate: Automatisch neue Ressourcen erstellen (z.B. NetworkPolicies)

Weitere nützliche Kyverno-Policies

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

OPA/Gatekeeper: Universelle Policy Engine

OPA (Open Policy Agent) ist ein allgemeines Policy Framework – nicht Kubernetes-spezifisch. Gatekeeper ist der Kubernetes-Admission-Controller, der OPA für Kubernetes nutzbar macht. Policies werden in Rego geschrieben, einer deklarativen Abfragesprache, die speziell für Policy-Entscheidungen entwickelt wurde.

Installation

# Gatekeeper via kubectl
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

# Oder via Helm
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper gatekeeper/gatekeeper -n gatekeeper-system --create-namespace

Beispiel: Resource Limits mit Rego

Mit Gatekeeper definiert man zuerst ein ConstraintTemplate (die Policy-Logik in Rego), dann eine Constraint (die konkrete Instanz):

# 1. ConstraintTemplate mit Rego-Logik
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: requireresourcelimits
spec:
  crd:
    spec:
      names:
        kind: RequireResourceLimits
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package requireresourcelimits
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.limits.cpu
          msg := sprintf("Container %v fehlen CPU-Limits", [container.name])
        }
---
# 2. Constraint (Instanz der Policy)
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: RequireResourceLimits
metadata:
  name: require-resource-limits
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

Die Trennung zwischen Template und Constraint ermöglicht wiederverwendbare Policies mit unterschiedlichen Parametern – ein mächtiges Konzept in größeren Organisationen.

Direktvergleich: Kyverno vs OPA/Gatekeeper

Kriterium Kyverno OPA/Gatekeeper
Policy-Sprache YAML/Kubernetes-nativ Rego (eigene Sprache)
Kubernetes-Focus Nur Kubernetes Universell (K8s, Terraform, CI/CD...)
Lernkurve Gering Hoch (Rego lernen)
Mutation ✅ Vollständig ⚠️ Experimentell
Generate ✅ Ja ❌ Nein
Audit Mode ✅ Ja ✅ Ja
Policy Library ✅ Kyverno Policies (400+) ✅ Gatekeeper Library
Resource-Verbrauch Mittel Höher
Community CNCF Incubating CNCF Graduated
Multi-Cluster ⚠️ Via Kyverno Policy Reporter ✅ OPA Enterprise

Kyverno Policy Reporter: Observability

Ein wichtiger Vorteil von Kyverno ist der Policy Reporter – ein Web-UI zur Visualisierung von Policy-Violations:

helm install policy-reporter policy-reporter/policy-reporter \
  -n policy-reporter --create-namespace \
  --set kyvernoPlugin.enabled=true \
  --set ui.enabled=true

Der Reporter lässt sich in Grafana integrieren und zeigt welche Workloads gegen welche Policies verstoßen.

Wann Kyverno, wann OPA/Gatekeeper?

Kyverno ist die bessere Wahl wenn:

  • Das Team bereits YAML kennt aber keine neue Sprache lernen möchte
  • Mutations und Generierung von Ressourcen benötigt werden
  • Ein reiner Kubernetes-Fokus vorliegt
  • Schnelle Time-to-Value wichtig ist
  • Kleinere bis mittlere Cluster verwaltet werden

OPA/Gatekeeper ist besser wenn:

  • Policies über mehrere Systeme hinweg gelten sollen (K8s + Terraform + CI/CD)
  • Komplexe, geschachtelte Policy-Logik benötigt wird
  • Das Team bereits Rego-Erfahrung hat
  • Enterprise-Features (Multi-Cluster, OPA Enterprise) benötigt werden
  • Eine große, diversifizierte Infrastruktur besteht

Best Practices: Rollout ohne Produktionsausfälle

Beide Tools unterstützen einen Dry-Run / Audit-Modus, der Violations meldet, ohne Ressourcen abzulehnen – ideal für den schrittweisen Rollout:

# Kyverno: Audit statt Enforce
spec:
  validationFailureAction: Audit  # Erst messen, dann enforzen

# Gatekeeper: Dryrun-Modus
spec:
  enforcementAction: dryrun

Empfohlene Reihenfolge:

  1. Audit-Modus aktivieren und bestehende Violations inventarisieren
  2. Violations in bestehenden Workloads beheben
  3. Enforce-Modus aktivieren
  4. Monitoring via Policy Reporter / OPA Dashboard einrichten

Fazit: Kyverno für die meisten Teams

Für Teams, die ausschließlich mit Kubernetes arbeiten und schnell loslegen wollen, ist Kyverno die empfohlene Wahl. Die YAML-basierte Policy-Definition senkt die Einstiegshürde erheblich, und Features wie automatische Mutation und Resource-Generierung übertreffen OPA/Gatekeeper in reinen Kubernetes-Szenarien.

OPA/Gatekeeper lohnt sich dann, wenn Policies über Kubernetes hinaus in anderen Systemen gelten sollen oder wenn bereits Rego-Expertise im Team vorhanden ist.

Beide Tools sind CNCF-Projekte mit aktiver Community und produktionsreif – wähle nach deinen konkreten Anforderungen.

Weiterführende Artikel

Verwandte Technologien im Techradar