Die Verwaltung von Terraform-Infrastruktur wird dann besonders anspruchsvoll, wenn sie über mehrere Geschäftsbereiche oder sogar verschiedene Kundenorganisationen hinweg erfolgt.
In solchen Szenarien reicht es nicht mehr aus, einzelne Workspaces oder Pipelines lediglich technisch sauber aufzusetzen. Vielmehr brauchen Entscheider, CTOs, Architekten und Senior Engineers klar strukturierte Verantwortlichkeiten, strenge Governance und durchgängig automatisierte Prozesse, um Konsistenz, Sicherheit und Effizienz sicherzustellen. Wir haben diese Separierung von States bereits ausführlich behandelt, aber lassen Sie es uns abschließend noch einmal stichwortartig zusammenfassen.
Teamstrukturen und Verantwortlichkeiten
Die Übersicht über die gesamte Infrastruktur kann in optimalerweise mindestens drei Verantwortungsbereiche aufgeteilt werden:
Platform-Engineering-Team
Das Platform-Engineering-Team verwaltet die Root-Tenancies sowie sämtliche zentralen Cloud-Accounts und Compartments des Unternehmens und schafft damit den organisatorischen Rahmen für alle nachgelagerten Aktivitäten.
Darüber hinaus erstellt, versioniert und pflegt das Team die Basismodule, die von allen weiteren Teams genutzt werden, um eine einheitliche technische Grundlage sicherzustellen.
Gleichzeitig definiert es verbindliche Architekturrichtlinien, Tagging-Standards und Namenskonventionen – Regeln, die unternehmensweit für Konsistenz und Transparenz sorgen.
Abschließend betreibt und härtet das Platform-Engineering-Team das Terraform-Backend sowie die CI/CD-Plattform, um einen stabilen, skalierbaren und revisionssicheren Betrieb zu garantieren.
Service-Teams
Service-Teams greifen auf die bereitgestellten Basismodule zurück und entwickeln daraus domänen- oder produktspezifische Service-Module, die passgenau auf ihre Fachgebiete zugeschnitten sind.
Sie übernehmen die Verantwortung für die Infrastruktur ihrer Geschäftsbereiche und transformieren fachliche Anforderungen direkt in Infrastructure-as-Code-Artefakte.
Die benötigten Module beziehen sie komfortabel über eine Private Registry, Git-Submodule oder etablierte Paketmanager, was eine konsistente Versorgung mit aktuellen Versionen gewährleistet.
Applikations-Teams
Applikations-Teams provisionieren anwendungsspezifische Ressourcen auf Basis der Service-Module und können sich damit voll auf den Mehrwert ihrer Software konzentrieren.
Sie integrieren Infrastruktur und Code in durchgängige Deployment-Pipelines, sodass Releases reproduzierbar, auditierbar und automatisiert ablaufen.
Trotz hoher Autonomie verpflichten sie sich zur Einhaltung aller zentral definierten Richtlinien, um Sicherheit und Governance innerhalb der Gesamtplattform sicherzustellen.
Vertrauenszonen und State-Isolation
Jede Organisationsebene besitzt ihre eigene Vertrauenszone. Backend-Konfigurationen, IAM-Policies und CI/CD-Pipelines stellen sicher, dass Teams ausschließlich auf jene States zugreifen können, für die sie verantwortlich sind. So wird verhindert, dass beispielsweise ein Applikations-Team unbeabsichtigt Plattformressourcen verändert.
Governance und Compliance
Policy-as-Code
HashiCorp Sentinel oder Open Policy Agent ermöglichen die Durchsetzung verbindlicher Regeln als Code und schaffen damit eine automatisierte Kontrollinstanz im gesamten Lebenszyklus der Infrastruktur.
import "tfplan/v2" as tfplan
mandatory_tags = ["Owner","CostCenter","Environment"]
validate_instances = rule {
all tfplan.resource_changes as _, rc {
rc.type is "oci_core_instance" and rc.change.actions contains "create" implies
all mandatory_tags as tag { rc.change.after.defined_tags[tag] is not null }
}
}
main = rule { validate_instances }
Compliance-Automatisierung
Die automatische Generierung von Compliance-Dokumentation direkt aus Terraform-Outputs reduziert manuellen Aufwand und schafft jederzeit nachvollziehbare Prüfnachweise.
Ergänzend führen regelmäßige Scans der produktiven Infrastruktur einen kontinuierlichen Abgleich mit dem deklarierten Zustand durch und decken Abweichungen frühzeitig auf.
Multi-Account-Strategien
Separate Cloud-Accounts erhöhen die Isolation zwischen Tenants, erfordern jedoch ein diszipliniertes Credential-Management und angepasste CI/CD-Pipelines, damit Betrieb und Sicherheit nicht leiden. Benutzen Sie daher neben Terraform Workspaces auch Provider-Aliases wie hier demonstriert:
provider "oci" {
alias = "tenant_a"
tenancy_ocid = var.tenant_a_ocid
user_ocid = var.tenant_a_user_ocid
fingerprint = var.tenant_a_fingerprint
private_key_path = var.tenant_a_private_key_path
auth_type = "api_key"
region = var.tenant_a_region
}
provider "oci" {
alias = "tenant_b"
tenancy_ocid = var.tenant_b_ocid
auth_type = "api_key"
}
CI/CD-Integration
Ein robuster Pipeline-Workflow durchläuft grundsätzlich die Phasen Validation, Planning, Approval, Apply und Verification und bildet damit die Grundlage für reproduzierbare und auditierbare Deployments in Multi-Tenant-Umgebungen.
Dynamische Tenant-Konfiguration
Tenant-Informationen können dynamisch aus diversen Quellen ausgelesen werden. Das sind in der Regel vermutlich Datenbanken oder Directories, aber es kann sich auch um simple YAML-Konstrukte oder JSON handeln. Ein Beispiel:
tenants:
- name: customer_a
environment: production
region: eu-frankfurt-1
approval_required: true
- name: internal_test
environment: development
region: eu-amsterdam-1
approval_required: false
Beispiel-Job für Policy-Validierung (GitLab)
Falls Sie kein Sentinel einsetzen und stattdessen auf ein externes Tool vertrauen, können Sie ein solches einfach als zusätzlichen Schritt in die Pipeline integrieren, wie zum Beispiel das Python-Skript in diesem Beispiel:
validate_policies:
image: hashicorp/terraform:1.7
stage: validate
script:
- terraform init
- terraform plan -out=tfplan
- terraform show -json tfplan | gzip > tfplan.json.gz
- python scripts/validate_policies.py tfplan.json.gz
artifacts:
paths:
- tfplan.json.gz
Self-Service-Portale
Ein Self-Service-Portal mit kuratiertem Modul-Katalog erlaubt Fachabteilungen, standardisierte Infrastruktur mit wenigen Klicks zu bestellen, während im Hintergrund automatisierte CI/CD-Pipelines für eine kontrollierte Bereitstellung sorgen.
Wenn sie die Verwendung eines Self-Service-Portals obligatorisch machen, verbessert dies auch die gesamte Compliance des Unternehmens, denn nur das Portal selbst benötigt dann die Berechtigung zur Bereitstellung auf Ebene der Applikationsteams. Was das Self-Service-Portal nicht bereitstellt, kann dann auch nicht mehr implementiert werden, das Risiko von Schatten-IT wird damit noch verringert und Zero Trust wird leichter zu implementieren, da die Applikationsteams selbst dann keine vertrauenswürdige Organisation mehr sind. Auf diese Weise behandeln Sie dann ihre internen Endandwender wie Kunden.
Wichtige Features von Terraform Cloud und Enterprise
Für komplexe Infrastrukturen führt kein Weg an Terraform Cloud bzw. Terraform Enterprise vorbei. Falls Sie Wert auf die alleinige Datenhoheit legen, was innerhalb der Europäischen Union der Standard ist, oder regulatorischen Vorgaben zur Sicherheit unterliegen, ist hier dann Terraform Enterprise der einzige gangbare Weg.
Workspace-Management
Separate Workspaces pro Tenant, wie von Terraform Enterprise und Terraform Cloud unterstützt werden (nicht verwechseln mit dem CLI-Kommando terraform workspace der kostenlosen Variante von Terraform, denn das ist etwas völlig anderes), gewährleisten eine strikte Isolation und ermöglichen zugleich granulare Versions- und Freigabeprozesse je Mandant.
Tags und wiederverwendbare Variable Sets vereinfachen das Konfigurations-Management erheblich und reduzieren Dopplungen in großen Workspace-Landschaften.
Team- und Rechteverwaltung
Eine fein abgestufte Rollenmatrix unterscheidet pro Workspace zwischen Lese-, Schreib- und Genehmigungsrechten und unterstützt so eine saubere Trennung von Duties.
Die unkomplizierte SSO-Integration bindet Terraform Cloud oder Enterprise an das bestehende Unternehmens-Identitätssystem an und beschleunigt On- und Offboarding-Prozesse.
Run Triggers und Abhängigkeiten
Änderungen in einem zentralen Workspace können automatisch Plans in abhängigen Workspaces auslösen, sodass konsistente Upgrades über mehrere Ebenen hinweg sichergestellt sind.
Private Registry
Die Private Registry übernimmt die zentrale Versionierung sämtlicher Module, publiziert deren Dokumentation automatisch und schafft einen Single Point of Truth für wiederverwendbare Infrastruktur-Bausteine.
Kosten-Prognosen und Drift-Erkennung
Eine integrierte Kostenprognose liefert bereits vor dem Apply belastbare Schätzungen der Infrastrukturkosten pro Tenant und ermöglicht so eine präzise Budgetplanung. Cloud-Provider bieten hier in der Regel Hilfsmittel an, aber auch falls ein Cloud-Provider dies nicht nativ unterstützt, können Sie dies über selbstdefinierte Pricing-Tags realisieren. Die Werte dieser Tags können zum Beispiel aus Quellen wie CSV-Dateien oder einer Datenbank stammen. Wenn sich die Preise ändern, kann dies leicht in den Infrastrukturkomponenten aktualisiert werden, denn custom tags sind normalerweise updatefähig und nicht destruktiv. Die eigentliche Challenge liegt hier in volumenbasierten Tarifen wie Netzwerktraffic, also versteckten Kosten wie bei AWS üblich.
Parallel überwacht die Drift-Erkennung permanent Abweichungen zwischen deklariertem und tatsächlichem Zustand und meldet Auffälligkeiten sofort, bevor sie zum Problem werden. Drift-Erkennung ist ein Feature von Terraform Enterprise und Terraform Cloud.
Auditing und Revisionssicherheit
Ein skalierbarer Terraform-Setup über mehrere Tenants hinweg benötigt nicht nur strukturierte Zuständigkeiten und durchgängige Automatisierung, sondern auch lückenlose Auditierbarkeit aller Änderungen an Infrastrukturressourcen.
Terraform Cloud und Terraform Enterprise bieten hierfür ein integriertes Audit-Log, das sämtliche relevanten Ereignisse – wie das Anstoßen eines Plans, Änderungen an Variablen, Teamzuweisungen oder das Ausführen eines terraform apply – chronologisch, unveränderlich und exportierbar dokumentiert. Diese Logs lassen sich bei Bedarf in externe SIEM-Systeme integrieren, um Sicherheitsrichtlinien, gesetzliche Vorgaben oder branchenspezifische Compliance-Anforderungen wie ISO 27001, BSI C5 oder SOC 2 zu erfüllen.
Für Unternehmen mit besonders hohen Anforderungen an Nachvollziehbarkeit und Revisionssicherheit empfiehlt sich die Ergänzung durch ein zentrales Log-Management auf Basis von Lösungen wie Elastic Stack oder Splunk. So können nicht nur Aktivitäten auf Terraform-Ebene, sondern auch Kontextinformationen aus GitLab, CI/CD-Pipelines, Identity-Providern und Cloud-APIs korreliert und analysiert werden.
Besonders hilfreich sind dabei Mechanismen zur Verlinkung von Changesets mit Ticketsystemen (z. B. Jira) und ein klarer Prozess für Change-Approvals, die sicherstellen, dass jede Änderung durch mindestens eine autorisierte Person überprüft und freigegeben wurde. Dies ist ein zentraler Bestandteil von Separation of Duties und Least Privilege-Strategien.
Fazit
Skalierung über organisatorische Grenzen hinweg verlangt mehr als reines Terraform-Know-how. Wer klar definierte Teamstrukturen, konsequente Policy-Prüfungen, automatisierte Compliance-Prozesse und moderne CI/CD-Pipelines mit den Multi-Tenancy-Fähigkeiten von Terraform Cloud oder Enterprise kombiniert, schafft die Basis für eine sichere, reproduzierbare und effiziente Infrastruktur, die selbst über viele Tenants hinweg verlässlich funktioniert.
