Policy-as-Code

Eine Policy-Engine bekommt zwei Dinge. Das eine ist die Regel, geschrieben als Code. Das andere ist der Gegenstand der Prüfung, etwa ein Kubernetes-Manifest, ein Terraform-Plan oder ein API-Aufruf, meist als JSON. Die Engine wertet die Regel gegen diese Daten aus und liefert „erlaubt" oder „verweigert", oft mit einer Begründung. Die Pipeline oder der Cluster reagiert auf diese Antwort und bricht den Build ab oder weist das Deployment zurück. Das verbreitetste Werkzeug dafür ist Open Policy Agent (OPA) mit seiner Sprache Rego. Für Kubernetes gibt es daneben Kyverno, das Regeln als YAML beschreibt.

Eine Regel wie „kein Container darf als root laufen" oder „jedes Deployment braucht eine gültige SBOM" liegt damit im Repository wie Anwendungscode. Das Team bespricht Änderungen im Review und sichert die Regel mit Tests ab. Verstöße fallen beim Deployment auf und nicht erst im Audit Monate später. Eine Regel im Wiki-Artikel hängt davon ab, dass sich jemand an sie erinnert. Eine Regel als Code hängt nur davon ab, dass die Pipeline läuft.

Aus Sicht des Audits heißt dieselbe Idee Compliance as Code. Anforderungen aus der IEC 62443, aus NIS2 oder aus internen Sicherheitsrichtlinien werden zu ausführbaren Gates. Weil jede Regel versioniert im Repository liegt, entsteht die Audit-Spur nebenbei. Fragt der Auditor „Wer hat diese Regel wann geändert?", beantwortet ein git log das in Sekunden. Ohne Repository dauert dieselbe Antwort eine Woche Suche quer durch Laufwerke und Mail-Postfächer.

Bei den Werkzeugen hat sich seit 2024 einiges bewegt. OPA 1.0 erschien im Dezember 2024 und machte die bereinigte Sprachfassung Rego v1 zum Standard. Kubernetes bringt seit Version 1.30 die ValidatingAdmissionPolicy als stabile, eingebaute Policy-Prüfung mit. Sie nutzt die Ausdruckssprache CEL und braucht für einfache Cluster-Regeln keinen zusätzlichen Admission-Webhook. Wer Regeln über CI-Pipelines, Terraform, APIs und Kubernetes hinweg durchsetzen will, bleibt bei OPA am flexibelsten. Wer nur Kubernetes absichert, kommt mit Kyverno oder den Bordmitteln meist schlanker aus.

Die meisten Projekte stolpern über zu strikte Regeln. Eine Policy blockiert einen legitimen Sonderfall, das Team braucht den Release trotzdem, und die Ausnahme entsteht am System vorbei. Das verhindert nur ein dokumentierter Ausnahmeprozess. Dazu kommt die Einarbeitung in Rego: Eine Regel ohne Tests kann selbst falsch sein und lässt dann genau das durch, was sie verhindern soll.