7 Min. Lesezeit

Wer ein Multi-Cloud-Setup mit drei oder mehr Kubernetes-Clustern fährt und Governance noch in Confluence-Seiten dokumentiert, hat 2026 ein operatives Risiko, das die NIS2-Auditoren spätestens bei der ersten Stichprobe finden. Policy-as-Code mit OPA Gatekeeper oder Kyverno schiebt die Regel-Durchsetzung in den Admission-Path. Was vorher als PDF im Compliance-Ordner lebte, wird damit zu YAML, das jede Pod-Definition prüft, bevor sie überhaupt gescheduled wird.

Das Wichtigste in Kürze

• Policy-as-Code verschiebt Compliance aus dem Audit-Termin in die Build-Pipeline: OPA Gatekeeper und Kyverno hängen sich als Admission-Webhook in jeden Kubernetes-API-Call und blocken Pods, die gegen Konfigurations-Vorgaben verstoßen, bevor sie scheduled werden.
• Multi-Cloud heißt Multi-Policy-Engine oder einheitliche Plattform-Schicht: EKS, AKS und GKE bringen je eigene Default-Regeln mit. Wer Governance konsistent über alle drei Cluster-Sets durchsetzen will, braucht entweder einen zentralen Policy-Hub oder GitOps-Pipelines, die identische Regeln auf jeden Cluster pushen.
• Der Unterschied zwischen OPA Gatekeeper und Kyverno ist operativ, nicht ideologisch: Gatekeeper braucht Rego als DSL und ein Team, das die Sprache verlässlich beherrscht. Kyverno arbeitet mit YAML-Patterns, die jeder Platform-Engineer ohne Schulung lesen kann. Die Entscheidung läuft fast immer auf Skill-Verfügbarkeit hinaus, nicht auf Feature-Listen.

Verwandt:Multi-Cluster ohne neues Ops-Silo  /  Kubernetes 1.36 Migration Checkliste

Warum Compliance-Drift bei Multi-Cloud-K8s schneller passiert als gedacht

In den Artikeln, die wir seit Anfang 2026 in cloudmagazin veröffentlicht haben, taucht ein Muster auf, das die meisten Plattform-Teams unterschätzen. Wer drei Cluster-Sets über EKS, AKS und GKE betreibt, hat irgendwann drei leicht unterschiedliche Default-Konfigurationen für Pod-Security-Standards. Eine kleine Abweichung bei der Definition von `runAsNonRoot`, ein anderes Verhalten bei automatischen Service-Account-Tokens, ein abweichender Defaulting-Pfad für Network-Policies. Im Einzelnen harmlos. In Summe entsteht ein Compliance-Profil, das niemand mehr vollständig dokumentiert hat.

Die NIS2-Implementierungen, über die unsere Autoren in den letzten Wochen geschrieben haben, machen genau diese Drift-Lücke jetzt zum Audit-Thema. Es reicht nicht mehr zu zeigen, dass eine Policy irgendwo existiert. Auditoren fragen nach dem Mechanismus, der sie durchsetzt. Confluence ist keine Antwort darauf.

Policy-as-Code mit OPA Gatekeeper oder Kyverno löst das Problem, indem es die Regel-Definition an den Punkt verschiebt, an dem Kubernetes ohnehin jede Ressource prüft. Den Admission-Controller. Damit wird Compliance ein Build-Schritt, kein Quartals-Termin.

OPA Gatekeeper vs. Kyverno: die operative Trennlinie

Die theoretischen Vergleiche der beiden Engines findet man in jeder zweiten DevOps-Konferenz-Aufzeichnung. In der Praxis trennen die Tools andere Linien, als die Feature-Matrix nahelegt.

Was in den Cluster-Migrationen unserer Autoren-Beobachtungen immer wieder kippt, ist die Skill-Frage. Rego ist mächtig, aber wenn von acht Platform-Engineers drei sie nicht produktiv schreiben können, wird die Policy-Pflege zum Bottleneck. Kyverno trifft die Lesbarkeits-Schwelle früher.

Ein Multi-Cloud-Setup ohne Policy-Drift: vier Schritte

Die ersten zwei Schritte sind das Pflichtprogramm. Schritt drei verhindert die Standard-Falle, in der Policies in Produktion kippen und vier Teams gleichzeitig blockieren. Schritt vier macht den Unterschied zwischen einer Compliance-Show und einem Setup, das auch nach 18 Monaten noch konsistent ist.

Was Plattform-Teams bei der Engine-Wahl 2026 wirklich entscheiden

In den Recherchen, die unsere Autoren mit DACH-Plattform-Verantwortlichen geführt haben, kristallisierten sich drei Entscheidungs-Anker heraus, die selten in den Konferenz-Folien auftauchen.

Erstens die Frage, ob das Plattform-Team Compliance ohnehin schon für Nicht-Kubernetes-Workloads (Terraform-Pläne, IAM-Policies, CI-Pipelines) durchsetzt. Wenn ja, ist OPA der natürliche Hebel, weil Rego diese Domains alle abdeckt. Wenn die Compliance-Welt rein Kubernetes ist, gibt es wenig Grund, eine zweite DSL ins Haus zu holen.

Zweitens die Größe und Senioritätsverteilung im Team. Ein Team von drei Engineers, in dem nur einer Rego verlässlich schreibt, ist mit Kyverno besser bedient. Sobald dieser eine Engineer Urlaub hat oder kündigt, bleibt die Policy-Pflege liegen. Kyverno-YAML überleben Personalfluktuation deutlich entspannter.

Drittens das vorhandene Sicherheits-Tooling. Wer Falco, Trivy oder Pod-Security-Standards bereits in der Pipeline hat, hat oft Reporting-Erwartungen, die Kyverno mit den Reports-CRDs nativ erfüllt. Gatekeeper liefert hier weniger out of the box.

Häufige Fragen

Lohnt sich Policy-as-Code schon ab einem einzelnen Kubernetes-Cluster?

Ja, sobald der Cluster Produktions-Workloads von mehr als einem Team trägt. Ohne Admission-Controller wandert die Konsistenz-Verantwortung in jedes einzelne Manifest. Mit Policy-as-Code wird sie zur Plattform-Eigenschaft. Bei einem Lab-Cluster ist der Overhead zu groß, bei einem Multi-Tenant-Setup ist er Pflicht.

Wie hoch ist der Performance-Overhead durch Admission-Webhooks?

In gut konfigurierten Setups liegt der zusätzliche Admission-Latency-Beitrag im einstelligen Millisekunden-Bereich pro Pod-Create. Kritisch wird es nur bei Bulk-Operations (etwa Helm-Releases mit hunderten Resources) oder bei sehr komplexen Constraint-Templates. Beide Engines unterstützen Caching und Background-Reconciliation.

Können OPA und Kyverno parallel im selben Cluster laufen?

Technisch ja, beide registrieren sich als unterschiedliche Webhooks. Operativ macht es selten Sinn. Doppelte Policies führen zu Konfusion im Debugging, doppelte Audit-Layer verdoppeln die Wartung. Wenn ein Migrationspfad notwendig ist, parallel betreiben, sonst auf eine Engine konsolidieren.

Was passiert, wenn der Admission-Webhook ausfällt?

Das hängt am `failurePolicy`-Setting. Auf `Fail` bedeutet jeder Webhook-Ausfall einen Cluster-Block für neue Pods. Auf `Ignore` werden Policies bei Webhook-Down umgangen, was im Worst Case Compliance-Lücken erzeugt. Best Practice für Produktion ist `Fail` plus Hochverfügbarkeit des Webhook-Deployments. Ein Single-Pod-Setup für einen Multi-Tenant-Cluster ist fahrlässig.

Reicht Policy-as-Code für NIS2-Compliance allein?

Nein, aber es deckt einen großen Teil der technischen Nachweispflichten ab. NIS2 verlangt zusätzlich Incident-Response-Prozesse, Lieferanten-Management und Berichtswesen. Policy-as-Code liefert den technischen Beleg für die Durchsetzung von Sicherheits-Konfigurationen, was die Audit-Last spürbar reduziert. Die organisatorische Seite bleibt davon unberührt.

Weiterlesen

• Plattform oder Fassade? Platform Engineering ehrlich bewertet
• Kubernetes 1.36 Haru: cgroup-v1-Abschaltung und DRA-Stabilität
• Container-Image-Diet 2026: Distroless, Wolfi, Chainguard

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt