Configuration Drift

1. Vermeiden:

   • Niemals SSH! Verbiete manuelle Logins.
   • Nutze Infrastructure as Code (IaC): Terraform oder Ansible. Wenn du etwas ändern willst, änderst du den Code (git commit) und lässt das Tool laufen.

2. Erkennen:

   • Terraform: terraform plan. Es zeigt: "Hey, jemand hat den Security Group Port 22 geöffnet. Ich werde das rückgängig machen."
   • Puppet/Chef: Läuft alle 30 Minuten und erzwingt den Soll-Zustand ("Enforcement").

1. Immutable Infrastructure

Die radikalste Lösung gegen Drift. Du reparierst Server nicht. Du tötest sie. Wenn du Nginx updaten willst, patchst du nicht den alten Server. Du baust ein neues Image (AMI / Docker Image), startest neue Server und löschst die alten. Da niemand auf den Servern lebt, gibt es keinen Drift ("Cattle vs. Pets"). Drift kann physikalisch dort (fast) nicht entstehen.

2. GitOps (Kubernetes)

In K8s wird Drift-Erkennung automatisiert (z. B. ArgoCD). ArgoCD hat einen "Sync Status". Es vergleicht Git (Soll) mit dem Cluster (Ist). Wenn jemand manuell kubectl edit macht, springt ArgoCD auf "OutOfSync". Je nach Einstellung macht ArgoCD einen Auto-Heal (macht die manuelle Änderung sofort rückgängig). Der Admin "kämpft" gegen den Bot – und der Bot gewinnt immer. Das erzwingt Disziplin.

3. Entropy is inevitable

Selbst ohne Menschen gibt es Drift.

• Logfiles füllen die Platte.
• Caches wachsen.
• Temp-Dateien häufen sich. Deshalb ist "Re-Paving" (Server regelmäßig neu aufsetzen) wichtig, auch ohne Code-Änderungen.

State File Divergence (Terraform)

Während "Drift" oft Serverkonfiguration meint, ist der Drift bei Cloud-Ressourcen (VPCs, S3-Buckets) noch gefährlicher. Terraform unterhält ein State File (terraform.tfstate). Drift tritt hier auf drei Ebenen auf:

1. Code vs. State: Ein Entwickler schrieb Code, ließ ihn aber nicht zwingend anwenden.
2. State vs. Realität: Ein Cloud-Admin hat in der AWS-Konsole "nur mal kurz" die S3-Bucket-Policy geändert. Terraform's State weiß davon nichts. Erst beim Ausführen von terraform plan holt Terraform den aktuellen Live-Zustand (Refresh-Phase) der Cloud-API ein, rechnet die Differenz zum Code aus und plant das Überschreiben der unautorisierten manuellen Änderung. Diese Drift-Detection ist essenziell für Security Audits.

Drift Remediation Frameworks (Continuous Reconciliation)

Wie geht man mit erkanntem Drift um?

• Alerting: Tools wie Terraform Cloud oder Spacelift führen nachts automatische "Drift Detection Runs" aus. Sie wenden nichts an, sondern schlagen Alarm (Slack/PagerDuty), falls der Plan ungleich Null ist.
• Auto-Remediation: Kubernetes-Controller (wie Fleet, Flux oder Crossplane) nutzen Loops. Sie validieren den Zustand alle paar Sekunden und patchen Abweichungen ohne Zögern zurück (Reconciliation Loop). Ein manuelles kubectl edit verschwindet Sekundenbruchteile später wieder. Dies ist in Produktions-Clustern die einzig skalierbare Antwort auf Drift.

Muta​​bility Window (Ansible vs. Packer)

In traditionellen Rechenzentren lässt Ansible viel Raum für Drift, da es Konfigurationen mutiert (verändert). Wenn ein Playbook sagt state: present für Nginx, ignoriert es, wenn jemand heimlich Apache daneben installiert hat. Es löscht ihn nicht. Das ist "Partial State Enforcement" (Drift in den Zwischenräumen). Der evolutionäre Upgrade dazu ist die Tool-Kette Packer -> Terraform. Packer baut eine "Golden Image" VM, auf der das System absolut final gebacken ist (Read Only, Immutable). Terraform wirft alte VMs dann weg und deployt das Image. Hier gibt es keine Zwischenräume für Dritt-Software.