# Terraform Testing & Validation: Qualitätssicherung für den Infrastruktur-Code

TL;DR / Management Summary Ein Fehler im Infrastruktur-Code kann das gesamte Rechenzentrum löschen. Wir nutzen Validation & Testing, um Fehler zu finden, bevor sie die Proxmox-API erreichen. Ein Senior Admin implementiert eine Test-Kette aus Linting (Syntax-Check), Security-Scans (Schwachstellen-Suche) und Policy-as-Code (Compliance-Prüfung). Ziel ist es, den “Blast Radius” von Fehlern zu minimieren und eine 100% konsistente Infrastruktur zu garantieren.

# 1. Statische Analyse (Linting)

Schönheit und Korrektheit.

Bevor Sie einen Plan erstellen, prüfen Sie die formale Korrektheit.

• terraform fmt: Bringt den Code in ein einheitliches Format.
• terraform validate: Prüft die interne Konsistenz (z.B. falsche Variablen-Referenzen).
• TFLint: Ein spezialisierter Linter, der auch provider-spezifische Fehler findet (z.B. “Ungültiger Instanz-Typ in AWS”).

# 2. Security Scans & Compliance

Schwachstellen im Code finden.

Nutzen Sie Tools, die Ihren Terraform-Plan gegen Best-Practice-Kataloge (CIS, NIST) prüfen.

1. Checkov: Scannt Ihren Code auf offene Sicherheitslücken (z.B. “Root-Login via SSH erlaubt”, “S3 Bucket nicht verschlüsselt”).
2. tfsec: Spezialisiert auf die Identifizierung von Risiken in Public-Cloud Providern.

# 3. Deep Dive: Policy as Code (Sentinel / OPA)

Die Leitplanken für die Cloud.

Verhindern Sie, dass Admins zu teure oder unsichere Ressourcen erstellen.

• HashiCorp Sentinel: Erlaubt logische Regeln.
• Beispiel: IF vm_memory > 128GB THEN deny_apply.
• Vorteil: Die Compliance wird bereits in der CI/CD Pipeline (Artikel 785) erzwungen, noch bevor der Administrator den Befehl ausführen kann.

# 4. Day-2 Operations: Unit Testing (Terratest)

Funktioniert das Ergebnis?

Mit Terratest (Go-basiert) können Sie echte End-to-End Tests schreiben.

• Workflow:
  1. Terraform erstellt eine temporäre VM.
  2. Ein Go-Script prüft: “Ist Port 80 wirklich erreichbar? Antwortet der Webserver?”.
  3. Wenn alle Tests PASS liefern, wird die Infrastruktur wieder gelöscht.
• Nutzen: Perfekt für die Validierung von komplexen Modulen (Artikel 790).

# 5. Troubleshooting & “War Stories”

Wenn der Test ‘Grün’ zeigt, aber die Welt ‘Rot’ ist.

# Top 3 Fehlerbilder

1. Symptom: terraform validate ist erfolgreich, aber apply schlägt fehl.

   • Ursache: Dynamische Fehler, die erst zur Laufzeit auftreten (z.B. IP-Adresse bereits vergeben).
   • Lösung: Nutzen Sie Pre-Apply Scripts zur Validierung externer Ressourcen.

2. Symptom: Security-Scans liefern hunderte Fehlalarme.

   • Lösung: Pflegen Sie eine Ausnahmeliste (.checkov.yml) für bewusste Abweichungen.

3. Symptom: Pipeline dauert ewig durch zu viele Tests.

# “War Story”: Der “Auto-Approve” GAU

Ein Admin übersprang den terraform plan Schritt in seiner Pipeline und nutzte stattdessen apply -auto-approve, um Zeit zu sparen. Das Ereignis: Durch eine Änderung in einem Modul wollte Terraform die gesamte produktive Datenbank löschen und neu erstellen (Recreation). Das Ergebnis: Ohne manuelle Validierung oder Policy-Check (Sentinel) löschte Terraform das System. Lehre: Automatisierung braucht Guardrails. Erzwingen Sie einen terraform plan und nutzen Sie Tools wie Infracost, um die Kostenänderung vor jedem Apply als Teil der Verifizierung anzuzeigen.

# 6. Monitoring & Reporting

Qualitäts-KPIs.

# Code Coverage Dashboard

Überwachen Sie Ihre Infrastruktur-Repositorys:

• Number of Linting Errors.
• Open Security Findings.
• Policy Violation Rate.

# 7. Fazit & Empfehlung

Testing ist der Unterschied zwischen “Basteln” und “Engineering”.

• Empfehlung: Integrieren Sie Checkov und TFLint in Ihre Git-Pre-Commit-Hooks. So wird fehlerhafter Code gar nicht erst eingecheckt.
• Wichtig: Nutzen Sie die Vorschau-Funktion (Plan) als heiliges Gesetz. Kein Apply ohne vorherigen Plan-Review!

# Anhang: Cheatsheet (Testing Tools)

# Referenzen

• Terratest: Official Documentation
• Checkov: Infrastructure as Code Security
• HashiCorp: Sentinel Policy as Code Framework