Kubernetes Policy Automation: Kyverno und OPA Gatekeeper im Praxisvergleich

TL;DR

• Policy Automation erzwingt Sicherheits- und Betriebsregeln automatisch ueber Kubernetes Admission Controller -- manuelle Reviews werden ueberfluessig.
• Kyverno nutzt native YAML-Syntax und ist schneller produktiv einsetzbar. OPA Gatekeeper bietet mit Rego mehr Flexibilitaet fuer komplexe Logik.
• Starte im Audit-Modus, pruefe die Violations, dann schalte schrittweise auf Enforce um.
• Beide Tools lassen sich in CI/CD-Pipelines integrieren (Shift Left), sodass Fehlkonfigurationen nie im Cluster landen.
• Ein realistischer Rollout dauert 4-6 Wochen bis zu ersten enforced Policies in Produktion.

Warum Policy Automation wichtig ist

Kubernetes gibt Teams viel Freiheit. Jeder Namespace kann eigene Deployments, Services und Ingresses anlegen. Ohne Leitplanken fuehrt das zu Problemen: Container laufen als Root, Images werden ohne Tag gepinnt, Resource Limits fehlen, und Secrets landen unverschluesselt in ConfigMaps.

Policy Automation loest dieses Problem auf der Ebene des API-Servers. Ein Admission Controller fängt jede Anfrage ab, bevor sie persistiert wird. Wenn ein Deployment gegen eine Regel verstoesst, wird es abgelehnt -- mit einer klaren Fehlermeldung.

Das Ergebnis: Entwickler bekommen sofort Feedback, Ops-Teams muessen nicht manuell pruefen, und Compliance-Anforderungen (DSGVO, BSI C5) werden automatisch durchgesetzt.

Kyverno vs. OPA Gatekeeper: Architekturvergleich

Beide Tools loesen das gleiche Problem, aber auf unterschiedliche Weise.

Wann Kyverno waehlen

Kyverno ist die bessere Wahl, wenn das Team hauptsaechlich aus Kubernetes-Admins besteht, die keine neue Sprache lernen wollen. Die Mutation- und Generation-Features sind ein grosser Vorteil: Du kannst z.B. automatisch Labels setzen oder NetworkPolicies fuer jeden neuen Namespace erzeugen.

Wann OPA Gatekeeper waehlen

OPA Gatekeeper macht Sinn, wenn du bereits OPA in anderen Bereichen nutzt (z.B. Terraform, Envoy) oder wenn deine Policies komplexe bedingte Logik benoetigen, die in YAML schwer abzubilden ist. Rego ist maechtig, aber erfordert Einarbeitung.

Praxis: Drei Policies, die jeder Cluster braucht

1. Keine Container als Root

Das ist die wichtigste Policy. Container, die als Root laufen, koennen bei einem Container-Escape den Host kompromittieren.

Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root-user
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-runAsNonRoot
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        resources:
          namespaces:
            - kube-system
      validate:
        message: "Container muessen als non-root User laufen. Setze securityContext.runAsNonRoot: true"
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

OPA Gatekeeper (ConstraintTemplate + Constraint):

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirerunasnonroot
spec:
  crd:
    spec:
      names:
        kind: K8sRequireRunAsNonRoot
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirerunasnonroot
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.runAsNonRoot
          msg := sprintf("Container '%v' muss runAsNonRoot: true setzen", [container.name])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequireRunAsNonRoot
metadata:
  name: must-run-as-nonroot
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - kube-system

2. Image Tags pinnen -- kein "latest"

Das latest-Tag ist nicht deterministisch. Zwei Deployments mit dem gleichen Manifest koennen unterschiedliche Images ausfuehren.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Image-Tag 'latest' ist nicht erlaubt. Nutze einen spezifischen Tag oder Digest."
        pattern:
          spec:
            containers:
              - image: "!*:latest"

3. Resource Requests und Limits erzwingen

Ohne Resource Limits kann ein einzelner Pod den gesamten Node destabilisieren. Diese Policy stellt sicher, dass jeder Container CPU- und Memory-Limits definiert.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Audit
  rules:
    - name: check-resource-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Jeder Container braucht CPU- und Memory-Limits."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"
                  requests:
                    memory: "?*"
                    cpu: "?*"

Shift Left: Policies in der CI/CD-Pipeline

Policies nur im Cluster zu erzwingen reicht nicht. Entwickler erfahren dann erst beim kubectl apply, dass ihr Manifest nicht konform ist. Besser: Die Pruefung in die CI/CD-Pipeline integrieren.

Kyverno CLI in GitHub Actions

# In deiner CI-Pipeline
# 1. Kyverno CLI installieren
curl -LO https://github.com/kyverno/kyverno/releases/download/v1.12.0/kyverno-cli_v1.12.0_linux_x86_64.tar.gz
tar -xzf kyverno-cli_v1.12.0_linux_x86_64.tar.gz

# 2. Policies gegen Manifeste pruefen
./kyverno apply ./policies/ --resource ./manifests/deployment.yaml

# 3. Exit Code pruefen -- bei Violations schlaegt die Pipeline fehl
if [ $? -ne 0 ]; then
  echo "Policy-Violations gefunden. Deployment blockiert."
  exit 1
fi

Conftest fuer OPA

# conftest nutzt OPA/Rego-Policies direkt
conftest test ./manifests/deployment.yaml --policy ./policies/

# Beispiel-Output:
# FAIL - deployment.yaml - Container 'web' muss runAsNonRoot: true setzen
# 2 tests, 1 passed, 1 warning, 1 failure

Der Vorteil von Shift Left: Entwickler bekommen Feedback in Sekunden, nicht erst nach dem Merge. Das spart Zeit und verhindert, dass Non-Compliance-Issues sich ansammeln.

Rollout-Strategie: Vom Audit zum Enforcement

Ein harter Cutover ("ab morgen blockieren wir alles") ist ein Rezept fuer Aerger. Stattdessen empfiehlt sich ein gestufter Rollout.

Phase 1: Audit (Woche 1-2)

Installiere die Policy Engine und setze alle Policies auf Audit. In diesem Modus werden Violations gemeldet, aber nichts blockiert. Nutze diese Phase, um zu verstehen, wie viele bestehende Ressourcen gegen die Policies verstossen.

# Kyverno: Policy Reports anzeigen
kubectl get policyreport -A

# Gatekeeper: Audit-Violations anzeigen
kubectl get constraints -o json | jq '.items[].status.violations'

Phase 2: Enforce fuer neue Ressourcen (Woche 3-4)

Schalte die wichtigsten Policies (Root-Verbot, Image-Tags) auf Enforce. Bestehende Ressourcen bleiben unangetastet, aber neue Deployments muessen konform sein. Kommuniziere die Aenderung an alle Teams.

Phase 3: Bestehende Violations bereinigen (Woche 5-8)

Arbeite die bestehenden Violations ab. Kyverno Policy Reports und Gatekeeper Audit Results liefern eine priorisierte Liste. Beginne mit den kritischsten Namespaces (Production) und arbeite dich zu weniger kritischen vor.

Phase 4: Kontinuierliche Erweiterung

Fuege neue Policies hinzu, wenn neue Anforderungen entstehen. Halte die Policies in einem Git-Repository (Policy as Code) und nutze Pull Requests fuer Reviews. So bleibt die Policy-Landschaft nachvollziehbar und versioniert.

DSGVO-relevante Policies

Fuer Unternehmen, die personenbezogene Daten in Kubernetes verarbeiten, sind einige Policies besonders relevant:

• Namespace-Isolation: NetworkPolicies, die den Zugriff zwischen Namespaces einschraenken. So koennen Entwicklungs-Workloads nicht auf Produktionsdatenbanken zugreifen.
• Encryption in Transit: Policies, die sicherstellen, dass Services nur ueber TLS kommunizieren (z.B. durch Erzwingung von Istio mTLS oder Ingress-TLS-Konfiguration).
• Image-Registry-Whitelisting: Nur Images aus vertrauenswuerdigen, internen Registries erlauben. Das verhindert, dass unkontrollierte Drittanbieter-Images in Produktion landen.
• Audit-Logging: Sicherstellen, dass der Kubernetes API-Server Audit-Logs schreibt und diese an ein zentrales Log-System weitergeleitet werden.

Diese Policies helfen, die technischen Anforderungen der DSGVO (Artikel 32: Sicherheit der Verarbeitung) automatisiert durchzusetzen.

Monitoring der Policy-Compliance

Policies ohne Monitoring sind blind. Beide Tools liefern Metriken, die sich in Prometheus/Grafana integrieren lassen.

Ein Grafana-Dashboard, das diese Metriken visualisiert, gibt dem Team jederzeit einen Ueberblick ueber den Compliance-Status. Details zum Aufbau eines Monitoring-Stacks findest du unter Kubernetes Observability Stack.

Haeufige Fehler und wie man sie vermeidet

Zu viele Policies auf einmal einfuehren. Starte mit 3-5 kritischen Policies. Wenn 50 Policies gleichzeitig enforced werden, ist Frustration bei Entwicklern vorprogrammiert.

Keine Exceptions definieren. Manche Workloads (z.B. kube-system, Monitoring-Agents) brauchen erhoehte Rechte. Definiere klare Ausnahmen ueber Namespace-Excludes oder spezifische Labels.

Policies nicht testen. Behandle Policies wie Code: Schreibe Tests, nutze CI/CD, und pruefe Policies in einer Staging-Umgebung, bevor sie in Produktion gehen.

Fehlende Kommunikation. Policies ohne Erklaerung erzeugen Widerstand. Dokumentiere jede Policy mit einer klaren Begruendung und biete einen Ansprechpartner fuer Fragen.

Weiterführende Themen

• Kubernetes RBAC im Enterprise-Einsatz -- Policies und RBAC ergaenzen sich: RBAC kontrolliert Wer, Policies kontrollieren Was.
• Kubernetes Network Policies (Advanced) -- Netzwerk-Isolation als Ergaenzung zu Admission Policies.
• Kubernetes Secrets Management mit Vault -- Secrets-Handling als haeufiger Policy-Anwendungsfall.
• Kubernetes Compliance Automation -- Der uebergeordnete Rahmen fuer Policy Automation.

Fazit

Policy Automation ist kein Nice-to-have, sondern eine Grundvoraussetzung fuer den sicheren Betrieb von Kubernetes. Ob Kyverno oder OPA Gatekeeper -- beide Tools sind ausgereift und produktionsbereit. Die Wahl haengt von der Teamstruktur und den vorhandenen Skills ab.

Der wichtigste Schritt ist der erste: Eine Policy Engine installieren, drei grundlegende Policies im Audit-Modus aktivieren, und die Ergebnisse analysieren. Von dort aus laesst sich das System schrittweise erweitern.

Wenn du Unterstuetzung bei der Planung oder Implementierung brauchst, melde dich fuer ein Gespraech unter /kontakt.