Terraform Configuration Drift (automatisch) erkennen

Intro

Seit einigen Jahren wird Infrastruktur als Code beschrieben. Eines der größeren Produkte in diesem Feld ist terraform von Hashicorp bzw. dessen Fork opentofu.

Wenn es Unterschiede zwischen dem tatsächlichen und dem gewünschten Zustand (Desired State) gibt, wird von einem Configuration Drift gesprochen. Dieser sollte vermieden werden, weil sich die Infrastrukur dadurch (z.B. in einem Notfall) nicht mehr komplett durch terraform erzeugen lässt.

Configuration Drift bewusst zulassen

Einzelne Einstellungen (z.B. Tags einer Ressource, die Kubernetes Version eines Clusters oder SSL Zertifikate von einem Application Gateway) können in dem Terraform Projekt mittels ignore_changes von der Prüfung ausgeschlossen werden. Ob und bei welchen Details dieses Feature genutzt wird, hängt von dem jeweiligen Projekt und dem betreuendem Team ab.

Configuration Drift erkennen

Um einen Configuration Drift mittels Azure Devops festzustellen, kann folgende Pipeline genutzt werden. Diese wird täglich um 6 Uhr morgens und für Pull Requests ausgeführt.

Das Terraform Projekt wird initialisiert und validiert. Anschließend wird mit terraform plan geschaut, ob Änderungen zwischen dem Ist- und Sollzustand bestehen. Wenn ja, schlägt die Ausführung der Pipeline fehl. Die Pipeline kann in Azure Devops als Branch Policy hinterlegt werden, damit Änderungen am Branch develop nur nach einem erfolgreichen Run vorgenommen werden können.

Als sinnvoller nächster Schritt könnte das terraform plan die ermittelten Änderungen mittels -out=FILENAME in eine tfplan-Datei speichern. Diese Datei könnte als Buildartefakt des Pipeline Runs hinterlegt werden und außerdem von terraform apply genutzt werden, um die Änderungen durchzuführen.

Manuell angelegte Ressourcen finden

Mit dem folgenden PowerShell Script lassen sich Azure Ressourcen ausfindig zu machen, die nicht mit terraform erstellt wurden bzw. nicht von terraform verwaltet werden. Das kann z.B. bei einem Azure Storage sinnvoll sein, wenn darin der Terraform State gespeichert wird.

Wenn der Zustand in Ordnung ist, kann der aktuelle Stand als “accepted-drift.txt” gespeichert werden, damit bei einer zukünftigen Ausführung des Scripts erkannt werden kann, ob weitere Ressourcen ebenfalls nicht mit terraform verwaltet werden.

Alternativen

Terraform kann auch von GitOps Produkten wie ArgoCD oder flux genutzt werden. Dadurch werden Änderungen am git Repository automatisch geprüft und ggf. direkt übernommen. Für meine Projekte haben sich die in diesem Artikel gezeigten, einfachen Lösungen als ausreichend erwiesen, um einerseits einen Configuration Drift schnell zu erkennen und dem Projekt gleichzeitig relativ wenig Komplexität und Wartungsarbeit hinzuzufügen.