Policy as Code hat den Ruf, Delivery zu verlangsamen. Tut es aber nur, wenn man es falsch angeht. Richtig implementiert, beschleunigt es Delivery, weil Entwickler Probleme vor dem Merge sehen statt im Audit.
Die Tool-Landschaft
- OPA (Open Policy Agent) — der Standard für allgemeine Policy-Entscheidungen, flexibel aber Rego-Lernkurve
- Conftest — CLI über OPA für Terraform-, Dockerfile-, Kubernetes-Policies
- Kyverno — Kubernetes-native, YAML-basierte Policies (einfacher als Rego)
- Gatekeeper — OPA für Kubernetes-Admission-Control
- Checkov / tfsec / Trivy — spezialisiert auf IaC und Container-Scanning
Stufenweise Einführung
Fehler Nummer 1: am Tag 1 alle Policies auf 'deny' stellen. Richtig ist eine Dreistufen-Einführung:
- Stufe 1 (Woche 1-4): 'warn' im CI, Output in PRs kommentiert
- Stufe 2 (Woche 5-8): kritische Policies auf 'deny', Rest bleibt 'warn'
- Stufe 3 (Woche 9+): schrittweise weitere Policies auf 'deny', jeweils mit Migration-Grace-Period
Regulatorische Anforderungen abbilden
In BaFin-/DORA-Kontexten lassen sich viele regulatorische Controls direkt in Policies übersetzen: 'keine Image-Pulls aus nicht-genehmigten Registries', 'alle Pods haben resource-limits', 'kein privileged-Container ohne explizite Exception', 'alle Deployments haben eine Namespace-annotierte Cost-Center-Zuordnung'. Das Audit-Gespräch wird dadurch deutlich kürzer.
“Policies, die Entwickler nicht verstehen, werden umgangen. Policies, die verstanden werden, werden respektiert.”