Policy as Code in der AI-Code-Ära: das Paradox aus Geschwindigkeit und Kontrolle

Copilot schreibt in 10 Sekunden, wofür ein Senior früher eine Stunde brauchte. Cursor baut ein Feature aus einem Absatz heraus. Claude Code öffnet einen PR ganz ohne Mensch in der Schleife. All das funktioniert — bis auf eines: Review ist manuell geblieben. Das Tempo von Production-Code überholt inzwischen routinemäßig das Tempo des Human Review, und das schreibt die Anforderungen an Governance neu.

Früher war Policy as Code ein «nice to have»: Code lief durch einen PR, zwei Augenpaare schauten auf den Diff, ein Action: "*" im IAM oder fehlende resources.limits wurden vom Senior innerhalb eines Tages gefangen. Heute liegt die Latenz zwischen AI-generiertem Code und seinem Versuch, im Cluster zu landen, im Minutenbereich, und die Zahl solcher Versuche bei Dutzenden pro Team und Tag. PaC wird vom Bonus zur funktionalen Anforderung. Es geht nicht um «AI schreibt Policies» — es geht um deterministic Admission Rules, geschrieben von Menschen oder AI, aber durchgesetzt ohne Human in the Loop, weil der Mensch schlicht nicht mehr nachkommt.

Drei Stellen, an denen man einen Verstoß abfangen kann

Ein einziges Admission-Gate im Cluster ist «alles oder nichts». Ein einziger CI-Check ist «umgehbar via --skip oder Hotfix-Branch». Das Modell, das in der Realität hält, sind drei Layer, und jeder fängt seine eigene Fehlerklasse.

CI / pre-merge. conftest gegen Rego-Policies, Trivy gegen CVEs, Checkov gegen Terraform-Configs. Am billigsten überhaupt: der Defekt wird vor dem Merge gefangen, vor dem Build, vor der Registry. Hier wohnen «erlaube nicht cidr_blocks = ["0.0.0.0/0"] auf Port 22» und «erlaube kein Action: "*" im IAM». Für Terraform ist das obligatorische Gate conftest test plan.json --policy ./policies/ gegen terraform plan -json, denn ein einziges apply rollt dutzende Ressourcen auf einmal aus, und im PR zurückrollen ist billiger als später.

Admission (Cluster). OPA Gatekeeper, Kyverno oder natives CEL ValidatingAdmissionPolicy. Hier wird gefangen, was CI durchgelassen hat: Deploy eines alten Tags an der Pipeline vorbei, ein Image aus einer nicht signierten Registry, ein Pod ohne runAsNonRoot. Admission ist die Last Line of Defense im Sinne von «vor dem etcd-Write»: Network-Egress-Block greift später, Runtime Detection (Falco) noch später.

Runtime. Falco/Tetragon sind detektiv, nicht präventiv. Sie fangen die Shell im Prod-Container, den Secret-Zugriff aus dem default ServiceAccount. Sie blockieren nicht — sie alarmieren, und sind deshalb ohne die ersten beiden Layer wertlos.

Das wichtige Detail: ein CI-Gate ohne Admission-Gate ist ein falsches Sicherheitsgefühl. CI fängt, was du gebaut hast; Admission fängt, was du deployt hast. Diese beiden Mengen überlappen sich, decken sich aber nicht.

Womit durchsetzen

Drei Werkzeuge, und die Wahl zwischen ihnen ist nicht «das Beste», sondern «das, was zum Team-Profil passt».

OPA Gatekeeper — Rego, Industriestandard, ausgereifte Validate, Mutation in Beta. Die Stärke ist Regos Ausdruckskraft für komplexe Regeln mit Cross-Resource-Logik. Die Schwäche ist die Lernkurve und die Sprachbarriere: ein Team, das nie Rego geschrieben hat, verbringt Wochen mit «seinem ersten nützlichen Constraint».

Kyverno — YAML statt Rego, mutate/generate von Haus aus (zum Beispiel, automatisch eine NetworkPolicy in einen neuen Namespace zu legen), eingebautes verifyImages für Cosign/Sigstore ohne externe Data Providers. CNCF Incubating. Default für Teams, die Mutation und Image-Policy brauchen und keine weitere DSL wollen.

CEL ValidatingAdmissionPolicy — GA in Kubernetes 1.30, MutatingAdmissionPolicy + CEL GA in 1.36. Sie läuft innerhalb des API-Servers: kein TLS, kein Deployment, keine cert-manager-Abhängigkeit, kein Failure Mode «Webhook down → alles abgelehnt oder alles durchgelassen». Sie deckt die Klasse einfacher deklarativer Validierungen ab (required Labels, Naming Conventions, Transition Rules) und nimmt Kyverno/OPA die «Steuer auf einfache Validierungen» ab. Sie verdrängt sie nicht — für Image Verification, multi-resource generate und komplexe Regeln braucht es weiterhin Kyverno.

Ein praktischer Leitfaden: CEL für Einfaches, Kyverno für die Mitte und Image-Policy, OPA Gatekeeper für Teams mit komplexer Cross-Resource-Logik und Rego-Kultur.

Was PaC in Production zerbricht

• failurePolicy: Ignore auf der ValidatingWebhookConfiguration. Default vieler Tutorials. Unter Last oder im Incident degradiert die Policy-Engine — Admission defaults to allow, der Bypass aktiviert sich genau dann, wenn er am gefährlichsten ist. Immer Fail.
• enforcementAction: dryrun für immer. Gatekeepers Killer-Feature ist Dryrun-Mode zum Beobachten des Blast Radius vor dem Flip nach deny. Wenn er ein halbes Jahr bleibt, ist es keine Policy mehr, es ist Logging. Harte Timeline: Dryrun eine Woche → deny.
• Ein gigantisches ConstraintTemplate / ClusterPolicy. Unmöglich zu debuggen, unmöglich zu reviewen, eine Exception für einen Namespace bricht alle anderen.
• PaC ohne Unit-Tests. OPA Rego bringt ein eingebautes Test-Framework mit, Kyverno hat kyverno cli test. Eine AI-generierte Policy ohne Test ist ein AI-generierter Security Incident.

Wo das zusammenläuft

Policy as Code in der AI-Code-Ära ist keine Methode, Entwickler wieder auf prä-AI-Tempo zu drosseln. Sie sind deterministic Guardrails, die Human Review auf wiederkehrenden Mustern (required Labels, Image Tags, Resource Limits, IAM-Wildcards) freigeben und dort behalten, wo er wirklich zählt (Architektur, Business-Logik, Edge Cases). Das Speed-vs-Control-Paradoxon löst sich nicht durch die Wahl «Speed oder Control», sondern durch das Verlagern von Control aus der manuellen Spur in die automatische.

Ohne diese Brücke ist ein AI-Agent ein Verstärker von Fehlern. Mit ihr ist ein AI-Agent ein Verstärker des Team-Durchsatzes.