Terraform Best Practices für produktive Umgebungen

Terraform ist schnell aufgesetzt — und genauso schnell unwartbar. Was im ersten Projekt als einzelne main.tf beginnt, wächst nach zwei Jahren zu einem State, den niemand mehr anzufassen wagt. Die folgenden Praktiken haben sich in unseren Kundenprojekten bewährt.

Remote State von Anfang an

Lokaler State ist ein Single Point of Failure: Er liegt auf genau einem Laptop, kennt kein Locking und landet im schlimmsten Fall im Git-Repository. Nutzen Sie einen Remote Backend mit State Locking — S3 mit DynamoDB, Azure Blob Storage oder ein STACKIT Object-Storage-Bucket.

terraform {
  required_version = "~> 1.9"

  backend "s3" {
    bucket         = "acme-tfstate-prod"
    key            = "platform/network/terraform.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Ein Key-Schema wie <projekt>/<domäne>/terraform.tfstate hält die States getrennt. Ein State pro Umgebung und Domäne — nicht einer für alles.

Versionen pinnen

Ein terraform apply, das gestern funktionierte und heute die halbe Infrastruktur ersetzen will, hat meist eine Ursache: ein ungepinnter Provider.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Das Lockfile .terraform.lock.hcl gehört ins Repository — es ist die einzige Garantie, dass CI und Entwicklerrechner dieselben Provider-Versionen benutzen.

Kein Klartext im Code

Secrets gehören nicht in .tfvars und nicht in Variablen-Defaults. Ziehen Sie sie zur Laufzeit aus einem Secret-Store (Vault, AWS Secrets Manager, Azure Key Vault) und markieren Sie Ausgaben konsequent:

variable "db_password" {
  type      = string
  sensitive = true
}

Wichtig zu wissen: Auch sensitive-Werte stehen im Klartext im State. Der State ist damit selbst ein Secret — verschlüsselt ablegen, Zugriff eng begrenzen.

Plan im Pull Request

Der größte Hebel für Sicherheit ist organisatorisch, nicht technisch: Kein apply ohne gelesenen Plan. In der Pipeline läuft terraform plan bei jedem Pull Request und postet das Ergebnis als Kommentar. Das Review-Gespräch findet damit vor der Änderung statt, nicht danach.

terraform plan -out=tfplan
terraform show -no-color tfplan > plan.txt

Ergänzend lohnen sich statische Prüfungen: terraform fmt -check, terraform validate, dazu tflint und checkov oder trivy für Security-Regeln.

Was Terraform nicht ist

Terraform verwaltet Infrastruktur, nicht Konfiguration im Betriebssystem. Wer remote-exec-Provisioner einsetzt, um Software zu installieren, baut sich Zustände, die Terraform nicht mehr abbilden kann. Für die Ebene darüber gehören vorgefertigte Images (Packer) oder Konfigurationsmanagement dazu.

Kurzfassung

• Remote State mit Locking, getrennt nach Umgebung und Domäne
• Terraform- und Provider-Versionen pinnen, Lockfile committen
• Secrets aus dem Store, State als Secret behandeln
• Plan im Pull Request, Apply nur nach Review
• Linting und Policy-Checks in die Pipeline

Wir begleiten Unternehmen beim Aufbau solcher Setups — vom ersten Modul bis zur Pipeline. Sprechen Sie uns an.