STACKIT Landing Zone Accelerator

Accelerator-Architektur

• 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

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

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

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

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

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

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

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

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.

Code & Registry github.com Architektur des Landing Zone Accelerators Prüfen Sie Implementierungsarchitektur, Deployment-Konfigurationen und Netzwerkverhalten im Quell-Repository. Repository öffnen

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.