Wo Infrastruktur-Richtlinien ausgeführt werden: Plan, Apply und Post-Deploy

Sie haben Ihre Infrastruktur-Richtlinien als Code geschrieben. Sie prüfen auf Sicherheitsverstöße, Kostenüberschreitungen und Namenskonventionen. Jetzt stellt sich die praktische Frage: Wo in Ihrer Pipeline sollen diese Richtlinien tatsächlich ausgeführt werden?

Die Antwort ist nicht ein Ort. Es sind drei. Jeder Ort fängt eine andere Art von Problem ab, und wenn Sie einen davon auslassen, entstehen Lücken in Ihren Schutzmechanismen.

Richtlinien zur Plan-Zeit: Probleme verhindern, bevor sie entstehen

Der erste Ort, um Richtlinien auszuführen, ist während der Plan-Phase. In Tools wie Terraform, Pulumi oder OpenTofu berechnet die Plan-Phase, welche Änderungen an Ihrer Infrastruktur vorgenommen würden. Sie zeigt Ihnen ein Diff: Ressourcen, die erstellt, geändert oder gelöscht werden sollen. Aber tatsächlich hat sich noch nichts geändert.

Hier Richtlinien auszuführen, wirkt als früher Filter. Die Richtlinien-Engine prüft die geplanten Änderungen und entscheidet, ob sie erlaubt sind. Wenn ein Entwickler versucht, eine Sicherheitsgruppe für 0.0.0.0/0 zu öffnen, blockiert die Richtlinie dies bereits zur Plan-Zeit. Wenn jemand einen teuren Instanztyp auswählt, der Ihr Budgetlimit überschreitet, markiert die Richtlinie dies. Wenn ein Ressourcenname nicht Ihrer Namenskonvention folgt, lehnt die Richtlinie ihn ab.

Der Vorteil liegt auf der Hand: Sie verhindern Verstöße, bevor überhaupt eine Ressource existiert. Die Pipeline stoppt, der Entwickler erhält eine klare Nachricht, was blockiert wurde und warum, und kann den Code korrigieren, ohne bereits erstellte Ressourcen bereinigen zu müssen. Kein Rollback nötig. Keine verwaisten Ressourcen. Kein Sicherheitsfenster.

Hier ist ein konkretes Beispiel mit Open Policy Agent (OPA), um eine Richtlinie durchzusetzen, die öffentliche Sicherheitsgruppen zur Plan-Zeit blockiert:

# Terraform-Plan erstellen und in JSON konvertieren
export TF_VAR_region="us-east-1"
terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json

# Richtlinie auswerten: ablehnen, wenn eine Sicherheitsgruppe 0.0.0.0/0 als Eingang hat
# policy.rego enthält: deny[msg] { ... }
opa eval --data policy.rego --input plan.json "data.terraform.deny"

# Wenn die Ausgabe eine deny-Nachricht enthält, Pipeline fehlschlagen lassen
if opa eval --data policy.rego --input plan.json "data.terraform.deny" | grep -q '"result"'; then
  echo "POLICY VIOLATION: Public security group detected. Blocking deployment."
  exit 1
fi

Dies ist der effizienteste Ort, um Richtlinien durchzusetzen. Es spart Zeit, reduziert Verschwendung und hält Ihre Infrastruktur von Anfang an sauber.

Richtlinien zur Apply-Zeit: Die letzte Verteidigungslinie

Der zweite Ort, um Richtlinien auszuführen, ist während der Apply-Phase. Apply ist der Moment, in dem die Änderungen tatsächlich in Ihrer Infrastruktur wirksam werden. Ressourcen werden wirklich erstellt, geändert oder gelöscht.

Warum Richtlinien erneut ausführen, wenn Sie bereits zur Plan-Zeit geprüft haben? Weil Plan-Zeit-Prüfungen blinde Flecken haben. Sie sehen nur, was im Code steht. Sie können den tatsächlichen Zustand Ihrer Infrastruktur nicht sehen, der möglicherweise außerhalb der Pipeline abgewichen ist. Jemand könnte eine Ressource manuell über die Konsole geändert haben. Ein vorheriges Deployment könnte Dinge in einem unerwarteten Zustand hinterlassen haben. Der Plan geht von einem bestimmten Ausgangspunkt aus, aber die Realität kann abweichen.

Richtlinien zur Apply-Zeit validieren erneut, bevor die Änderungen ausgeführt werden. Sie fangen Fälle ab, in denen der Plan in Ordnung schien, aber der tatsächliche Infrastrukturzustand einen Verstoß verursachen würde. Sie behandeln auch Szenarien, in denen Änderungen vollständig von außerhalb der Pipeline kommen. Wenn jemand ein manuelles Terraform Apply von seinem Laptop ausführt, greift die Apply-Zeit-Richtlinie trotzdem.

Ein weiterer wichtiger Anwendungsfall sind Genehmigungsstufen. Zur Plan-Zeit kann eine Richtlinie einen Verstoß erkennen und markieren. Aber die Entscheidung, fortzufahren oder zu stoppen, fällt oft zur Apply-Zeit. Vielleicht erfordert der Verstoß, dass ein leitender Ingenieur eine Ausnahme genehmigt. Vielleicht ist die Änderung mit hohem Risiko verbunden und benötigt ein zweites Paar Augen. Apply-Zeit-Richtlinien können diese Workflows durchsetzen.

Betrachten Sie Plan-Zeit-Richtlinien als Prävention und Apply-Zeit-Richtlinien als Verifikation. Beide sind notwendig.

Richtlinien nach dem Deployment: Drift und stille Verstöße erkennen

Der dritte Ort, um Richtlinien auszuführen, ist, nachdem Ressourcen bereits laufen. Dies ist die Post-Deploy-Durchsetzung und dient einem anderen Zweck.

Plan- und Apply-Richtlinien fangen Verstöße zum Zeitpunkt der Änderung ab. Aber die Infrastruktur bleibt nicht statisch. Jemand mit Konsolenzugriff kann nach dem Deployment eine Sicherheitsgruppenregel ändern. Eine neue Compliance-Anforderung kann zuvor akzeptable Ressourcen nicht konform machen. Ressourcen, die nur temporär sein sollten, laufen möglicherweise Monate später noch und verursachen Kosten.

Post-Deploy-Richtlinien werden nach einem Zeitplan ausgeführt. Jede Stunde, jede Nacht oder jede Woche scannen sie Ihre Live-Infrastruktur und vergleichen sie mit Ihren Richtlinienregeln. Jede Ressource, die gegen eine Regel verstößt, wird gemeldet. Der Bericht geht an Slack, E-Mail oder ein Dashboard. Das Team behebt dann den Verstoß oder entfernt die Ressource.

So fangen Sie Konfigurationsdrift. So setzen Sie auch Richtlinien durch, die nicht zur Plan- oder Apply-Zeit geprüft werden können. Zum Beispiel kann eine Richtlinie, die besagt "Keine Ressource sollte ohne Überprüfung älter als 90 Tage sein", nur durch regelmäßiges Scannen laufender Ressourcen durchgesetzt werden.

Post-Deploy-Richtlinien verwandeln Compliance von einer einmaligen Hürde in eine fortlaufende Praxis. Ohne sie driftet Ihre Infrastruktur langsam von Ihren Standards ab, und niemand bemerkt es bis zur nächsten Prüfung.

Wie die drei Punkte zusammenarbeiten

Jeder Punkt deckt ab, was die anderen übersehen. Plan-Zeit-Richtlinien stoppen Verstöße, bevor sie passieren. Apply-Zeit-Richtlinien fangen ab, was die Plan-Zeit übersehen hat, und setzen Genehmigungsworkflows durch. Post-Deploy-Richtlinien erkennen Drift und langfristige Probleme.

Das folgende Diagramm zeigt, wie die drei Richtlinien-Prüfpunkte in eine typische Infrastruktur-Pipeline passen:

flowchart TD A[Code Commit] --> B[Plan Phase] B --> C{Plan-Time Policy Check} C -->|Pass| D[Apply Phase] C -->|Fail| E[Block & Notify Developer] E --> A D --> F{Apply-Time Policy Check} F -->|Pass| G[Resources Created/Modified] F -->|Fail| H[Block & Require Approval] H --> D G --> I[Post-Deploy Policy Scan] I -->|Compliant| J[Monitor Continuously] I -->|Drift Detected| K[Alert Team & Remediate] K --> G

Wenn Sie Richtlinien nur zur Plan-Zeit ausführen, umgehen manuelle Änderungen Ihre Regeln. Wenn Sie Richtlinien nur zur Apply-Zeit ausführen, erstellen Sie dennoch Ressourcen, die gegen Richtlinien verstoßen, bevor die Prüfung läuft. Wenn Sie Richtlinien nur nach dem Deployment ausführen, reagieren Sie immer nur auf Probleme, anstatt sie zu verhindern.

Alle drei sind für ein vollständiges Schutzsystem notwendig.

Praktische Checkliste

Hier ist eine Kurzreferenz für die Einrichtung von Richtlinien-Ausführungspunkten in Ihrer Pipeline:

  • Plan-Phase: Führen Sie Richtlinien gegen das geplante Diff aus. Blockieren Sie Änderungen, die gegen Sicherheits-, Kosten- oder Namensregeln verstoßen. Lassen Sie die Pipeline frühzeitig fehlschlagen.
  • Apply-Phase: Führen Sie Richtlinien erneut aus, bevor Sie Änderungen ausführen. Fangen Sie Drift ab und erzwingen Sie manuelle Genehmigung für risikoreiche Änderungen.
  • Post-Deploy: Planen Sie regelmäßige Richtlinien-Scans der Live-Infrastruktur. Melden Sie Verstöße an das Team. Beheben oder entfernen Sie nicht konforme Ressourcen.

Das Fazit

Richtlinien an nur einem Ort auszuführen, reicht nicht. Plan-Zeit-Prüfungen verhindern Probleme, bevor sie beginnen. Apply-Zeit-Prüfungen fangen ab, was durchrutscht. Post-Deploy-Prüfungen halten Ihre Infrastruktur langfristig ehrlich. Bauen Sie alle drei in Ihre Pipeline ein, und Ihre Richtlinien werden Ihre Infrastruktur tatsächlich schützen, anstatt Ihnen nur ein falsches Sicherheitsgefühl zu geben.