Wenn Cloud-Konsole und IaC-Code sich widersprechen: Infrastruktur-Drift automatisch erkennen

Sie verwalten Ihre Infrastruktur seit Monaten mit Terraform. Alles ist in Code definiert, durch Pull-Requests reviewed und über Pipelines deployed. Eines Tages muss ein Teammitglied schnell eine Konfigurationsänderung vornehmen. Statt den Pipeline-Weg zu gehen, loggt es sich in die Cloud-Konsole ein, ändert manuell eine Security-Group-Regel und macht weiter. Die Änderung funktioniert. Niemand denkt mehr daran.

Wochen später führen Sie ein neues Deployment aus. Terraform plant, die Security-Group-Änderung rückgängig zu machen, weil der Code noch die alte Definition enthält. Wenn Sie den Plan anwenden, wird die bewusst vorgenommene Änderung überschrieben. Wenn Sie ihn überspringen, stimmt Ihr Code nicht mehr mit der Realität überein. Sie haben jetzt Infrastruktur-Drift.

Drift ist die Lücke zwischen dem, was Ihr Infrastruktur-Code vorgibt, und dem, was tatsächlich in Ihrer Cloud-Umgebung existiert. Das ist kein theoretisches Problem. Es tritt in jedem Team auf, das Infrastruktur in größerem Umfang verwaltet. Die Frage ist nicht, ob Drift auftritt, sondern wie schnell Sie ihn finden.

Warum manuelle Drift-Erkennung scheitert

Technisch gesehen können Sie Drift erkennen, indem Sie die Cloud-Konsole öffnen, jede Ressource inspizieren und mit Ihrem IaC-Code vergleichen. Das funktioniert, wenn Sie fünf Ressourcen verwalten. Es funktioniert nicht mehr, wenn es fünfzig, fünfhundert oder fünftausend sind.

Manuelle Erkennung hat drei Probleme. Erstens ist sie langsam. Ein einzelner Vergleich kann Minuten dauern. Multiplizieren Sie das mit Hunderten von Ressourcen, und Sie verbringen Stunden mit etwas, das automatisiert werden sollte. Zweitens ist sie unzuverlässig. Menschliche Augen übersehen kleine Unterschiede, besonders wenn Ressourcen Dutzende von Konfigurationsfeldern haben. Drittens ist sie inkonsistent. Verschiedene Teammitglieder prüfen möglicherweise unterschiedliche Dinge oder vergessen die Prüfung ganz.

Das eigentliche Problem ist das Timing. Drift kann jederzeit auftreten. Ein manueller Check einmal pro Woche bedeutet, dass Sie tagelang mit einer unentdeckten Änderung leben. Wenn diese Änderung eine Sicherheitslücke einführt oder eine Abhängigkeit zerstört, werden Sie es auf die harte Tour beim nächsten Incident erfahren.

Wie automatisierte Drift-Erkennung funktioniert

Automatisierte Drift-Erkennung folgt einem einfachen Prinzip: Führen Sie regelmäßig einen Vergleich zwischen Ihrem tatsächlichen Infrastrukturzustand und Ihren IaC-Definitionen durch. Dieser Prozess heißt Drift-Scan. Ein Drift-Scan ändert nichts. Er findet nur Unterschiede und meldet sie.

Der gängigste Ansatz verwendet die gleichen Tools, die Sie bereits zur Infrastrukturverwaltung einsetzen. Terraform zum Beispiel hat einen plan-Befehl, der Ihre State-Datei mit den tatsächlichen Cloud-Ressourcen vergleicht. Ihre State-Datei ist eine Aufzeichnung, die Terraform lokal oder remote führt und speichert, welche Ressourcen erstellt wurden und wie ihre aktuelle Konfiguration aussieht. Wenn Sie terraform plan ausführen, ohne den Code zu ändern, prüft das Tool, ob die State-Datei mit dem übereinstimmt, was tatsächlich in der Cloud existiert. Wenn jemand eine Ressource direkt in der Konsole geändert hat, zeigt der Plan dies als eine Änderung an, die Terraform vornehmen möchte.

Das ist die Grundlage der Drift-Erkennung: Führen Sie regelmäßig einen Plan aus und prüfen Sie auf unerwartete Änderungen.

Hier ist ein minimales Bash-Skript, das einen Drift-Scan durchführt und Ihr Team benachrichtigt, wenn Drift gefunden wird:

#!/bin/bash
# drift-scan.sh - Führt einen Terraform-Drift-Scan durch und benachrichtigt bei Änderungen

set -euo pipefail

cd /pfad/zum/terraform/projekt

terraform init -input=false

# State aus Live-Ressourcen aktualisieren, dann mit detailliertem Exit-Code planen
terraform plan -refresh-only -detailed-exitcode -out=drift.tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
    # Exit-Code 2 bedeutet, es gibt Änderungen (Drift erkannt)
    echo "Drift erkannt um $(date)"
    
    # Eine lesbare Zusammenfassung erzeugen
    terraform show drift.tfplan > drift-summary.txt
    
    # Benachrichtigung an Slack senden (Webhook-URL anpassen)
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"🚨 Drift in der Produktion erkannt!\n$(cat drift-summary.txt)\"}" \
        https://hooks.slack.com/services/YOUR/WEBHOOK/URL
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
    echo "Fehler während der Plan-Ausführung"
    exit 1
else
    echo "Kein Drift erkannt"
fi

Dieses Skript kann von einem Cron-Job oder einer geplanten CI/CD-Pipeline ausgeführt werden, um alle paar Stunden zu laufen.

Das folgende Flussdiagramm zeigt den vollständigen Drift-Erkennungszyklus:

flowchart TD A[IaC-Code<br/>Soll-Zustand] -->|terraform apply| B[Cloud-Ressourcen<br/>Ist-Zustand] B -->|Manuelle Änderung in Konsole| C[Abgewichene Ressource] C -->|Geplanter Plan oder Refresh| D{Drift erkannt?} D -->|Ja| E[Benachrichtigung<br/>Slack oder E-Mail] D -->|Nein| B E --> F{Entscheidung zur Reaktion} F -->|Abgleichen| G[terraform apply macht Änderung rückgängig] F -->|Akzeptieren| H[IaC-Code an Ist-Zustand anpassen] G --> B H --> A

Jenseits des einfachen Plans: Genaue Ergebnisse erzielen

Es gibt ein subtiles, aber wichtiges Detail. Ein normaler terraform plan vergleicht die State-Datei mit den tatsächlichen Ressourcen. Aber was, wenn die State-Datei selbst veraltet ist? Wenn jemand eine Änderung in der Konsole vorgenommen hat, spiegelt die State-Datei diese möglicherweise nicht wider. Der Plan würde den Drift nicht erkennen, weil er zwei Dinge vergleicht, die beide nicht synchron sind.

Einige Tools handhaben das besser. Terraform Cloud und OpenTofu bieten eine Drift-Erkennung, die tiefer geht. Anstatt nur den State mit den Ressourcen zu vergleichen, aktualisieren sie zunächst den State, indem sie die tatsächliche Konfiguration aus der Cloud abrufen, und vergleichen dann diesen aktualisierten State mit Ihrem Code. Das ergibt einen Vergleich von Code zu tatsächlichen Ressourcen, nicht von State zu Ressourcen. Das Ergebnis ist genauer, weil es auch Änderungen erfasst, die vollständig außerhalb der State-Datei stattgefunden haben.

Diese Unterscheidung ist wichtig. Wenn Sie sich nur auf die einfache Plan-Ausgabe verlassen, übersehen Sie möglicherweise Drift, der eingeführt wurde, bevor die State-Datei zuletzt aktualisiert wurde. Ein ordentlicher Drift-Scan sollte immer damit beginnen, den State aus der Live-Umgebung zu aktualisieren.

Planung und Benachrichtigung

Ein Drift-Scan muss nach einem Zeitplan laufen. Wie oft, hängt davon ab, wie häufig Änderungen außerhalb Ihrer Pipeline stattfinden. Teams, die kritische Produktionsinfrastruktur verwalten, führen Scans oft alle paar Stunden durch. Teams mit weniger Aktivität führen sie vielleicht einmal täglich aus. Der Schlüssel ist Konsistenz: Der Scan muss automatisch und ohne menschliches Eingreifen laufen.

Sie können Scans mit einem Cron-Job auf Ihrem CI/CD-Server, einem geplanten Pipeline-Trigger oder einem integrierten Planer Ihres IaC-Tools planen. Wichtig ist, dass der Zeitplan zuverlässig ist und nicht davon abhängt, dass jemand daran denkt, ihn auszuführen.

Wenn Drift erkannt wird, ist der nächste Schritt die Benachrichtigung. Automatisierte Alarme sollten an den Kommunikationskanal Ihres Teams gehen, sei es Slack, E-Mail oder ein Ticketsystem. Eine gute Benachrichtigung enthält drei Dinge: welche Ressource abgewichen ist, was sich geändert hat und wann es erkannt wurde. Wenn Ihr Cloud-Anbieter protokolliert, wer die Änderung vorgenommen hat, fügen Sie auch diese Information hinzu. Das beschleunigt die Untersuchung erheblich.

Was nach der Erkennung passiert

Drift zu finden ist nur der erste Schritt. Sobald Sie wissen, dass er existiert, haben Sie zwei Optionen.

Die erste Option ist der Abgleich: Bringen Sie die Ressource zurück in den in Ihrem Code definierten Zustand. Dies ist die Standardreaktion der meisten Teams. Sie führen terraform apply oder Ihr Äquivalent aus, und das Tool macht die manuelle Änderung rückgängig. Das funktioniert gut, wenn der Drift versehentlich oder unbefugt war.

Die zweite Option ist die Akzeptanz: Die manuelle Änderung war beabsichtigt und soll bestehen bleiben. In diesem Fall aktualisieren Sie Ihren IaC-Code, um ihn an den tatsächlichen Zustand anzupassen. Dies ist die richtige Wahl, wenn die Änderung eine legitime schnelle Korrektur in der Konsole war und der Code aufholen muss. Die Gefahr ist, dass Ihr Code aufhört, die Quelle der Wahrheit zu sein, und stattdessen zu einer historischen Aufzeichnung wird, wenn Sie dies zu oft tun.

Die Entscheidung zwischen Abgleich und Akzeptanz hängt von der Richtlinie Ihres Teams ab. Manche Teams gleichen immer ab, es sei denn, es gibt eine dokumentierte Ausnahme. Andere erlauben Akzeptanz, verlangen aber einen nachfolgenden Pull-Request innerhalb eines definierten Zeitrahmens. Wichtig ist, dass die Entscheidung bewusst und nicht zufällig getroffen wird.

Praktische Checkliste für die automatisierte Drift-Erkennung

Wenn Sie die Drift-Erkennung zum ersten Mal einrichten, finden Sie hier eine kurze Checkliste für den Einstieg:

  • Wählen Sie Ihr Erkennungstool: Nutzen Sie die integrierte Drift-Erkennung Ihres vorhandenen IaC-Tools oder ein dediziertes Tool wie Terraform Cloud, OpenTofu oder ein benutzerdefiniertes Skript, das regelmäßig einen Plan ausführt.
  • Legen Sie einen Scan-Zeitplan fest: Beginnen Sie mit einmal täglich für nicht-kritische Umgebungen und alle paar Stunden für die Produktion. Passen Sie ihn an, je nachdem, wie oft manuelle Änderungen vorkommen.
  • Konfigurieren Sie Benachrichtigungen: Senden Sie Alarme an Ihren Team-Chat oder Ihr Ticketsystem. Fügen Sie den Ressourcennamen, die spezifische Änderung und den Zeitstempel hinzu.
  • Definieren Sie eine Reaktionsrichtlinie: Entscheiden Sie, ob Sie Drift abgleichen oder akzeptieren. Dokumentieren Sie den Prozess, damit alle im Team dem gleichen Ansatz folgen.
  • Testen Sie den Prozess: Führen Sie eine absichtliche manuelle Änderung in einer Staging-Umgebung durch, lassen Sie den Scan sie erkennen und überprüfen Sie, ob Benachrichtigung und Reaktion wie erwartet funktionieren.

Die konkrete Erkenntnis

Infrastruktur-Drift ist kein Zeichen für ein schlechtes Team. Es ist ein Zeichen dafür, dass Ihr Team schnell arbeitet und gelegentlich Abkürzungen nimmt. Das Problem ist nicht die Abkürzung selbst. Das Problem ist, nichts davon zu wissen, bis es einen Incident verursacht.

Automatisierte Drift-Erkennung macht aus einem unsichtbaren Problem ein sichtbares. Sie verhindert nicht, dass Leute Änderungen in der Konsole vornehmen. Sie stellt sicher, dass der Rest des Teams, wenn sie es tun, schnell davon erfährt und entscheiden kann, was als Nächstes zu tun ist. Diese Sichtbarkeit ist es, die Ihre Infrastruktur zuverlässig hält – selbst wenn Code und Cloud sich nicht einig sind.