--- title: "STACKIT Landing Zone Accelerator" description: "STACKIT Basis-Asset zum Aufbau einer Platform Landing Zone mit wiederverwendbaren OpenTofu/Terraform-Modulen, Enterprise-Standards und zentralem Kubernetes." sidebar: badge: text: "STACKIT" variant: success scfAsset: managed: false category: "blueprint" external: true tags: ["design-and-mobilize", "landing-zone", "opentofu", "terraform", "template"] maintainers: - user: "lukas.weberruss" role: true website: true source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/landing-zone-foundation-opentofu/" source_file: "docs/de/migration/assetcontainer/stackit/landing-zone-foundation-opentofu.mdx" --- ## Accelerator-Architektur ![Architekturübersicht des STACKIT Landing Zone Accelerators vom Bootstrap über Plattformfunktionen bis zu Application Landing Zones und Workloads](../../../../contributors/stackit/files/migration/landing-zone-accelerator-architecture.svg) - GitHub Repository ## Übersicht Dieses Asset liefert eine wiederverwendbare Grundlage für die Umsetzung einer STACKIT Platform Landing Zone. Es ist für Enterprise-Umgebungen ausgelegt, die eine strukturierte Basis für Governance, Security, Netzwerk, Kostensteuerung und Automatisierung benötigen. Repository: - GitHub Repository ## Wie das Repository funktioniert Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut. - Das Root-Modul in `src/main.tf` orchestriert alle Plattform- und Landing-Zone-Bausteine. - Die Konfiguration erfolgt über flavor-spezifische Variablendateien in `src/config/`. - Deployment ist mit OpenTofu oder Terraform möglich (identische Modulstruktur). - Das erste Deployment nutzt einen temporären Bootstrap-Service-Account und wechselt danach auf Managed Backend und Managed Credentials. ## Deployment-Flavors und ihr Umfang Das Repository enthält acht Referenzkonfigurationen in `src/config/`. Wählen Sie die einfachste Topologie, die die erforderlichen Netzwerk-, Sicherheits-, Organisations-, Mandanten- und Regionsgrenzen erfüllt. ## Standalone ![Standalone-Topologie mit Management-Basis, Sandbox und öffentlicher Application Landing Zone](../../../../contributors/stackit/files/migration/standalone.svg) Nutzen Sie `standalone.tfvars` für die kleinste Basis: Governance, Management, eine Sandbox und eine öffentliche Application Landing Zone mit eigenem Netzwerk und direktem Internetzugang. Es wird weder eine gemeinsame Network Area noch ein Connectivity-Hub erstellt. Das Muster eignet sich, wenn Workloads keine private Ost-West-Kommunikation oder zentrales DNS benötigen. ## Hub-and-Spoke ![Hub-and-Spoke-Topologie mit gemeinsamer Network Area und separater öffentlicher Landing Zone](../../../../contributors/stackit/files/migration/hub-and-spoke.svg) Nutzen Sie `hub-and-spoke.tfvars`, wenn Corporate Workloads gemeinsame private Connectivity benötigen. Ein zentrales Connectivity-Projekt stellt Network Area und DNS bereit, die Corporate Data Platform nutzt diese private Domäne und öffentliche Workloads behalten unabhängige Netzwerke mit direktem Internetzugang. ## Hub-and-Spoke mit Firewall ![Hub-and-Spoke-Topologie mit zentraler Inspektion durch eine OPNsense-Firewall](../../../../contributors/stackit/files/migration/hub-and-spoke-firewall.svg) Nutzen Sie `hub-and-spoke-firewall.tfvars`, wenn Corporate Egress einen einheitlichen Inspektions- und Kontrollpunkt benötigt. Das Muster erweitert die gemeinsame Network Area um eine OPNsense-Firewall und führt die Default Routes der Corporate Landing Zones über die Appliance, während öffentliche Landing Zones direkt angebunden bleiben. ## Trennung von Finance und Research ![Finance- und Research-Topologie mit unabhängigen privaten Connectivity-Domänen](../../../../contributors/stackit/files/migration/hub-and-spoke-finance-research.svg) Nutzen Sie `hub-and-spoke-finance-research.tfvars`, wenn Business Units unabhängige Ownership und private Connectivity benötigen. Finance und Research erhalten innerhalb derselben STACKIT Organisation jeweils einen eigenen Adressplan, ein Connectivity-Projekt, eine Network Area und eine Workload Landing Zone. ## Network Areas für regulierte und gemeinsame Workloads ![Multi-Area-Topologie zur Trennung regulierter und gemeinsamer Workloads](../../../../contributors/stackit/files/migration/hub-and-spoke-multi-area.svg) Nutzen Sie `hub-and-spoke-multi-area.tfvars`, wenn regulierte und gemeinsame Workloads in getrennten privaten Connectivity-Domänen liegen müssen. Jede Domäne erhält eine eigene Network Area und DNS-Zone; zwischen ihnen besteht kein implizites Routing. ## Unabhängige regionale Hubs ![Multi-Region-Topologie mit unabhängigen Hubs in eu01 und eu02](../../../../contributors/stackit/files/migration/hub-and-spoke-multi-region.svg) Nutzen Sie `hub-and-spoke-multi-region.tfvars` für regionale Basen in `eu01` und `eu02`. Jede Region erhält einen unabhängigen Hub, eine Network Area, eine Workload Landing Zone und optional einen Platform-Kubernetes-Cluster. Interregionale Connectivity wird bewusst nicht erstellt und muss explizit entworfen werden. ## Isolation von Produktion und Nicht-Produktion ![Produktions- und Nicht-Produktions-Topologie mit getrennten Network Areas und Firewalls](../../../../contributors/stackit/files/migration/hub-and-spoke-prod-nonprod-firewall.svg) Nutzen Sie `hub-and-spoke-prod-nonprod-firewall.tfvars`, wenn Produktion von Nicht-Produktion isoliert werden muss. Jede Domäne erhält eine eigene Network Area und OPNsense-Firewall; Development und Test teilen die Nicht-Produktions-Domäne, bleiben aber getrennte Landing Zones. ## Mandantenisolation ![Mandantenisolation mit drei unabhängigen privaten Mandantendomänen](../../../../contributors/stackit/files/migration/hub-and-spoke-tenant-isolation.svg) Nutzen Sie `hub-and-spoke-tenant-isolation.tfvars` für mehrere Mandanten innerhalb einer Organisation. Jeder Mandant erhält unabhängige Ownership, einen eigenen Adressplan, eine Network Area, ein Connectivity-Projekt und eine Workload Landing Zone ohne privates Routing zu den anderen Mandantendomänen. ## Modul-für-Modul-Beschreibung ### 1. Governance-Modul (`src/modules/governance`) Zweck: - Erstellt die RM-Folder-Struktur (`platform`, `landing_zones_corporate`, `landing_zones_public`, `sandboxes`). - Vergibt Folder-Owner- und Auditor-Rollen. - Vergibt Organization-Owner- und Auditor-Rollen. - Erstellt Custom Roles auf Organisationsebene. Landing-Zone-Zuordnung: - **Platform Landing Zone**: zentrale Governance-Basis. ### 2. Management-Modul (`src/modules/management`) Zweck: - Erstellt ein zentrales Management-Projekt. - Provisioniert Secrets Manager und einen Default-Zugangsuser. - Provisioniert Object-Storage-Buckets (inklusive tfstate-Bucket). - Erstellt Object-Storage-Credentials und speichert sie im Secrets Manager. - Erstellt Automation-Service-Account plus rotierende Keys und speichert den Key im Secrets Manager. - Stellt optional Observability bereit und speichert die zugehörigen Zugangsdaten im Secrets Manager. - Konfiguriert optional Federated Identity Provider für den Automation-Service-Account. Landing-Zone-Zuordnung: - **Platform Landing Zone**: gemeinsamer Operations- und Automatisierungs-Kontrollpfad. ### 3. Connectivity-Modul (`src/modules/connectivity`) Zweck: - Erstellt ein dediziertes Connectivity-Projekt. - Erstellt Network Area und regionale Network-Area-Konfiguration. - Erstellt DNS-Zonen für gemeinsame Namensräume. - Stellt optional Firewall-Image, Volume, Server, Interfaces und Public IP bereit. - Liefert die Firewall-Next-Hop-IP für Routen in Corporate Landing Zones. Landing-Zone-Zuordnung: - **Platform Landing Zone**: gemeinsame Netzwerk- und Routing-Basis. ### 4. DevOps-Modul (`src/modules/devops`) Zweck: - Erstellt ein dediziertes DevOps-Projekt. - Erstellt optional eine zentrale STACKIT Git-Instanz mit ACL-Ranges. Landing-Zone-Zuordnung: - **Platform Landing Zone** in der Architektur dieses Accelerators. - Begründung: Das Modul liefert zentrale Delivery-Tooling-Grundlagen und Source-Control-Kapazität für mehrere Landing Zones. ### 5. Landing-Zone-Modul (`src/modules/landing-zone`) Zweck: - Erstellt anwendungsnahe Landing-Zone-Projekte iterativ über `for_each`. - Unterstützt **corporate** Landing Zones (an Network Area angebunden) und **public** Landing Zones. - Erstellt geroutete Netzwerke und optional Default-Route über Firewall-Next-Hop. - Erstellt optional projektbezogene Child-DNS-Zonen. - Erstellt projektbezogene Custom Roles und Role Assignments. - Erstellt Secrets Manager, Object-Storage-Buckets und Automation-Service-Account-Key-Material pro Landing Zone. Landing-Zone-Zuordnung: - **Application Landing Zone**: zentrales ALZ-Umsetzungsmodul. ### 6. Sandboxes-Modul (`src/modules/sandboxes`) Zweck: - Erstellt schlanke Sandbox-Projekte im dedizierten `sandboxes`-Folder. - Vergibt Project-Owner. Landing-Zone-Zuordnung: - **Application Landing Zone (unterstützend)**: nicht-produktive Testumgebung nahe ALZ-Nutzungsmustern. ## Neu umgesetzter Umfang in diesem Asset Die aktuelle Umsetzung enthält jetzt einen durchgängigen Pfad für eine zentrale Kubernetes-Plattform und ein namespace-basiertes Application-Onboarding. ### Platform Landing Zone für zentrales Kubernetes Der Platform-Umfang enthält jetzt eine dedizierte zentrale Kubernetes-Basis, die als geteilter Platform-Service betrieben werden kann. - **Zentrale Cluster-Basis**: Ein dediziertes Platform-Kubernetes-Projekt mit SKE-Cluster-Life-cycle, DNS-Extension-Integration und optionaler Observability-Anbindung. - **Secret-Policy-Readiness**: Namespace-bezogenes Secret-Manager-Policy-Enforcement unterstützt schrittweise Rollout-Modi wie audit und strict. - **Shared-Service-Modell**: Plattform-Teams können zentrale Fähigkeiten bereitstellen und gleichzeitig klare Projekt- und Namespace-Grenzen beibehalten. - **Betriebs-Basis**: Cluster-bezogene Outputs und Informationen zum Zugriff stehen für Automatisierung und kontrollierte Plattform-Operationen bereit. ### Application Landing Zone für Namespace-Tenants Application Landing Zones können jetzt den Namespace-Service aus dem zentralen Platform-Kubernetes-Cluster nutzen. - **Namespace-Onboarding**: Die Landing-Zone-Konfiguration kann die Namespace-Erstellung für ein Team im Shared Cluster anfordern. - **Developer-Zugriffspfad**: Namespace-spezifische Kubernetes-User und Role-Bindings werden für Tenant-Operationen bereitgestellt. - **Service-Exposition**: DNS- und Ingress-Muster sind für Service-Endpunkte auf Basis von Landing-Zone- und Namespace-Kontext vorkonfiguriert. - **Secret-Integration**: Workloads können zentral gesteuerte Secret-Flows konsumieren und bleiben dabei im Namespace-Umfang. ## Zusätzliche Plattform-Features in diesem Setup - **External-DNS-Automatisierung**: DNS-Einträge für Namespace-Services werden über Kubernetes-Annotationen und Extension-Zone-Integration verwaltet. - **Zentrales Kubernetes-Monitoring**: Die Plattform-Observability-Integration umfasst Grafana-Zugang und Metrics-Push-Wiring für Cluster-Telemetrie. - **Dashboard-Provisioning-Workflow**: Beispiel-Dashboards werden für eine schnellere operative Übergabe provisioniert und importiert. - **Option für Encrypted Volumes**: Unterstützung für verschlüsselte Volume-Muster hilft bei strengeren Datenschutz- und Compliance-Anforderungen. - **Flexibles Netzwerk-Setup**: Das Platform-Kubernetes-Modul unterstützt SNA-orientierte Netzwerk-Setups für kontrollierte Enterprise-Konnektivität. ## Was Entwickler in einer Application Landing Zone bekommen - **Sofort nutzbarer Namespace**: Ein vorkonfigurierter Namespace im zentralen Cluster statt eines vollständigen Cluster-pro-Team-Modells. - **Least-Privilege-Zugriff**: Namespace-bezogene Identitäten und Berechtigungen passend zu typischen Day-2-Developer-Aufgaben. - **Konsistentes Endpunkt-Modell**: Vorhersehbare DNS- und Ingress-Muster für die Service-Veröffentlichung. - **Governed Secret Usage**: Zentrale Secret-Governance mit Namespace-bezogenen Mustern zur Nutzung. - **Observability-Transparenz**: Gemeinsame Metrik- und Dashboard-Sichten helfen Teams bei Rollout und Validierung im Betrieb. ## Platform vs Application Landing Zone Umfang in diesem Repository - **Platform Landing Zone Fokus (derzeit der größere Umfang)**: - `governance` - `management` - `connectivity` - `devops` - **Application Landing Zone Umfang (derzeit fokussierter)**: - `landing-zone` (ALZ-Kernprovisionierung) - `sandboxes` (unterstützende ALZ-nahe Umgebungen) Damit liefert das Repository aktuell primär eine starke Plattform-Basis, während ALZ-Funktionalität bewusst auf Landing-Zone-Instanziierung und Sandbox-Enabling fokussiert ist. ## Einsatz im Migrationsprogramm - Plattform-Basis früh starten (Governance, Management, Connectivity, optional DevOps). - Corporate- vs Public-ALZ-Muster anhand von Connectivity- und Compliance-Anforderungen definieren. - Application Landing Zones über die `landing_zones`-Map in Variablendateien bereitstellen. - Sandboxes für Team-Onboarding und kontrollierte frühe Experimente nutzen. - Nach erstem Apply State in das Managed Backend migrieren und von Bootstrap-Credentials auf Managed Automation-Credentials wechseln. ## Inhalt des Assets - **Wiederverwendbare Basismodule**: Bausteine für Account-/Projektstruktur, IAM, Netzwerk und Kontrollen. - **Policy-orientiertes Setup**: Leitplanken und Konventionen für sichere und steuerbare Cloud-Nutzung. - **IaC-First-Ansatz**: OpenTofu/Terraform als Modell für wiederholbare Bereitstellung. - **Erweiterbar für Enterprise-Bedarf**: Bewusst als Basis für kundenspezifische Anpassungen ausgelegt. ## Typischer Einsatz im Migrationsprogramm - **Früher Plattform-Stream**: Aufbau parallel zum Discovery starten. - **Kontrollbasis vor produktiver Migration**: Pflichtkontrollen vor dem ersten produktiven Move etablieren. - **Template-Quelle für Application Landing Zones**: Basismodule für Workload-Archetypen wiederverwenden und verfeinern. ## Empfohlene Voraussetzungen - Organisations- und Ownership-Modell für Projekte und Umgebungen. - Security- und Compliance-Vorgaben (Identität, Logging, Nachweise, Segmentierung). - Konnektivitäts- und Integrationsanforderungen. - Betriebsmodell-Abstimmung zwischen Plattform-, Security- und Applikationsteams.