Effektiv in Terraform testen

Terraform ist eine Infrastructure-as-Code-Lösung (IaC), mit der DevOps-Teams Programmierkonzepte nutzen können, um Infrastrukturkomponenten automatisch On-Premises oder in einer Public Cloud bereitzustellen. Dazu können virtuelle Maschinen, Netzwerkkomponenten, Speicher, Anwendungen oder Datenbankdienste gehören.

Terraform bietet die HashiCorp Language (HCL). HCL ist eine einheitliche, domänenspezifische Sprache, die das Erstellen von Vorlagen für verschiedene Cloud-Anbieter vereinfacht, darunter Amazon AWS CloudFormation, Microsoft Azure ARM Templates und Bicep sowie Googles Cloud Deployment Manager für GCP.

So wie das Testen von Code ein wesentlicher Bestandteil der Softwareentwicklung ist, ist auch das Testen einer IaC-Lösung wie Terraform unverzichtbar. Richtig integriert kann IaC-Testing erhebliche Probleme bei der Ressourcenverwaltung mindern und DevOps-Teams dabei unterstützen, die Wirksamkeit von Konfigurationen zu überprüfen.

Die Integration dieser Tests in den DevOps-Prozess kann jedoch eine Herausforderung sein. Dabei stellen sich Fragen: Was sollten die Tests umfassen, worauf können sie verzichten und welche verfügbaren Mechanismen sind am wirksamsten? 

Terraform-Vorlagen lassen sich auf viele Arten testen. Am einfachsten geht es mit integrierten Terraform-Befehlen wie terraform validate oder terraform plan. Mit diesen Befehlen können wir Unit-, Integrations-, Compliance- oder End-to-End-Tests schreiben – ganz im Sinne herkömmlicher Testverfahren in der Softwareentwicklung. Alternativ können wir einen stärker entwicklerorientierten Ansatz verfolgen und mit dem Cloud Development Kit for Terraform (CDKTF) testen.

Letztlich müssen DevOps-Teams die Ziele des Validierungsprozesses klar festlegen. Dazu kann gehören, die Syntax der Vorlage zu überprüfen und sicherzustellen, dass sie erfolgreich bereitgestellt wird. Oder das Ziel besteht darin, ein wesentlich komplexeres Testszenario zu entwickeln: gezielt nach Sicherheitsproblemen oder Fehlkonfigurationen zu suchen und die Auswirkungen auf die Sicherheit bei Bereitstellungen zu erkennen. Entscheidend ist, genau festzustellen, was getestet werden muss, und anschließend die passende Kombination von Testlösungen zu finden.

Teststrategien für Terraform

Sehen wir uns einige verschiedene Teststrategien für Terraform an.

Drift-Tests

Terraform validiert Ihre aktuelle Infrastruktur anhand der terraform state-Datei. Bei jeder Terraform-Bereitstellung wird der Endzustand in einer State-Datei gespeichert, die üblicherweise an einem gemeinsam genutzten Speicherort liegt.

Wenn jedoch nicht alle Bereitstellungen in Ihrer Zielumgebung mit Terraform ausgelöst werden, kann eine Abweichung zwischen den „tatsächlichen“ Ressourcen und den Ressourcen entstehen, die laut Terraform State-Datei vorhanden sind. Betrifft eine solche Bereitstellung eine bereits von Terraform verwaltete Ressource, ist der integrierte Terraform-Befehl terraform plan hilfreich: Er kann Änderungen oder Abweichungen zwischen dem Umfang der State-Datei und der tatsächlichen Zielumgebung aufzeigen. Wird durch die Bereitstellung eine völlig neue Ressource erstellt, sind Tools wie driftctl und CloudQuery nützlich, da sie alle Ressourcen melden, die nicht von Terraform verwaltet werden.

Unit-Tests

Unit-Tests gehören zu den einfachsten Testarten. Dabei wird ein bestimmter, relativ grundlegender Test ausgeführt – in der Regel für ein einzelnes Objekt. Oft wird dabei überprüft, ob die Syntax der Vorlage korrekt ist.

Dafür können wir terraform validate verwenden. Bei einem Fehler in der Vorlagensyntax gibt terraform validate eine Fehlermeldung aus (auch wenn eine erfolgreich erkannte Syntax nicht zwangsläufig eine erfolgreiche Bereitstellung garantiert).

Um eine Bereitstellung zu validieren, können wir einen weiteren integrierten Befehl verwenden: terraform plan. Während der Planungsphase simuliert Terraform eine tatsächliche Bereitstellung, kommuniziert mit dem Backend des Anbieters und meldet das Ergebnis der Bereitstellung, die mit dem Befehl terraform apply ausgeführt wird.

Die Ausgabe von terraform plan hebt alle Änderungen hervor, die im Vergleich zur vorhandenen Umgebung erkannt wurden. Dazu können das Erstellen, Ändern oder Löschen von Ressourcen gehören. Anhand dieser Informationen kann unser DevOps-Team die Auswirkungen der Bereitstellung einschätzen, bevor es sie ausführt.

Im nächsten Schritt kommt Terraform apply zum Einsatz, um die eigentliche Bereitstellung auszuführen. Beachten Sie jedoch, dass diese Phase die Situation nicht immer vollständig abbildet. Wenn Sie eine Ressource aus Ihrer Terraform-HCL entfernen und anschließend terraform apply ausführen, wird die Ressource auf der IaaS gelöscht – denn obwohl sie nicht mehr in der HCL enthalten ist, steht sie noch im Terraform State, in dem sie bei der letzten erfolgreichen Bereitstellung gespeichert wurde. Terraform vergleicht den TF State mit der IaaS-API, stellt fest, dass die Ressource nicht mehr bereitgestellt werden soll, und löscht sie. Achten Sie daher weiterhin auf mögliche Abhängigkeiten oder Einschränkungen in Ihrer Umgebung. In Cloud-Szenarien wie AWS oder Azure wird dies üblicherweise durch Policy-Governance geregelt. 

Linting

Auch ein Linter ist hilfreich. Damit können DevOps-Teams Code auf Fehler, Bugs oder verdächtige Codeblöcke untersuchen. So lassen sich Syntaxprobleme erkennen, aber auch kritischere Anwendungsfälle abdecken, etwa das Aufspüren von Sicherheitsproblemen.

Es gibt mehrere Open-Source-Linter für Terraform, die unterschiedliche Analysemechanismen für verschiedene Zielplattformen bieten. GitHub stellt verschiedene Vorlagen bereit, die tflint für unterschiedliche Cloud-Anbieter verwenden.

Je nach Komplexität des Linting-Anwendungsfalls kann der Prozess als einfacher Unit-Test gelten oder Teil eines komplexeren, fortgeschrittenen Testszenarios sein. Erlaubt die Vorlage beispielsweise eine Bereitstellung virtueller Maschinen mit einer zugewiesenen öffentlichen IP-Adresse, kann die Linter-Validierung das IP-Adressobjekt erkennen und einen Fehler ausgeben. Der Linter kann außerdem fest codierte Passwörter oder Verbindungszeichenfolgen im Code erkennen.

Integrationstests

Selbst wenn jeder Unit-Test erfolgreich ist, garantiert die sequenzielle Ausführung aller Terraform-Pläne keinen Gesamterfolg. Deshalb sind Integrationstests unverzichtbar. Einfach gesagt bedeutet Integrationstesten, eine Kombination von Unit-Tests auszuführen. In Terraform beziehen sich Unit-Tests normalerweise auf ein einzelnes Modul, während Integrationstests mehrere Module mit umfangreichen Abhängigkeiten überprüfen.

Angenommen, wir haben zwei separate Terraform-Vorlagen: eine zum Erstellen eines virtuellen Netzwerks oder einer Virtual Private Cloud (VPC) und eine weitere zum Bereitstellen der Infrastruktur für virtuelle Maschinen. Wir könnten jede Vorlage einzeln als Unit-Test ausführen. Letztlich möchten wir jedoch die virtuellen Maschinen erfolgreich in den bereitgestellten Komponenten des virtuellen Netzwerks einsetzen. Wird eines der Module in einer anderen Region bereitgestellt, wäre der Unit-Test dennoch erfolgreich, der Integrationstest hingegen würde fehlschlagen.

Ein weiterer wichtiger Unterschied: Unit-Tests lassen sich offline ausführen, ohne etwas bereitzustellen. Integrationstests hingegen erfordern die Bereitstellung von Ressourcen, um Auswirkungen und Erfolg zu überprüfen.

Ein hilfreiches Tool für Integrationstests ist Terratest by Gruntwork. Es basiert auf dem Go-Sprachframework mit integrierter Pakettestfunktion und ermöglicht DevOps-Teams, dieselben Prinzipien auf IaC-Szenarien anzuwenden.

Compliance-Tests

Bei der Validierung von Terraform-Vorlagen müssen technische Bereitstellungen den Compliance-Vorgaben des Unternehmens entsprechen. Deshalb sind Compliance-Tests erforderlich. Dabei werden regionale Compliance-Standards, Namenskonventionen, Infrastrukturstandards wie bestimmte VM-Typen und die Sicherheit der Festplattenspeicherung überprüft.

In den meisten Fällen ist die Compliance-Validierung Teil der Konfiguration der Zielumgebung – oder sollte es sein – und umfasst die Integration von Azure Policies oder dem AWS Compliance Center. Diese Richtlinien werden jedoch erst bei einer tatsächlichen Bereitstellung überprüft. Entspricht die Bereitstellung den Compliance-Vorgaben nicht, schlägt sie fehl.

Durch die Integration von Compliance-Tests in den Terraform-DevOps-Prozess werden Tests vor der Bereitstellung ausgeführt und tragen so zu erfolgreichen Bereitstellungen bei. Eine Lösung ist Terraform-compliance, ein externes Tool, das überprüft, ob die Vorlagen einer Organisation den Compliance-Vorgaben entsprechen.

End-to-End-Tests

Letztlich versuchen DevOps-Teams, alle Testmethoden in einem einzigen Szenario zu kombinieren. Im Idealfall werden dabei alle Vorlagen getestet, alle Module bereitgestellt und Erfolg oder Fehlschlag überprüft.

Das klingt ideal, doch End-to-End-Tests bringen Herausforderungen mit sich. Ihre Dauer kann zum Engpass werden: Es kann deutlich länger dauern, bis Ergebnisse vorliegen, als bei schnell ausgeführten Unit-Tests, die sofort Ergebnisse liefern.

Unit-Tests mit CDKTF

Bisher gingen unsere Beispiele davon aus, dass wir für unsere Vorlagendateien die native HashiCorp Language verwenden. Terraform bietet mit dem CDKTF - Cloud Development Kit for Terraform jedoch auch einen stärker entwicklerorientierten IaC-Ansatz.

Mit CDKTF können DevOps-Teams Infrastruktur in jeder gängigen Programmiersprache bereitstellen, etwa Python, C#, Go oder Java. Alle Terraform-Provider und -Module sind mit diesem Kit kompatibel. Der größte Vorteil: Unser Team muss HCL nicht erlernen und kann vorhandene Kenntnisse in der jeweiligen Programmiersprache einsetzen.

CDKTF verwendet einen anderen Ansatz zum Schreiben von Vorlagen und Ausführen von Bereitstellungen. Deshalb funktionieren Unit-Tests anders. Aktuelle Dokumentation zu CDKTF-Tests finden Sie auf der Terraform-Website.

Snyk-Sicherheitstools

Das Testen Ihrer IaC ist entscheidend für den Zustand Ihrer Umgebung. Neben der Bewertung verschiedener Testmethoden ist es wichtig, auch die Sicherheitsaspekte des Testens hervorzuheben. Snyk bietet hilfreiche Tools:

• Snyk Infrastructure as Code unterstützt Sie dabei, Sicherheit in alle Aspekte der IaC-Entwicklung zu integrieren. Dafür werden Sicherheits-Code-Scans eingesetzt, ähnlich wie bei herkömmlichem Quellcode von Anwendungen.

• driftctl, das zuvor erwähnte Tool für Drift-Tests, wird von Snyk entwickelt und ist als Open-Source-Engine zur Drift-Erkennung verfügbar.

• Snyk IaC umfasst einen umfangreichen Satz vordefinierter, an Branchenstandards ausgerichteter Sicherheitsregeln, Best Practices von Cloud-Anbietern und die Bedrohungsmodellforschung von Snyk. Mit Snyk IaC können wir außerdem benutzerdefinierte Regeln erstellen – mithilfe des Open Policy Agent (OPA)-Frameworks und der Abfragesprache Rego.

Mehr über Sicherheit für Terraform erfahren

Das Testen von Vorlagen ist ein wesentlicher Bestandteil ihrer Erstellung. Neben den funktionalen Vorteilen trägt es dazu bei, die Sicherheit von Terraform-Bereitstellungen zu optimieren. Wenn Sie mehr darüber erfahren möchten, wie Sie Sicherheit in Ihre Terraform-Bereitstellungsvorlagen integrieren, sehen Sie sich Snyk an. Snyk bietet Tools zur Sicherheitsvalidierung für Ihre DevOps- und Automatisierungspipelines – einschließlich Terraform.