Open-Source-Tools zum Testen von Terraform-Code

Hinweis der Redaktion: Dieser Beitrag erschien ursprünglich auf CloudSkiff.com. CloudSkiff ist im Oktober 2021 zu Snyk gekommen.

Das Testen von Terraform-Code ist ein wiederkehrendes Thema, das uns immer wieder begegnet. Viele beschäftigen sich mit dem Testen von Infrastructure-as-Code, auch wenn Tests in der Praxis noch nicht weit verbreitet sind. Zunächst einmal: Sollten Sie Ihren Code testen? Welche Strategien gibt es, um Tests zu automatisieren, und welche Open-Source-Tools eignen sich dafür am besten?

Terraform-Code zu testen ist entscheidend – und ja, Sie sollten ihn testen. Dafür gibt es viele Möglichkeiten. Das Vorgehen ähnelt den üblichen Softwareentwicklungsprozessen. Es stammt aus derselben Kultur, daher ist das keine Überraschung.

Terraform-Code testen: Beginnen Sie mit Lintern

Linter können Sie direkt auf Ihrem Laptop oder in Ihrem CI/CD-System ausführen. So stellen Sie sicher, dass sich andere an bestimmte Programmierkonventionen oder Standards halten.

Ein Terraform-Linter, den ich wirklich mag, heißt TFLint. Er ist Open Source und auf Github verfügbar. Es ist ein Linter „für die Infrastruktur“, das heißt, er prüft Ihren Code auf eine Weise, die terraform validate nicht abdeckt. terraform validate ist ein Unterbefehl in Terraform. Im Grunde prüft er nur, ob die Struktur gültig ist, nicht aber, ob die Inhalte korrekt sind. Wenn Sie beispielsweise einen ungültigen AWS-Maschinentyp anfordern, erkennt terraform validate das nicht als Fehler – TFLint hingegen schon.

So würde ein fehlerhafter Commit aussehen:

Und so würde der Fehler erkannt und in Ihren Logs angezeigt:

Dieser Linter bietet auch eine Funktion für „Deep Linting“, die über einfache Prüfungen hinausgeht.

Angenommen, Sie möchten eine vorhandene, geeignete VM anfordern, zum Beispiel eine T3-large-Instanz. Wenn Ihr Konto keine weiteren Kapazitäten zulässt (etwa weil Sie bereits alle VMs gestartet haben, die Sie anfordern durften), sendet der Linter eine Anfrage an die AWS-API. So prüft er nicht nur, ob Ihre Anforderung korrekt ist, sondern auch, ob sie innerhalb Ihrer Kontolimits ausgeführt werden kann. Er erledigt alles, was ein guter Linter während der Entwicklung tun sollte – etwa Qualitäts- und Tabulatorprüfungen – und geht über den Validator und Formatter hinaus, die direkt in Terraform verfügbar sind.

Ein typischer Anwendungsfall: Sie haben alle Tests in einer Staging-Umgebung durchgeführt. Die AWS-Limits dieser Umgebung sind sehr hoch, weil Sie im Laufe der Zeit Dutzende von Anfragen gestellt haben, wann immer Sie etwas testen mussten. Möglicherweise sind daher in jeder Region Hunderte oder sogar Tausende von Instanzen zugelassen.

Dann entscheiden Sie sich, eine neue Änderung in der Produktion bereitzustellen. Vielleicht gelten dort jedoch andere Regeln oder andere AWS-Kontolimits. Dann stellen Sie etwas bereit, das in Ihrer Produktionsumgebung nicht funktioniert.

Der Deep Linter stellt sicher, dass sich das, was Sie aus Staging, der Entwicklungsumgebung oder einer beliebigen anderen Umgebung in die Produktion überführen oder dort starten möchten, tatsächlich mit den Berechtigungen Ihres Kontos ausführen lässt.

Führen Sie mit TDD Unit-Tests für Ihren Terraform-Code durch‹

Ein geeigneter agiler Entwicklungsworkflow beginnt mit testgetriebener Entwicklung (TDD).

Wenn Sie mit TDD beginnen, schreiben Sie Unit-Tests, zum Beispiel: „Ich möchte meine VPC erstellen, und sie soll über diesen Adressraum verfügen.“ Als Nächstes schreiben Sie Ihre Funktion (in Terraform heißt sie Ressource) und führen sie aus. Wie wir später sehen werden, würde ich dafür eines der RSpec-abgeleiteten Tools verwenden: Serverspec, InSpec … Ihre TDD-Schritte könnten etwa so aussehen:

Schreiben Sie zuerst Ihren Test: Er schlägt fehl

Schreiben Sie die Ressource. Der Test schlägt nicht fehl, weil sie in einer isolierten Umgebung gestartet wird – insbesondere die VPC.

Bei diesem Prozess testen Sie, was Sie testen möchten, und entfernen es anschließend wieder. Sie können genauso vorgehen wie in der Softwareentwicklung, etwa in Ihrer CI: Führen Sie alle Tests für Pull Requests aus. Übrigens ist es ein heikles Thema, wie viele Sicherheitstests Sie durchführen möchten, wenn Sie mit dem Testen beginnen. Ich führe persönlich alle Tests aus, bevor ich etwas zusammenführe. Während der Pull-Request-Phase bin ich jedoch weniger streng, denn alle Tests ständig bei jedem Commit auszuführen, kann sehr lange dauern.

Führen Sie Integrationstests durch

Eine weitere Möglichkeit, die in QA-Prozessen recht verbreitet ist: Variablen und andere Werte nach dem Zufallsprinzip festlegen. Terratest ist ein weiteres wirklich hilfreiches Tool für Integrationstests. Es ist wahrscheinlich das umfassendste, aber auch das komplexeste.

Sehen wir es uns genauer an.

Terratest ist eine Go-Bibliothek. Um sie zu beherrschen, benötigen Sie entsprechende Kenntnisse (schließlich ist es Go …). Dafür können Sie alles testen, was über eine API verfügt, etwa AWS, Azure, Google Cloud, Kubernetes, Docker-Images, Packer-Builds … (Packer ist das Tool von HashiCorp zum Erstellen von AMIs: Festplatten-Images virtueller Maschinen) und sogar Helm-Charts.

Im Grunde müssen Sie nur den Namen Ihrer resource_test.go-Datei erstellen, Ihre Bibliotheken importieren und den Test ausführen. Dafür benötigen Sie jedoch gewisse Go-Kenntnisse und ein tiefes Verständnis dessen, was Sie testen möchten.

Werte nach dem Zufallsprinzip festlegen

In dieser Integrationsphase würde ich Werte wie Regionsnamen nach dem Zufallsprinzip festlegen. Normalerweise testen Sie Ihren Code immer in derselben Region. Wenn Sie den Wert variieren, erhalten Sie unterschiedliche Ergebnisse und stellen sicher, dass alles funktioniert.

Vielleicht sind Ihre Namen eindeutig, und auch die Namen Ihrer Ressourcen müssen es sein. So muss beispielsweise Ihr Amazon-S3-Bucket einen eindeutigen Namen haben. Das Vorgehen entspricht dem eines Softwareentwicklungsprojekts:

Verwenden Sie die Tools

• Prüfen Sie Ihren Code mit einem Linter

• Führen Sie Unit-Tests für Ihre Dateien aus

• Variieren Sie die Werte nach dem Zufallsprinzip

• Integrieren Sie die Ergebnisse in Ihre CI

• Fügen Sie die Tests zu Ihren Pull Requests hinzu

• Kennzeichnen Sie Ihren Code und Ihre Releases (z. B. master)

• Verwenden Sie Feature-Branches, führen Sie sie anschließend in master zusammen und veröffentlichen Sie dann eine Codeversion

Weitere Tools, die wir zum Testen Ihres Infrastructure-as-Code empfehlen

Ich habe die RSpec-abgeleiteten Tools dafür erwähnt: Serverspec, InSpec … InSpec stammt von Chef, während Serverspec meines Erachtens stärker von der Community getragen wird.

Serverspec eignet sich für Unit-Tests, ist aber nicht nur auf Terraform beschränkt, sondern allgemeiner einsetzbar. Sie können damit alles testen – von Infrastruktur und Docker-Images bis hin zu Prozessen, die auf einem Server laufen, und Ähnlichem. Die Tests sind gut lesbar und kommen dem Englischen nahe. Das Tool ist sehr vielseitig, weil es nicht direkt den Code testet oder direkt dem Terraform-Code in Ihrem Infrastruktur-Repository entspricht. Stattdessen prüft es, was tatsächlich gestartet wurde. Wenn Sie beispielsweise eine neue Funktion hinzufügen, etwa eine Datenbank in Google Cloud, und sicherstellen möchten, dass Port „5.4.3.2“ offen ist, können Sie diesen Test einfach schreiben und ausführen. So können Sie dauerhaft sicherstellen, dass an diesem Port etwas antwortet. Mit Serverspec geht das schnell und einfach.

Ein weiteres Tool, das ich wirklich mag, heißt GOSS. Es ist Open Source und wirklich großartig. Das einfache Tool basiert auf YAML. Es ist nicht dafür gedacht, Terraform-Code zu testen, sondern vielmehr die Ergebnisse. Angenommen, Sie haben eine Sicherheitsgruppe erstellt und möchten sicherstellen, dass Port 22 für SSH geschlossen ist. Das können Sie ebenso prüfen wie Prozesse, Pakete, DNS-Resolver und Benutzer … oder ob Ihr HTTP-Endpunkt in Kubernetes antwortet – und Ähnliches.

Meines Wissens kann das Tool Testergebnisse sogar in einem Nagios-kompatiblen Format ausgeben. Damit können Sie es als /health-Endpunkt in Ihrem Microservice ausführen und sicherstellen, dass alles ordnungsgemäß funktioniert. Es ist wirklich einfach und leichtgewichtig. Ich mag dieses Tool sehr. Es funktioniert auch mit Docker-Dateien und vielem mehr …

Ihren Terraform-Code testen

GOSS eignet sich für sehr einfache Prüfungen auf hoher Ebene: mit unkompliziertem YAML und einer einfachen Binärdatei – ganz unkompliziert. Serverspec und InSpec sind für alle Unit-Tests geeignet und vollständig Open Source.

Und natürlich Terratest für Integrationstests. Das Tool ist sehr umfassend. Integrieren Sie all das in Ihr CI/CD-System oder führen Sie die Tests zumindest vor der Veröffentlichung oder Bereitstellung aus. Andernfalls werden Sie Probleme bekommen, oder?

Um Ihren Terraform-Code auf Sicherheitslücken zu prüfen, kann Snyk IaC Ihre Terraform-Konfigurationen (sowie Kubernetes-, CloudFormation- und ARM-Vorlagen) während der Entwicklung scannen und Sie mit gezielten Korrekturvorschlägen dabei unterstützen, Änderungen zusammenzuführen und weiterzuarbeiten. Testen Sie Ihren Code während des Schreibens, überwachen Sie Änderungen in Ihren Git-Repositories und automatisieren Sie Tests in Ihren Build-Pipelines vor der Bereitstellung. Die Einrichtung eines kostenlosen Plans dauert nur wenige Minuten. Eine Sicherheitsverletzung aufgrund einer IaC-Fehlkonfiguration kann jedoch lebenslange Folgen haben. Registrieren Sie sich und sichern Sie Ihre Konfigurationen noch heute.