terraform plan meldet „no changes“. Gleichzeitig steht in der Cloud-Konsole bei einer Security Group SSH für das gesamte Internet offen. Plan ist weder kaputt noch lügt er — er kann es schlicht nicht sehen: Die Regel wurde von Hand angelegt, sie steht nicht im State, und Plan vergleicht State mit Config, nicht die Cloud mit Ihrer Absicht.
Das ist einer von vier blinden Flecken, wegen derer plan -detailed-exitcode allein nicht als Drift-Detektor taugt.
Was Plan nicht sieht
- Ressourcen außerhalb des State. Was an Terraform vorbei entstanden ist, existiert für ihn nicht.
- Getrennte State-Dateien. Drift in der einen ist aus der anderen nicht sichtbar; je sauberer die Infrastruktur zerlegt ist, desto mehr blinde Zonen entstehen zwischen den Teilen.
- Änderungen aufseiten des Providers. Der Provider wurde aktualisiert, Defaults haben sich verschoben — Plan meldet „no changes“, während die Ressource in der Cloud bereits anders aussieht.
- Semantik. Plan prüft den Soll- gegen den Ist-Zustand, aber nicht, ob der Soll-Zustand überhaupt zulässig ist: Öffentliches SSH und abgeschaltete Verschlüsselung zeigt er als völlig normalen Zustand.
Vier Ebenen statt eines Werkzeugs
Jeder blinde Fleck wird von einer eigenen Ebene geschlossen. Keine ersetzt die anderen.
| Ebene | Womit | Was sie abdeckt |
|---|---|---|
| L1 | plan -detailed-exitcode (Code 2 = Diff vorhanden) | Drift in verwalteten Ressourcen |
| L2 | Cloud-Inventar: AWS Config, Steampipe | Ressourcen außerhalb des State, Compliance im ganzen Account |
| L3 | Policy Engine: OPA, Conftest, Sentinel | Semantik über der Plan-Ausgabe |
| L4 | Events: EventBridge → Lambda → Benachrichtigung | manuelle Konsolen-Änderungen, im Moment der Änderung |
L3 verdient eine eigene Bemerkung: Es arbeitet gegen den Plan, nicht gegen die Cloud. Die Pipeline terraform show -json plan.tfplan | conftest test -p policies/ macht aus der Policy-Prüfung ein Gate vor dem Apply — derselbe Mechanismus, mit dem Sicherheit in die Pipeline einzieht und zwar auf deren anderen Stufen.
Die Hälfte der Drift-Ursachen sind keine Verstöße
Die Ursachenliste liest sich meist wie ein Sündenregister: Änderungen in der Konsole, Hotfixes an der CI vorbei, fremde Automatisierung, andere Werkzeuge auf denselben Ressourcen. Bei zwei weiteren Ursachen hat aber niemand etwas verletzt.
Die erste sind Provider-Defaults: Die Cloud hat einen Standardwert zwischen zwei Versionen geändert. Die zweite sind zeitgebundene Änderungen: Passwortrotation, Zertifikatserneuerung, Autoscaling der Kapazität. Mal landet das im State, mal driftet es.
Daraus folgt praktisch: Ein System, das auf jede Drift mit einem Rollback antwortet, rollt regelmäßig das normale Leben der Infrastruktur zurück. Die Trennung zwischen „automatisch korrigieren“ und „einem Menschen zeigen“ ist kein Konfigurationsdetail, sondern die zentrale Entwurfsentscheidung.
Was den Wechsel zur Auto-Korrektur antreibt
Eine Umfrage von ControlMonkey liefert drei Zahlen: 71% der Teams sagen, generative Werkzeuge vergrößern ihr IaC-Volumen, 63% sagen, solche Infrastruktur sei schwerer zu steuern als handgeschriebene, 81% sagen, manuelles Review komme bei diesem Tempo nicht mehr mit.
Ein Vorbehalt ist Pflicht: ControlMonkey verkauft eine IaC-Plattform, und der Schluss, reine Detektion sterbe 2026 aus, ist deren Prognose und kein neutraler Befund. Die Volumenzahlen sind plausibel und decken sich mit dem, was ringsum zu sehen ist; den Schluss daraus zieht der Verkäufer der Lösung.
Vorsichtiger formuliert dieselbe Beobachtung: Je mehr Änderungen pro Zeiteinheit, desto teurer wird eine Warteschlange von Alerts, die niemand abarbeitet. Ein Alert ohne Adressaten ist keine Observability, sondern ein aufgeschobener Incident.
Remediation as Code: wo die Grenze verläuft
Automatische Korrektur heißt nicht „alles zurückrollen“. Praktisch sind es drei getrennte Entscheidungen, und man trifft sie besser vorab als im Moment des Auslösens.
Was automatisch zurückgerollt wird. Eine schmale Liste, bei der der richtige Zustand bekannt und eindeutig ist: öffentlicher Zugriff, abgeschaltete Verschlüsselung, fehlende Pflicht-Tags. Hier gehört Automatik hin, weil die Alternative ein offenes Loch ist, das auf einen Menschen wartet.
Was in den State übernommen wird. Eine legitime manuelle Änderung soll nicht ewig als Drift leuchten. Dafür gibt es plan -refresh-only: Er synchronisiert den State mit der Realität und plant überhaupt keine Aktionen an Ressourcen. Danach wandert die Änderung über einen normalen PR in den Code.
Was als Incident läuft. Alles Übrige. Drift in Produktion ist ein P2: Artefakt sichern, im Audit-Log nachsehen, wer wann was geändert hat, zwischen Vorwärtsrollen und Zurückrollen entscheiden, Postmortem schreiben. Das Postmortem ist hier kein Ritual — es ist der einzige Weg zu bemerken, dass dieselbe Drift immer aus demselben Grund wiederkehrt.
Struktureller Schutz schlägt Detektion
Die billigste Drift ist die, die nicht passieren kann.
- Mutationen allen außer Terraform verbieten. Eine IAM-Policy, die ändernde Aktionen für jeden Principal ablehnt, der nicht als Terraform-verwaltet markiert ist. Das ist keine Prüfung, sondern eine Wand: Die manuelle Änderung wird nicht entdeckt, weil sie nicht stattfindet.
ManagedByüberdefault_tagsdes Providers setzen — einmal im Provider statt in jeder Ressource. Auf diesen Tags ruht der vorige Punkt.- Bestehendes über
import-Blöcke aufnehmen statt über die Shell-History: Der Import wird zu einer normalen Änderung, die im PR sichtbar und diskutierbar ist.
Policy as Code wirkt hier als Beschleuniger und nicht als Bremse — aber nur, wenn die Regeln zusammen mit dem Code entstehen und nicht obendrauf; zu diesem Paradox gibt es ein eigenes Gespräch.
Werkzeuge: ein ehrlicher Vorbehalt
driftctl wird oft als unabhängiger Scanner für Ressourcen empfohlen, die im State fehlen. Das Werkzeug funktioniert, aber seit dem 29. Juni 2023 ist das Projekt im Maintenance Mode: Die Autoren schreiben ausdrücklich, dass sie keine Prüfung von Beiträgen zusagen können. Für ein einmaliges Audit ist das kein Problem. Für eine dauerhafte L2-Ebene schon: Neue Ressourcentypen kommen nicht hinzu, und genau dort sammelt sich das Unbemerkte. Eine dauerhafte Ebene steht sicherer auf dem Inventar der Cloud selbst.
Und noch zur Versuchung, Drift einem GitOps-Controller zu überlassen. Das Muster „Argo CD startet einen Job mit terraform apply“ sieht elegant aus und scheitert am Wesentlichen: Der Job läuft einmal, eine fortlaufende Abgleichung gibt es nicht. Cloud-Ressourcen brauchen entweder eine ehrliche CI-Pipeline oder eine Control Plane, die reconciled — das ist aber ein anderes Werkzeug und ein anderes Gespräch über State.
Womit anfangen, wenn heute nur L1 steht
- Ein nächtliches
plan -detailed-exitcodeje State; Code 2 legt ein Ticket mit dem Diff im Body an. Der billigste Schritt, und er zeigt sofort das Ausmaß. default_tagsmitManagedByplus IAM-Verbot von Mutationen an Terraform vorbei. Zwei Schritte, und der Zufluss neuer Drift verengt sich deutlich.- Ein Policy-Gate auf dem Plan vor dem Apply — mit zwei, drei Regeln beginnen, die niemals gebrochen werden dürfen.
- Cloud-Inventar für Ressourcen außerhalb des State. Zu diesem Zeitpunkt sind die Funde wenige und gut abzuarbeiten.
Auto-Korrektur kommt zuletzt und auf eine schmale Liste — wenn klar ist, welche Drift in Ihrer Infrastruktur normal ist und welche nicht. Sonst fängt die Automatik an zu reparieren, was nie kaputt war.