Terraform oder OpenTofu: Was die Lizenzänderung für dein Unternehmen bedeutet

Die Business Source License 1.1 ist keine Open-Source-Lizenz, aber auch keine übliche proprietäre Lizenz. Der Quelltext bleibt einsehbar, die Nutzung ist erlaubt, und jede Version wechselt zum festgelegten Change Date automatisch auf die Mozilla Public License 2.0. Entscheidend ist der Additional Use Grant: Untersagt ist der produktive Einsatz nur dann, wenn ihr das Werkzeug Dritten in einer Form bereitstellt, die mit den Produkten des Rechteinhabers konkurriert. Für die Frage, ob euer Haus betroffen ist, brauchst du also keinen Blick in den Code, sondern in euer Geschäftsmodell.

Halte das Ergebnis schriftlich fest, mit Datum und geprüfter Lizenzfassung. Ohne dieses Dokument beginnt die Diskussion beim nächsten Audit und beim nächsten Lieferantenfragebogen von vorn. Steht ohnehin eine grundsätzliche Werkzeugwahl an, gehört sie in denselben Vorgang wie der Vergleich der Werkzeuge für Infrastructure as Code.

Das bekannteste Beispiel ist der State. Er enthält Zugangsdaten im Klartext, sobald eine Ressource welche erzeugt, etwa ein Datenbankpasswort oder einen Zugriffsschlüssel. Ein verschlüsselter Bucket schützt nur gegen den Verlust des Buckets, nicht gegen jeden im Haus, der Leserechte darauf hat. OpenTofu löst das mit clientseitiger Verschlüsselung des State. Terraform geht den anderen Weg und sorgt mit ephemeren Werten und Write-only-Argumenten dafür, dass sensible Werte gar nicht erst im State landen. Beide Ansätze funktionieren, verlangen aber unterschiedliche Umbauten am Code.

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "standard" {
      keys = key_provider.pbkdf2.passphrase
    }

    state {
      method   = method.aes_gcm.standard
      enforced = true
    }
  }
}

enforced = true sorgt dafür, dass ein unverschlüsselter Stand gar nicht erst geschrieben wird. Ohne dieses Flag akzeptiert OpenTofu weiterhin Klartext, was für die Umstellungsphase gedacht ist und danach gerne vergessen wird. In der Produktion nimmst du statt pbkdf2 einen Schlüssel aus AWS KMS oder Azure Key Vault, damit die Passphrase nicht im Repository landet.

Wichtig ist die Reihenfolge: Erst prüfen, welche dieser Funktionen ihr wirklich braucht, dann entscheiden. Ein Team, das seine Geheimnisse ohnehin über einen externen Tresor bezieht und niemals im State ablegt, gewinnt durch die State-Verschlüsselung wenig. Ein Team, das für eine Behörde in einem Netz ohne Internetzugang arbeitet, gewinnt durch den OCI-Bezug sehr viel. Die Frage nach dem größeren Ökosystem beantwortet ihr an eurer Pipeline, nicht an einer Featureliste.

# 1. State sichern, bevor irgendetwas anderes passiert
terraform state pull > state-$(date +%F).json
sha256sum state-*.json | tee state-pruefsummen.txt

# 2. OpenTofu installieren, Installationsskript vorher lesen
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
less install-opentofu.sh
chmod +x install-opentofu.sh
./install-opentofu.sh --install-method deb

# 3. Initialisieren und den Ist-Zustand vergleichen
tofu init -upgrade
tofu plan -detailed-exitcode -out=tofu.plan
echo "Exitcode: $?"

Der interessante Wert ist der Exitcode: 0 bedeutet keine Abweichung, 2 bedeutet geplante Änderungen, 1 bedeutet Fehler. Eine 0 ist dein Abnahmekriterium. Eine 2 heißt nicht automatisch, dass etwas kaputt ist, sondern meist, dass unterschiedliche Provider-Versionen gezogen wurden. Vergleiche dann zuerst die .terraform.lock.hcl.

Plane den Testlauf so, dass ein apply zunächst gar nicht vorgesehen ist. Erst wenn mehrere Stacks nacheinander einen leeren Plan liefern, nimmst du den ersten unkritischen Stack produktiv unter OpenTofu. Alles andere bleibt vorerst bei Terraform. Ein Parallelbetrieb über einige Wochen ist ausdrücklich möglich, weil beide Werkzeuge dasselbe State-Format lesen, und er ist deutlich billiger als ein Stichtag, an dem alles gleichzeitig kippt.

Terraform und OpenTofu nutzen getrennte Registries. Die Provider selbst sind davon meist unberührt, sie stehen üblicherweise unter MPL 2.0 oder Apache 2.0 und laufen in beiden Werkzeugen. Was sich ändert, ist der Bezugsweg. In regulierten Umgebungen solltest du den ohnehin nicht dem Internet überlassen, sondern die Artefakte spiegeln, so wie es auch Cluster ohne Internetzugang tun. Ein lokaler Spiegel macht Läufe reproduzierbar, überlebt Ausfälle der öffentlichen Registry und nimmt der ganzen Registry-Frage einen Großteil ihrer Brisanz.

# Alle im Projekt referenzierten Provider in ein Verzeichnis holen
tofu providers mirror /srv/tofu/provider-mirror

# Ergebnis pruefen: je Provider ein Verzeichnis mit Versionen und Pruefsummen
find /srv/tofu/provider-mirror -maxdepth 4 -type d | head -n 20

# Welche Provider haengen ueberhaupt am Projekt?
tofu providers

Der Spiegel gehört auf ein Volume, das gesichert wird, nicht in ein Home-Verzeichnis auf einem Build-Knoten. Bei Terraform heißt derselbe Befehl terraform providers mirror und legt dieselbe Verzeichnisstruktur an.

provider_installation {
  filesystem_mirror {
    path    = "/srv/tofu/provider-mirror"
    include = ["registry.opentofu.org/*/*"]
  }

  direct {
    exclude = ["registry.opentofu.org/*/*"]
  }
}

Damit greift kein Lauf mehr ins Internet, solange der gesuchte Provider im Spiegel liegt. Für Terraform gilt dieselbe Syntax in ~/.terraformrc, nur mit registry.terraform.io als Host. Ein fehlender Provider fällt dann sofort beim init auf und nicht erst nachts in der Pipeline.

variables:
  TOFU_VERSION: "1.9.0"   # exakte Version, niemals latest

plan:
  image: ghcr.io/opentofu/opentofu:$TOFU_VERSION
  script:
    - tofu init -input=false -lockfile=readonly
    - tofu plan -input=false -detailed-exitcode -out=tofu.plan || rc=$?
    - test "${rc:-0}" -ne 1   # 1 waere ein echter Fehler, 2 sind Aenderungen
  artifacts:
    paths: [tofu.plan]
    expire_in: 1 week

-lockfile=readonly verhindert, dass ein Lauf die Provider-Versionen still nachzieht. Achte auf die Auswertung des Exitcodes: GitLab wertet jeden Wert ungleich null als Fehler, und -detailed-exitcode liefert bei geplanten Änderungen eine 2. Ohne die Abfrage oben ist jeder Plan mit Änderungen ein roter Job.