Policy as Code: Infrastrukturänderungen im Griff behalten

Du hast drei Umgebungen: Entwicklung, Staging und Produktion. Jede wird durch Infrastructure as Code verwaltet. Die Pipeline läuft, die Pläne sehen gut aus, und die Änderungen werden angewendet. Doch eines Tages erstellt jemand eine Ressource in der falschen Region. Ein anderes Mal wird eine Cloud-Ressource ohne das obligatorische Cost-Center-Tag hochgezogen. Niemand hat es bemerkt, bis die Rechnung kam.

Separate Umgebungen lösen das Problem, Änderungen zu testen, bevor sie in die Produktion gelangen. Aber sie lösen nicht das Problem, dass Leute Änderungen vornehmen, die gegen organisatorische Regeln verstoßen. Du brauchst etwas, das diese Regeln automatisch durchsetzt – nicht nur ein Dokument, das niemand liest.

Warum manuelle Regeln nicht funktionieren

Die meisten Teams haben Richtlinien irgendwo aufgeschrieben. Eine Wiki-Seite besagt, dass alle Ressourcen ein environment-Tag haben müssen. Eine Slack-Nachricht sagt, dass Produktionsressourcen nur in ap-southeast-1 stehen dürfen. Eine Meeting-Entscheidung legt fest, dass jede Änderung an Firewall-Regeln die Zustimmung des Sicherheitsteams benötigt.

Diese Regeln existieren, aber sie verlassen sich auf menschliches Erinnerungsvermögen und gute Absichten. Leute vergessen. Neue Teammitglieder wissen nicht, dass das Wiki existiert. Dringende Änderungen überspringen den Review-Prozess. Und wenn etwas schiefgeht, hast du keine Möglichkeit zu beweisen, ob die Regel befolgt wurde oder nicht.

Manuelle Governance erzeugt Reibung, ohne Sicherheit zu bieten. Die Regeln sind da, aber sie werden erst durchgesetzt, nachdem der Schaden bereits eingetreten ist.

Policy as Code: Regeln, die in der Pipeline laufen

Eine Policy ist eine Regel, die jede Infrastrukturänderung befolgen muss. Governance ist die Art und Weise, wie du sicherstellst, dass diese Regeln tatsächlich eingehalten werden. Wenn du beides als Code schreibst und in deiner Pipeline ausführst, erhältst du etwas, das Policy as Code genannt wird.

Die Idee ist einfach: Anstatt Regeln in einem Dokument zu haben, schreibst du sie als ausführbare Prüfungen, die ausgeführt werden, bevor eine Änderung angewendet wird. Die Pipeline bewertet die vorgeschlagene Änderung anhand deiner Policies. Wenn eine Policy verletzt wird, stoppt die Pipeline und meldet genau, was falsch gelaufen ist.

Hier ist eine einfache Sentinel-Policy, die ein erforderliches environment-Tag für jede Ressource durchsetzt:

# Require every resource to have an "environment" tag
mandatory_tag = rule {
  all tfplan.resources as _, resource {
    resource.applied.tags contains "environment"
  }
}

main = rule {
  mandatory_tag
}

Das ist das gleiche Prinzip wie Infrastructure as Code. Du behandelst deine Regeln genauso wie deine Infrastrukturdefinitionen. Sie leben in einem Repository, werden reviewed, getestet und konsistent angewendet.

Häufige Policies, die du durchsetzen kannst

Tagging-Anforderungen sind der häufigste Ausgangspunkt. Viele Organisationen verlangen, dass jede Cloud-Ressource Tags wie environment, owner oder cost-center hat. Ohne Durchsetzung erhältst du inkonsistente Tags, fehlende Tags oder Tippfehler in Tags. Mit Policy as Code prüft die Pipeline die Plan-Ausgabe und lehnt jede Ressource ab, die die Tagging-Regeln nicht erfüllt.

Regionseinschränkungen sind eine weitere häufige Policy. Wenn deine Organisation entschieden hat, dass Produktions-Workloads nur in bestimmten Regionen laufen, sollte die Pipeline das durchsetzen. Ein Entwickler könnte versehentlich während einer nächtlichen Bereitstellung eine andere Region anvisieren. Die Policy fängt es ab, bevor eine Ressource erstellt wird.

Genehmigungsworkflows können ebenfalls in Policies eingebettet werden. Nicht alle Änderungen haben das gleiche Risiko. Das Ändern einer Firewall-Regel im Staging könnte einen Reviewer benötigen. Das Ändern derselben Regel in der Produktion könnte die Zustimmung des Sicherheitsteams erfordern. Die Pipeline kann die Umgebung, den Ressourcentyp und den Umfang der Änderung prüfen, um zu bestimmen, welcher Genehmigungspfad erforderlich ist.

Wie es in der Praxis funktioniert

Der typische Ablauf sieht so aus. Nachdem der Infrastrukturplan erstellt wurde und bevor der Apply-Schritt ausgeführt wird, führt die Pipeline Policy-Prüfungen durch. Diese Prüfungen lesen die Plan-Ausgabe und bewerten sie anhand deiner Regeln.

Hier ist eine visuelle Darstellung dieses Ablaufs:

flowchart TD A[Code Commit] --> B[Generate Plan] B --> C{Policy Check} C -- Pass --> D[Apply Change] C -- Fail --> E[Block Pipeline] E --> F[Show Error: Rule, Resource, Expected Value] D --> G[Deployment Complete]

Du kannst dedizierte Tools wie Open Policy Agent (OPA) oder Sentinel für komplexe Policies verwenden. Oder du schreibst einfache Skripte, die den Plan parsen und bestimmte Bedingungen prüfen. Das Tool ist weniger wichtig als das Prinzip: Die Prüfung muss automatisch, konsistent und blockierend sein.

Wenn ein Policy-Verstoß gefunden wird, stoppt die Pipeline. Die Ausgabe zeigt genau, welche Regel verletzt wurde, welche Ressource sie ausgelöst hat und welcher Wert erwartet wurde. Der Entwickler erhält sofortiges Feedback, nicht ein Ticket, das drei Tage später eintrifft.

Ausnahmen sind Teil des Systems

Policies sollten keine absoluten Barrieren sein. Es gibt legitime Gründe für Ausnahmen. Eine neue Geschäftsanforderung könnte Ressourcen in einer Region erfordern, die zuvor nicht genehmigt wurde. Ein Notfall-Fix könnte die normalen Tagging-Regeln umgehen müssen.

Der Schlüssel ist, Ausnahmen sichtbar und dokumentiert zu machen. Anstatt dass jemand die Policy stillschweigend umgeht, reicht er eine Ausnahmeanfrage ein. Die Anfrage durchläuft einen Genehmigungsprozess, und die genehmigte Ausnahme wird im Audit-Trail festgehalten. Die Pipeline kann sogar nach genehmigten Ausnahmen suchen und die Änderung zulassen.

Das verwandelt Ausnahmen von Schattenprozessen in dokumentierte Entscheidungen. Du weißt, wer was wann und warum genehmigt hat. Diese Informationen sind wertvoll für Audits, Post-Mortems und zukünftige Policy-Reviews.

Warum das Teams schneller macht

Es klingt kontraintuitiv. Das Hinzufügen automatisierter Prüfungen zu deiner Pipeline klingt, als würde es Dinge verlangsamen. Aber das Gegenteil ist der Fall.

Ohne Policy as Code erfordert jede Änderung, die einen sensiblen Bereich berühren könnte, eine manuelle Überprüfung. Der Reviewer muss den Plan prüfen, sich an die Regeln erinnern und eine Entscheidung treffen. Das kostet Zeit, und der Reviewer könnte etwas übersehen.

Mit Policy as Code passieren Routineprüfungen automatisch. Die Pipeline lehnt eindeutig ungültige Änderungen in Sekunden ab. Der Reviewer muss sich nur noch Änderungen ansehen, die wirklich menschliches Urteilsvermögen erfordern. Das Team wird schneller, weil es nicht auf manuelle Prüfungen für Dinge wartet, die automatisiert werden könnten.

Und wenn etwas schiefgeht, hast du einen klaren Audit-Trail. Du weißt, was sich geändert hat, wer es genehmigt hat und welche Policies betroffen waren. Kein Rätselraten mehr, keine Schuldzuweisungen mehr, kein „Ich wusste nicht, dass diese Regel existiert“ mehr.

Eine kurze Checkliste für den Einstieg

Wenn du Policy as Code für deine Infrastruktur-Pipeline in Betracht ziehst, sind hier die Schritte, um zu beginnen:

  • Wähle eine Policy aus, die heute die meisten Probleme verursacht. Tagging ist normalerweise ein guter Anfang.
  • Schreibe die Policy als Skript oder verwende ein Tool wie OPA. Teste sie gegen einen bekannten Verstoß.
  • Füge die Policy-Prüfung zwischen den Plan- und Apply-Schritten in deine Pipeline ein.
  • Führe sie zunächst im nicht-blockierenden Modus aus. Protokolliere Verstöße, aber lasse die Pipeline weiterlaufen.
  • Überprüfe die Verstöße eine Woche lang. Behebe False Positives und passe die Regeln an.
  • Wechsle in den blockierenden Modus. Lasse die Pipeline bei Verstößen anhalten.
  • Dokumentiere den Ausnahmeprozess. Mache klar, wie eine Ausnahme beantragt werden kann.

Das Fazit

Policy as Code verwandelt deine Infrastrukturregeln von vergessenen Dokumenten in automatisierte Wächter. Es fängt Verstöße ab, bevor sie die Produktion erreichen, bietet klare Audit-Trails und lässt dein Team schneller arbeiten, indem es Routineprüfungen automatisiert. Die Regeln leben in deinem Repository, werden wie Code reviewed und in jeder Pipeline-Ausführung ausgeführt. Das ist Governance, die tatsächlich funktioniert – nicht Governance, die auf einer Wiki-Seite lebt, die niemand liest.