Platform Landing Zone
Unternehmensweite Grundlage für Governance, Identität, Security, Netzwerk, Kostensteuerung und Automatisierung.
Zur Platform Landing ZoneSTACKIT Serviceportfolio-Karte
STACKIT
Landing-Zone-Journey
Zuletzt aktualisiert am
STACKIT
Landing-Zone-Journey
Geführte Landing-Zone-Präsentation von Grundlagen und Architektur bis zu Accelerator, Umsetzung, Managed Service und sicherer skalierbarer Betriebsbasis.
STACKIT Serviceportfolio erkunden
Allgemein
Architecture portfolio reference services architecture
STACKIT
Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.
Erkunden Sie mit dieser interaktiven Karte das STACKIT Serviceportfolio. Wählen Sie ein Produkt oder Zugriffstool aus, um die aktuelle Dokumentation oder das zugehörige Cloud-Framework-Asset zu öffnen.
Interaktives Serviceportfolio
Abschnitt betitelt „Interaktives Serviceportfolio“Nutzungshinweise
Abschnitt betitelt „Nutzungshinweise“Die Karte dient als Navigationshilfe und stellt keine Lifecycle-Zusage dar. Prüfen Sie auf den verlinkten Produktseiten die aktuellen Regionen, Verfügbarkeiten, Service Levels und Release-Status.
Gesamte STACKIT Produktdokumentation durchsuchen Dokumentation öffnenLanding Zone im Migration Framework einordnen
Eine Landing Zone ist die gemeinsame Startbahn für eine steuerbare Migration. Sie wird in Design and Mobilize als Plattformbasis etabliert, damit Migrationswellen auf einer funktionierenden Grundlage für kontrollierte Delivery und stabilen Betrieb aufbauen.
Platform Landing Zone definieren
Ordnen Sie die Landing Zone als strukturierte Cloud-Basis für einen steuerbaren STACKIT-Betrieb ein. Klären Sie früh, welche Leitplanken verbindlich sind, wer sie verantwortet und welche Anforderungen die Anwendungen mitbringen.
Überblick: Landing Zones
Abschnitt betitelt „Überblick: Landing Zones“Eine Landing Zone ist die strukturierte Cloud-Grundlage, die festlegt, wie Ihre Organisation auf STACKIT von Anfang an betrieben wird. Sie verbindet Governance, Identität, Security, Netzwerkarchitektur, Kostensteuerung und Automatisierung zu einem belastbaren Rahmen.
Ohne diese Grundlage stocken Migrationswellen typischerweise durch fehlende Freigaben, inkonsistente Kontrollen und wiederkehrende Plattformentscheidungen.
Kernkomponenten
Abschnitt betitelt „Kernkomponenten“Die folgende Visualisierung zeigt die zentralen Komponenten für eine belastbare Plattform-Basis.
Warum Sie eine Landing Zone brauchen
Abschnitt betitelt „Warum Sie eine Landing Zone brauchen“- Kontrolle und Risikoreduktion: Security- und Compliance-Kontrollen werden konsistent umgesetzt.
- Skalierbare Delivery-Basis: Wiederverwendbare Muster beschleunigen mehrere Migrationswellen.
- Klare Verantwortlichkeiten: Zuständigkeiten zwischen Plattform-, Security- und Applikationsteams sind klar.
- Höhere Umsetzungsgeschwindigkeit: Grundlegende Kontrollen müssen nicht je Applikation neu entworfen werden.
Wann Sie starten sollten
Abschnitt betitelt „Wann Sie starten sollten“Starten Sie den Landing-Zone-Stream so früh wie möglich parallel zum Discovery.
- Zu spät: Produktive Migrationen werden blockiert, weil Pflichtkontrollen noch fehlen.
- Zu früh ohne Discovery-Feedback: Relevante Applikationsrandbedingungen fehlen und führen zu Nacharbeit.
Bewährt hat sich ein zweigleisiges Vorgehen: Die Plattform-Basis früh etablieren und Application-Landing-Zone-Templates iterativ mit Discovery-Erkenntnissen verfeinern.
Zwei Ebenen: Platform und Application Landing Zone
Abschnitt betitelt „Zwei Ebenen: Platform und Application Landing Zone“Application Landing Zone
Workload-spezifische Umsetzungsprofile, abgeleitet aus Plattform-Basis und Discovery-Ergebnissen.
Zur Application Landing ZoneTypische Eingaben aus dem Unternehmen
Abschnitt betitelt „Typische Eingaben aus dem Unternehmen“Für ein belastbares Landing-Zone-Design werden typischerweise benötigt:
- Organisations- und Ownership-Modell: Einheiten, Projektgrenzen und Verantwortungsmodell.
- Compliance- und Policy-Anforderungen: Regulatorische Pflichten und interne Kontrollvorgaben.
- Security-Anforderungen: IAM-Standards, Netzsegmentierung, Verschlüsselung und Logging.
- Betriebs- und Supportvorgaben: Incident-Prozesse, Eskalationswege und Übergabemodell.
- Erkenntnisse aus dem Applikationsportfolio: Discovery-Resultate zu Abhängigkeiten und Archetypen.
Vorgehensmodell
Abschnitt betitelt „Vorgehensmodell“- Unternehmensweite Leitplanken und Kontrollmodell definieren.
- Platform Landing Zone als Code aufbauen und validieren.
- Application-Landing-Zone-Templates aus Discovery und Migrationsdesign ableiten.
- Mit Pilot-Workloads testen und über Migration-Factory-Runbooks skalieren.
STACKIT Beschleuniger und Assets
Abschnitt betitelt „STACKIT Beschleuniger und Assets“Um die Umsetzung zu beschleunigen, bietet STACKIT konkrete Best Practices und wiederverwendbare Vorlagen:
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Blueprint
Migration
Service
Migration
Blueprint
Migration
Software
Migration
Service
Account Governance strukturieren
Etablieren Sie Organisationsstruktur, Projektgrenzen und ein Ownership-Modell, damit Landing-Zone-Governance über Teams und Umgebungen hinweg wiederholbar bleibt.
Zielbild
Abschnitt betitelt „Zielbild“Account Governance beschreibt, wie Teams, Umgebungen und Zuständigkeiten in der Cloud klar getrennt und steuerbar aufgebaut werden.
Damit entsteht die organisatorische Steuerungsebene für Migrationswellen: wo Workloads betrieben werden, wem welcher Scope gehört und wie neue Projekte ohne Umgehung von Guardrails angebunden werden.
Governance-Hierarchie
Abschnitt betitelt „Governance-Hierarchie“
Governance-Design und Delivery
Abschnitt betitelt „Governance-Design und Delivery“Kernbausteine der Governance
Abschnitt betitelt „Kernbausteine der Governance“- Regions: Die Regionenstrategie bestimmt Datenlokalität, Latenzprofil und Resilienzgrenzen für Workloads und Shared Services. Definieren Sie früh verbindliche Nutzungsmuster und stimmen Sie diese mit Compliance- und Kontinuitätsanforderungen ab. Dokumentation
- Customer Account: Der Customer Account ist die oberste Governance-Grenze für Ownership, Abrechnung und Administration. Er bildet den Anker für organisationsweite Standards und Kontrollverantwortung. Dokumentation
- STACKIT Folder: Folder strukturieren organisatorische Domänen (zum Beispiel Plattform, Shared Services, Business Units, Umgebungen) und ermöglichen Policy-Vererbung sowie klare Delegationsmodelle. Dokumentation
- STACKIT Projects: Projects sind die Delivery-Scopes, in denen Ressourcen bereitgestellt und betrieben werden. Sie sollten über ein definiertes Onboarding-Modell an Folder angebunden werden und nicht ad hoc entstehen. Dokumentation
Wie die Bausteine zusammenspielen
Abschnitt betitelt „Wie die Bausteine zusammenspielen“- Regionprinzipien zuerst: Legen Sie fest, welche Regionen für welche Workload-Klassen zulässig sind.
- Customer Account als Governance-Root: Verankern Sie globale Ownership, Policy-Absicht und finanzielle Verantwortlichkeit.
- Folder für Struktur und Delegation: Überführen Sie das Betriebsmodell in skalierbare organisatorische Grenzen.
- Projects für Delivery: Stellen Sie Projektscopes über einen standardisierten Lebenszyklus mit verpflichtenden, vom Folder geerbten Kontrollen bereit.
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Region-Governance-Modell: Entscheiden Sie zwischen Single-Region-, Dual-Region- oder Workload-basiertem Regionenansatz inklusive Ausnahmen.
- Customer-Account-Verantwortung: Definieren Sie, welche zentralen Teams Governance, Billing-Transparenz und Kontrollbetrieb verantworten.
- Folder-Topologie: Legen Sie fest, wie Folder auf Domänen wie Plattform, Umgebungen und Business Units abgebildet werden.
- Project-Onboarding-Modell: Standardisieren Sie Projekterstellung, Namenskonventionen, Tagging und Lebenszyklus-Kontrollen.
- Policies und Ausnahmen: Definieren Sie verpflichtende Guardrails und transparente Ausnahmeprozesse.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Governance-Blueprint: Customer-Account-, Folder- und Project-Topologie mit Verantwortungsmatrix.
- Regionen-Nutzungsrichtlinie: Freigegebene Regionenmuster je Workload-Typ und Risikoprofil.
- Project-Onboarding-Standard: Wiederholbarer Prozess für die Erstellung und Anbindung gesteuerter Projekte.
- Control-Baseline: Erzwungene Namens-, Tagging- und Policy-Kontrollen mit dokumentiertem Ausnahmefluss.
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Keine Regionenrichtlinie: Regionauswahl pro Team oder Projekt ohne unternehmensweite Leitplanken.
- Unstrukturierte Project-Sprawl: Projekte entstehen ohne Folder-Strategie, klare Ownership oder Lebenszyklusstandards.
- Governance nur auf Papier: Kontrollen sind dokumentiert, aber nicht im Projekt-Onboarding und Betrieb verankert.
Zielbild
Abschnitt betitelt „Zielbild“IAM stellt sicher, dass Zugriffe eindeutig zugeordnet, nachvollziehbar und auf das notwendige Maß begrenzt sind.
Für Migrations-Landing-Zones ist IAM das zentrale Kontrollrückgrat, das menschliche Identitäten, technische Identitäten und Autorisierungsregeln in ein steuerbares Betriebsmodell überführt.
Kernbausteine von IAM
Abschnitt betitelt „Kernbausteine von IAM“- Access and Identity (zentrale Domäne): Nutzen Sie die Plattformdomäne als zentrale Referenz für IAM-Funktionen und Betriebsverantwortung. Dokumentation
- STACKIT IDP: Nutzen Sie den STACKIT IDP als Identitäts-Kontrollpunkt für Authentifizierung und Account-Zugriffsflüsse. Dokumentation
- Federation (SAML 2.0): Integrieren Sie Unternehmensidentitäten per Föderation, um zentrale Identity-Lifecycles durchzusetzen und lokale Account-Sprawl zu reduzieren. Dokumentation
- Roles and Permissions: Definieren Sie rollenbasierte Autorisierungsgrenzen für Plattformteams, Applikationsteams und Betrieb. Dokumentation
- Custom Roles: Implementieren Sie Least-Privilege-Muster, wenn Standardrollen für Enterprise-Kontrollen zu weit gefasst sind. Dokumentation
- Service Accounts: Trennen Sie technische Identitäten von Benutzeridentitäten für Automatisierung, CI/CD und betriebliche Integrationen. Dokumentation
Wie die Bausteine zusammenspielen
Abschnitt betitelt „Wie die Bausteine zusammenspielen“- Identitätsquelle und Vertrauen: STACKIT IDP plus Federation legen fest, wer authentifiziert wird und unter welchen Unternehmensrichtlinien.
- Autorisierungsmodell: Roles and Permissions definieren, wer in welchem Governance-Scope welche Aktionen ausführen darf.
- Least-Privilege-Verfeinerung: Custom Roles schließen Berechtigungslücken, wenn Standardrollen Anforderungen zur Aufgabentrennung nicht abdecken.
- Automatisierungs-Identitätsmodell: Service Accounts liefern nicht-menschliche Identitäten für wiederholbaren Betrieb ohne persönliche Zugangsdaten.
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Identity-Integrationsansatz: Entscheiden Sie, wie Unternehmensidentitäten föderiert werden und wie Lifecycle-Ereignisse synchronisiert sind.
- Rollenarchitektur je Scope: Definieren Sie Rollengrenzen für Plattform, Security, Betrieb und Applikationsteams.
- Custom-Role-Strategie: Legen Sie fest, wann Custom Roles erforderlich sind und wie sie geprüft und freigegeben werden.
- Kontrollen für privilegierten Zugriff: Definieren Sie Freigabe-Workflows, temporäre Erhöhung und Notfallzugriffsprozesse.
- Service-Account-Governance: Standardisieren Sie Erstellung, Ownership, Credential-Rotation und Nachverfolgbarkeit technischer Identitäten.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- IAM-Architektur-Baseline: Föderiertes Authentifizierungsmodell mit dokumentierten Vertrauensgrenzen.
- Rollen- und Berechtigungsmatrix: Zuordnung von Standard- und Custom-Rollen pro organisatorischem Scope.
- Service-Identity-Standard: Guardrails für Service Accounts in Automatisierung und Plattformbetrieb.
- Operatives IAM-Betriebsmodell: Verfahren für privilegierten Zugriff, Freigaben und Notfallzugriffe.
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Keine Föderationsstrategie: Lokale Identitätssilos und inkonsistentes Lifecycle-Handling.
- Überprivilegierte Standardrollen: Breite Berechtigungen ohne Custom-Least-Privilege-Kontrollen.
- Geteilte privilegierte Benutzerkonten: Administrative Aktionen sind keiner eindeutig verantwortlichen Identität zuordenbar.
- Automatisierung mit menschlichen Identitäten: Pipelines und Integrationen laufen unter persönlichen Konten statt Service Accounts.
Sicherheit und Compliance Themen
Ordnen Sie Sicherheits- und Compliance-Themen früh ein, damit Kontrollanforderungen, Nachweise, Souveränitätsentscheidungen und Zero-Trust-Prinzipien in das Landing-Zone-Design einfließen.
Zielbild
Abschnitt betitelt „Zielbild“Sicherheit und Compliance definieren die Leitplanken für Migrationsentscheidungen in Design, Landing Zones und Umsetzung.
Ziel ist es, Vorgaben in technisch erzwungene Kontrollen und kontinuierlich erzeugbare Nachweise zu übersetzen.
Themenkarte Sicherheit und Compliance
Abschnitt betitelt „Themenkarte Sicherheit und Compliance“Nutzen Sie diese semantische Karte als strukturierten Einstieg in alle Themen dieses Moduls.
Warum dieses Modul früh starten muss
Abschnitt betitelt „Warum dieses Modul früh starten muss“Sicherheit und Compliance sind kein später Härtungsschritt, sondern prägen Architekturentscheidungen von Beginn an:
- Architektur zuerst: Vertrauensgrenzen, Modell für das Netzwerk und Identitätskontrollen lassen sich spät nur mit hohem Aufwand nachziehen.
- Kontinuierliche Lieferung: Fehlende Pflichtkontrollen blockieren Freigaben und verlangsamen Migrationswellen.
- Nachweise von Anfang an: Compliance-Nachweise müssen laufend erzeugt und dürfen nicht spät rekonstruiert werden.
- Gemeinsame Verantwortung: Jeder Design-Strang braucht die Sicht von Sicherheit und Compliance.
Wie das Modul Design und Landing Zones unterstützt
Abschnitt betitelt „Wie das Modul Design und Landing Zones unterstützt“- Design-Perspektive: Architektur, Prinzipien für Kontrollen und Governance-Modell definieren.
- Landing-Zone-Perspektive: Prinzipien in Platform- und Application-Landing-Zones umsetzen.
Dieses Modul bildet die verbindliche Grundlage für beide Kontexte.
Übergang von On-Premises in die Cloud
Abschnitt betitelt „Übergang von On-Premises in die Cloud“- Von statischen Grenzen zu dynamischen Bereichen: Projekte und Services verändern sich schneller als klassische Zonen.
- Von manuellen Freigaben zur Durchsetzung von Richtlinien: Kontrollen müssen automatisierbar und testbar sein.
- Von isolierten Protokollen zu zusammenführbarer Telemetrie: Audit-, Plattform- und Applikationssignale gehören zusammen.
- Von Fokus auf Infrastruktur zu gemeinsamen Plattformfähigkeiten: Identität, Schlüssel, Observability und Governance sind Plattformfähigkeiten.
Architekturansätze gezielt kombinieren
Abschnitt betitelt „Architekturansätze gezielt kombinieren“- Architektur mit Fokus auf das Netzwerk: Hub-and-Spoke-Routing, zentrale Firewalls und Segmentierung.
- Zero-Trust-orientierte Architektur: Explizite Identität, starke Authentifizierung, Ende-zu-Ende-Verschlüsselung und Least Privilege.
In der Praxis braucht der Zielzustand oft beide Ansätze mit klaren Kriterien für den Einsatz je Workload-Klasse.
Digitale Souveränität und Compliance
Abschnitt betitelt „Digitale Souveränität und Compliance“In vielen Programmen sind Regelkonformität (Compliance) und digitale Souveränität zentrale Treiber der Migration:
- Rechtliche und Residency-Anforderungen: Region- und Entscheidungen zum Daten-Standort beeinflussen Architektur und Kontrollen.
- Operative Souveränitätsziele: Governance, Portabilität und Transparenz reduzieren Abhängigkeitsrisiken.
- EU Cloud Sovereignty Framework (CSF): Nutzen Sie ein CSF-orientiertes Kontroll- und Mapping-Modell für Nachweise und die Steuerung des Reifegrads.
Compliance bei der Migration: Was bleibt, was ändert sich
Abschnitt betitelt „Compliance bei der Migration: Was bleibt, was ändert sich“Bei einer Migration von On-Premises in die Cloud bleibt die Compliance-Verpflichtung des Unternehmens inhaltlich bestehen.
Was sich ändert, ist die Art der Umsetzung, der Nachweise und der Betriebsprozesse.
- Was bleibt gleich: Rechtliche Vorgaben, interne Richtlinien, Prüfbarkeit und Verantwortlichkeit.
- Was ändert sich: Kontrollen werden stärker automatisiert, Nachweise kontinuierlich erzeugt und Verantwortlichkeiten zwischen Plattform und Teams neu geschnitten.
Typische Compliance-Kategorien in der Migration:
- Datenschutz und Speicherort von Daten: Anforderungen an Daten, Orte für die Speicherung und klare Grenzen für Zugriffe.
- Zugriff und Berechtigungen: Prinzipien für Rollen, Trennung von Aufgaben und privilegierte Zugriffe.
- Protokollierung und Nachweise: Anforderungen an Vollständigkeit, Aufbewahrung und gute Auswertung.
- Betriebssicherheit und Notfallfähigkeit: Anforderungen an Verfügbarkeit, Wiederherstellung und klare Reaktion im Störfall.
- Lieferanten und Verträge: Anforderungen an Provider, vertragliche Regeln und überprüfbare Zusicherungen.
Wie STACKIT die Compliance-Erfüllung konkret unterstützt
Abschnitt betitelt „Wie STACKIT die Compliance-Erfüllung konkret unterstützt“- Geprüfte Grundlage für Sicherheit: Zertifizierte Rechenzentren und etablierte Sicherheitsstandards schaffen eine belastbare Grundlage für regulatorische Anforderungen.
- C5 als prüfbarer Nachweis: Das C5-Testat bietet strukturierte Nachweise zu zentralen Bereichen wie Risiko, Betrieb, Zugriff, Verschlüsselung und Umgang mit Vorfällen.
- Transparenz für Audits: Prüfberichte und dokumentierte Kontrollen unterstützen interne Revision, externe Audits und die eigene Analyse von Risiken.
- Unterstützung in der Umsetzung: Guidance für Architektur, Rollenmodell und Zuordnung von Kontrollen hilft, Compliance-Anforderungen für den Cloud-Betrieb umzusetzen.
- Shared Responsibility bleibt zentral: STACKIT stellt Plattformkontrollen und Nachweise bereit, das Unternehmen verantwortet weiterhin Konfiguration, Berechtigungen und die Einordnung von Daten.
Aufbau des Moduls
Abschnitt betitelt „Aufbau des Moduls“Betriebsmodell und Steuerung
Definieren Sie Rollen, Entscheidungsrechte, Verantwortlichkeiten und verbindliche Prüfpunkte für Sicherheit und Compliance.
Modul öffnenArchitekturmuster
Definieren Sie, wo netzwerkzentrierte Kontrollen zwingend sind und wo Zero Trust priorisiert wird.
Modul öffnenSicherheitsgrundsätze nach Security by Design
Definieren Sie Basisanforderungen für Identität, Netzwerk, Workloads und Datenschutz.
Modul öffnenKontrollen und Nachweise
Definieren Sie präventive und detektive Kontrollen sowie automatisierte Evidenzbereitstellung.
Modul öffnenÜbergang von On-Premises in die Cloud
Klären Sie, welche Sicherheitsannahmen und Betriebspraktiken in der Cloud angepasst werden müssen.
Modul öffnenDigitale Souveränität und CSF-Abgleich
Übersetzen Sie Souveränitäts- und CSF-Anforderungen in Architektur, Kontrollen und Nachweise.
Modul öffnenZielbild
Abschnitt betitelt „Zielbild“In Landing Zones sind Sicherheit und Compliance verbindliche Leitlinien für die Umsetzung, die aus dem eigenständigen Modul abgeleitet werden.
Nutzen Sie diese Seite für die konkrete Anwendung in Platform- und Application-Landing-Zones.
Das Modul als Quelle
Abschnitt betitelt „Das Modul als Quelle“- Modulübersicht: /de/migration/design-and-mobilize/security-and-compliance/overview/
- Betriebsmodell und Governance: /de/migration/design-and-mobilize/security-and-compliance/operating-model-and-governance/
- Architektur: /de/migration/design-and-mobilize/security-and-compliance/architecture-patterns/
- Sicherheitsgrundsätze: /de/migration/design-and-mobilize/security-and-compliance/security-by-design-baseline/
- Kontrollen und Nachweise: /de/migration/design-and-mobilize/security-and-compliance/controls-and-evidence-pipeline/
- Übergang in die Cloud: /de/migration/design-and-mobilize/security-and-compliance/onpremises-to-cloud-shift/
- Digitale Souveränität und CSF-Abgleich: /de/migration/design-and-mobilize/security-and-compliance/digital-sovereignty-and-csf-alignment/
Umsetzung in Landing Zones
Abschnitt betitelt „Umsetzung in Landing Zones“- Audit Logging: Nutzen Sie zentrales Audit Logging als autoritative Quelle für sicherheitsrelevante Plattformaktionen und administrative Änderungen. Dokumentation
- Telemetry Router: Leiten und normalisieren Sie Telemetrieströme, damit Logs und Metriken aus verteilten Workloads konsistent erfasst werden. Dokumentation
- Logs: Etablieren Sie zentrale Muster für Log-Erfassung zur operativen und sicherheitsbezogenen Analyse. Dokumentation
- Observability: Entwerfen Sie Observability als Schichtenmodell: Application Logs je Anwendung plus zentrales Audit Logging und Plattformtelemetrie für Governance und Incident-Analyse. Dokumentation
- Netzwerksicherheit: Wenden Sie Härtungsprinzipien für Segmentierung, kontrollierte Verkehrsflüsse und reduzierte Angriffsflächen an. Dokumentation
- Sicherheit für Compute-Ressourcen: Definieren Sie Härtungsstandards für Workloads und sichere Praktiken für die Laufzeit von Compute-Ressourcen. Dokumentation
- Secrets Manager: Speichern und verwalten Sie sensible Zugangsdaten und Geheimnisse von Anwendungen über gemanagte Kontrollen statt ad hoc. Dokumentation
- KMS: Steuern Sie Schlüssellebenszyklen und Verschlüsselungs-Governance über einen zentralen Key-Management-Ansatz. Dokumentation
- ACL-Muster für PaaS-Services: Nutzen Sie servicebezogene Access Control Lists, um Verbindungswege zu gemanagten Services zu begrenzen. PostgreSQL ist ein Beispiel, das Muster gilt jedoch für STACKIT-PaaS-Services allgemein. PostgreSQL-Referenz: Dokumentation .
- Unified Firewall: Nutzen Sie zentrale Firewall-Kontrollen für konsistente Netzwerk-Policy-Durchsetzung über Zonen und Workloads hinweg. Dokumentation
Wie dies in Landing Zones zusammenspielt
Abschnitt betitelt „Wie dies in Landing Zones zusammenspielt“- Nachweis- und Erkennungsschicht: Audit Logging, Logs, Telemetry Router und Observability bilden die Datengrundlage für Compliance-Nachweise und Incident-Analyse.
- Präventive Härtungsschicht: Netzwerksicherheit, Sicherheit für Compute-Ressourcen, Unified Firewall und Service-ACLs reduzieren Exposition und erzwingen freigegebene Verkehrs- und Grenzen für die Laufzeit.
- Datenschutzschicht: Secrets Manager und KMS schützen sensitive Datenpfade und kryptografische Assets über den gesamten Workload-Lebenszyklus.
- Betriebsmodell: Applikationsteams liefern Workload-Telemetrie, zentrale Teams verantworten die gemeinsame Audit- und Governance-Sicht.
Wichtige Entscheidungen in Landing Zones
Abschnitt betitelt „Wichtige Entscheidungen in Landing Zones“- Grenzen der Logging-Architektur: Definieren Sie, was auf Applikations-, Plattform- und Audit-Ebene geloggt wird und wo jeder Stream aufbewahrt wird.
- Telemetry- und Observability-Modell: Legen Sie Routing, Enrichment und Ownership für Logs, Metriken und Traces fest.
- Hardening-Baseline-Umfang: Definieren Sie verpflichtende Kontrollen für Netzwerk- und Compute-Domänen inklusive Firewall- und Service-ACL-Mustern.
- Geheimnis- und Schlüssel-Governance: Standardisieren Sie Nutzung, Verantwortlichkeit und Lebenszyklus-Verantwortung für Secrets Manager und KMS.
- Compliance-Betriebsmodell: Definieren Sie, wer Nachweiserhebung, Kontrollverifikation und Reporting-Takt verantwortet.
Typische Ergebnisse für Landing Zones
Abschnitt betitelt „Typische Ergebnisse für Landing Zones“- Sicherheits-Basiskatalog: Kontrollen für Netzwerk, Compute, Identität und Datenschutz.
- Logging- und Nachweisarchitektur: Zentrales Audit Logging plus Workload-Observability mit klaren Ownership-Grenzen.
- Geheimnis- und Verschlüsselungsstandard: Definiertes Nutzungsmodell für Secrets Manager, KMS und den Lebenszyklus von Schlüsseln und Geheimnissen.
- Response- und Eskalationsmodell: Operative Runbooks für Erkennung, Bewertung und Incident-Reporting.
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Sicherheit erst in späten Migrationsphasen: Kontrollen werden nach dem Workload-Onboarding statt von Anfang an eingeführt.
- Entkoppelte Telemetrie-Stacks: Audit-, Plattform- und Applikationssignale sind bei Incidents nicht korrelierbar.
- Secrets im Code oder in ungemanagten Stores: Sensitive Werte werden nicht über dediziertes Secret Management gesteuert.
- Flacher Netzwerkzugriff ohne Service-Kontrollen: Fehlende Firewall- und ACL-Grenzen erlauben übermäßige laterale Bewegung.
Netzwerkarchitektur gestalten
Definieren Sie Segmentierung, Connectivity, DNS, Routing und sichere Kommunikationsmuster für Shared Services und Workload-Umgebungen.
Zielbild
Abschnitt betitelt „Zielbild“Die Netzwerkarchitektur regelt sichere Kommunikation, Segmentierung und die Governance zentraler Connectivity-Services über Shared und projektbezogene Landing Zones.
In Enterprise-Migrationen geht es dabei weniger um einzelne Subnetze, sondern um ein dauerhaft steuerbares Konnektivitätsmodell: welches Projekt über welche Pfade angebunden wird und unter welchen Guardrails.
Referenztopologie
Abschnitt betitelt „Referenztopologie“
Connectivity-Design und Delivery
Abschnitt betitelt „Connectivity-Design und Delivery“Kernbausteine der Connectivity
Abschnitt betitelt „Kernbausteine der Connectivity“- STACKIT Network Area: Nutzen Sie eine geteilte Unternehmens-Netzwerkscope als zentrales Rückgrat für Projektanbindung und Governance-Planung. Dokumentation
- Routing Tables: Definieren und erzwingen Sie, wie Projekte innerhalb einer Network Area verbunden sind und ob ein Hub-and-Spoke-Modell mit zentraler Firewall-Kontrolle oder eine flachere Topologie genutzt wird. Dokumentation
- DNS: Standardisieren Sie Namensgebung und Service Discovery frühzeitig, damit Connectivity-Design, Zertifikatshandling und Workload-Cutovers konsistent bleiben. Dokumentation
- VPN (Connectivity): Behandeln Sie VPN als zentrale Connectivity-Fähigkeit für Hybrid- und Multi-Cloud-Integrationsmuster, nicht als isolierte Einzellösung. Dokumentation
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Network-Area-Ownership-Modell: Entscheiden Sie, wer geteilte Connectivity zentral steuert und welche Onboarding-Kriterien für angebundene Projekte gelten.
- Routing-Strategie je Domäne: Legen Sie fest, wo Hub-and-Spoke mit zentraler Inspektion verpflichtend ist und wo eine flache Routing-Topologie ausreicht.
- Hybrid-Connectivity-Baseline: Definieren Sie, wie VPN-basierte Konnektivität in Plattformstandards und Betriebs-Lifecycle integriert wird.
- Namensauflösungsdesign: Standardisieren Sie DNS-Grenzen und Muster für Plattformservices, Shared Services und Applikations-Landing-Zones.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Zieltopologie und Vertrauensgrenzen: Dokumentierter Zielzustand für Segmentierung und projektübergreifende Kommunikation.
- Network-Area-Onboarding-Prinzipien: Klare Kriterien, welche Projekte angebunden werden, wie Reviews ablaufen und wie Änderungen freigegeben werden.
- Routing-Governance-Modell: Definierter Einsatz von Routing Tables inklusive Entscheidungskriterien für Hub-and-Spoke versus flaches Routing.
- Connectivity-Baseline: Wiederverwendbare Standards für VPN, DNS und gemeinsame Netzwerk-Services.
Asset-Container-Referenz
Abschnitt betitelt „Asset-Container-Referenz“Asset-Titel
Framework
Asset-Typ
Migration
Software
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Ungeplantes Wachstum der Network Area: Projekte werden ohne zentrale Architekturprüfung und Ownership angebunden.
- Ad-hoc-Einsatz von Routing Tables: Inkonsistente Routing-Logik je Projekt ohne Referenzarchitektur.
- DNS als Nachgedanke: Späte DNS-Entscheidungen bremsen Migrationstermine oder stören Service Discovery.
- VPN als Ausnahmepfad: VPN wird als Sonderlösung statt als geregelte Grundlage für die Konnektivität genutzt.
Zielbild
Abschnitt betitelt „Zielbild“Kostensteuerung macht Cloud-Ausgaben über Migrationswellen und Regelbetrieb transparent, zurechenbar und aktiv steuerbar.
Für Migrations-Landing-Zones braucht es dafür ein gemeinsames finanzielles Steuerungsmodell über Plattformteams, Anwendungs-Teams und Business-Stakeholder hinweg.
Zentrale Bausteine der Kosten-Governance
Abschnitt betitelt „Zentrale Bausteine der Kosten-Governance“- Costs and Billing (zentrale Domäne): Nutzen Sie die Cost-and-Billing-Domäne als zentrale Grundlage für Kostentransparenz, Governance-Rollen und Reporting-Logik. Dokumentation
- Billing Accounts: Definieren Sie Billing Accounts als strukturelle Grenzen für Ownership, Abrechnung und finanzielle Verantwortlichkeit. Dokumentation
- FOCUS: Nutzen Sie das FOCUS-Modell zur Standardisierung und Normalisierung von Kostendaten für transparente Analysen und teamübergreifendes Finanz-Reporting. Dokumentation
- Resource Labeling: Erzwingen Sie konsistente Labels, um technische Nutzung verlässlich Teams, Produkten, Umgebungen und Kostenstellen-IDs zuzuordnen. Dokumentation
Zusammenspiel der Bausteine
Abschnitt betitelt „Zusammenspiel der Bausteine“- Finanzstruktur-Ebene: Billing Accounts legen fest, wo Kosten anfallen und wer dafür verantwortlich ist.
- Datenstandardisierungs-Ebene: FOCUS liefert ein konsistentes Kostenmodell über Services und Teams hinweg.
- Zuordnungs- und Ownership-Ebene: Resource Labels verbinden Cloud-Nutzung mit fachlicher und technischer Verantwortung.
- Betriebs-Ebene (FinOps): FinOps etabliert einen wiederkehrenden Zyklus aus Transparenz, Optimierungsmaßnahmen und Ownership-Tracking.
FinOps im Landing-Zone-Kontext
Abschnitt betitelt „FinOps im Landing-Zone-Kontext“FinOps sollte von Beginn an in das Landing-Zone-Design integriert werden und nicht erst nach dem Start von Migrationswellen.
- Transparenz: Gemeinsame Sichtbarkeit für Plattform-, Shared-Service- und Workload-Kosten aufbauen.
- Verantwortung: Klare Zuständigkeiten je Billing Account, Team und Service-Domäne festlegen.
- Optimierung: Ein aktives Optimierungs-Backlog mit regelmäßigem Review-Rhythmus betreiben.
- Governance: Budgetgrenzen und Eskalationswege mit benannten Verantwortlichen und Entscheider-Kreis verknüpfen.
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Grenzen der Zuordnung: Festlegen, wie Ausgaben auf Billing Accounts, Produkte, Teams und Umgebungen verteilt werden.
- Standardisierung der Daten: Entscheiden, wie FOCUS und interne Reporting-Dimensionen konsistent umgesetzt werden.
- Label-Strategie: Pflicht-Labels und Qualitätskontrollen für verlässliche Zuordnung und Chargeback/Showback definieren.
- Budget- und Eskalationsmodell: Schwellenwerte, Verantwortlichkeiten und Reaktions-Workflows festlegen.
- FinOps-Rhythmus: Review-Frequenz, Optimierungs-Governance und Nachverfolgung realisierter Einsparungen definieren.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Kostentaxonomie und Ownership-Modell: Standardisierte Zuordnung über Billing Accounts, Labels und verantwortliche Teams.
- Kosten-Reporting-Baseline: FOCUS-ausgerichtete finanzielle Sicht für Trendanalysen und Stakeholder-Reporting.
- Budget-Guardrails: Definierte Schwellwerte mit dokumentierter Eskalation und Entscheidungs-Ownership.
- FinOps-Betriebsmodell: Regelmäßiger Review-Rhythmus mit priorisiertem Optimierungs-Backlog und Outcome-Tracking.
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Keine Billing-Account-Strategie: Kosten sind nur aggregiert sichtbar und nicht klar verantwortbar.
- Inkonsistente oder fehlende Labels: Nutzung kann Produkten, Teams oder Umgebungen nicht verlässlich zugeordnet werden.
- Keine Standardisierung von Daten: Kostenübersichten unterscheiden sich je Team und sind nicht belastbar vergleichbar.
- FinOps nur als Reporting: Kein wiederkehrender Ablauf für Optimierung und keine Ownership für Verbesserungsmaßnahmen.
Zielbild
Abschnitt betitelt „Zielbild“Automatisierung stellt sicher, dass Landing-Zone-Funktionen reproduzierbar, versioniert und testbar bereitgestellt werden.
Für Migrations-Landing-Zones ist Automatisierung das Delivery-Rückgrat, das Plattform-APIs, IaC-Werkzeuge, Entwickler-Workflows und Release-Kontrollen in ein verlässliches Betriebsmodell überführt.
Kernbausteine der Automatisierung
Abschnitt betitelt „Kernbausteine der Automatisierung“- STACKIT API: Nutzen Sie die API als grundlegende Steuerungsschnittstelle für Plattformautomatisierung und Integrationsmuster. Dokumentation
- Terraform Provider: Nutzen Sie den offiziellen Provider für deklarative Infrastruktur-Bereitstellung und Lifecycle-Steuerung. Dokumentation
- OpenTofu Provider: Nutzen Sie OpenTofu mit dem STACKIT Provider als offene IaC-Option mit vergleichbaren deklarativen Workflows. Dokumentation
- Pulumi: Nutzen Sie Pulumi, wenn Teams für Infrastruktur-Automatisierung allgemeine Programmiersprachen bevorzugen. Dokumentation
- Ansible: Nutzen Sie Ansible primär für Post-Provisioning-Konfiguration und Betriebsaufgaben. In einem kombinierten Modell stellen Terraform/OpenTofu die Infrastruktur bereit, während Ansible OS- und Middleware-Konfiguration übernimmt.
- STACKIT CLI: Standardisieren Sie CLI-basierte Operationen für Skripting, Fehleranalyse und wiederholbare Betriebsaufgaben. Dokumentation
- SDKs (Go, Python, Java): Nutzen Sie SDKs für kundenspezifische Automatisierung und Service-Integrationen, wenn IaC-Abstraktionen nicht ausreichen. Go SDK , Python SDK , Java SDK .
- STACKIT Git: Nutzen Sie Git als Source of Truth für IaC-Module, Policies und Delivery-Workflows. Dokumentation
- CI/CD Pipeline: Nutzen Sie Pipelines für Validierung, Policy-Prüfungen, kontrollierte Promotion und auditierbare Releases. Dokumentation
- Container Registry: Nutzen Sie eine zentrale Registry für versionierte Build-Artefakte und konsistente Deployments über Umgebungen hinweg. Dokumentation
Wie die Bausteine zusammenspielen
Abschnitt betitelt „Wie die Bausteine zusammenspielen“- Steuerungsschicht: STACKIT API, CLI und SDKs liefern direkte und programmierbare Steuerungsschnittstellen.
- Provisioning-Schicht: Terraform/OpenTofu und Pulumi definieren und synchronisieren den gewünschten Infrastrukturzustand.
- Konfigurationsschicht: Ansible setzt Host- und Middleware-Konfiguration nach dem Infrastruktur-Provisioning um.
- Delivery-Schicht: Git und CI/CD Pipelines erzwingen Qualitäts-Gates, Policy-Prüfungen und kontrollierten Rollout über Umgebungen.
- Artefakt-Schicht: Die Container Registry liefert unveränderliche und versionierte Artefakte für vorhersehbare Deployments.
Delivery-Flow mit Terraform/OpenTofu und Ansible
Abschnitt betitelt „Delivery-Flow mit Terraform/OpenTofu und Ansible“Terraform oder OpenTofu und Ansible lösen unterschiedliche Aufgaben innerhalb eines Delivery-Flows. Halten Sie die Grenze explizit, damit Infrastrukturänderungen prüfbar und Host-Konfigurationen wiederholbar bleiben.
Terraform / OpenTofu
Verantwortet den Infrastruktur-Lifecycle: Projekte, Netzwerke, Sicherheitskontrollen, Compute, Storage, Managed Services und die für das Konfigurationsmanagement benötigten Outputs.
Ansible
Verantwortet die Konfiguration im erreichbaren Ziel: Betriebssystempakete, Middleware, Applikationsartefakte, Service Units und die Validierung auf Workload-Ebene.
- Versionieren Sie Infrastruktur-Inputs, Konfiguration und Referenzen auf Applikationsartefakte in Git.
- Validieren und prüfen Sie den Terraform/OpenTofu-Plan einschließlich Ersetzungen und Security-Auswirkungen.
- Wenden Sie den freigegebenen Plan an und übergeben Sie nur das von Ansible benötigte Zielinventar und die erforderlichen Outputs.
- Führen Sie Ansible idempotent aus, um Betriebssystem, Middleware, Workload und Telemetrie zu konfigurieren.
- Validieren Sie Infrastrukturzustand, Service Health und betriebliche Kontrollen und bewahren Sie die Nachweise auf.
- Promoten Sie denselben versionierten Workflow durch die Umgebungen, statt manuelle Einrichtungsschritte zu wiederholen.
Verwischen Sie die Zuständigkeit beider Ebenen nicht durch Provisioner oder Ad-hoc-Skripte. Ansible aus Terraform anzustoßen kann eine praktische Brücke sein, aber jedes Werkzeug muss eigenständig verständlich, testbar und wiederholbar bleiben.
Empfohlenes Betriebsmodell
Abschnitt betitelt „Empfohlenes Betriebsmodell“- Empfehlung 1: Nutzen Sie Git plus CI/CD als Standard-Steuerungspfad und vermeiden Sie direkte manuelle Änderungen in produktiven Scopes.
- Empfehlung 2: Wählen Sie je Plattformdomäne ein primäres IaC-Tool (Terraform oder OpenTofu), um Fragmentierung zu reduzieren.
- Empfehlung 3: Nutzen Sie Ansible für Konfigurationsmanagement, nicht als Ersatz für deklaratives Infrastruktur-Provisioning.
- Empfehlung 4: Nutzen Sie SDKs für domänenspezifische Automatisierung, wenn Provider-Ressourcen das gewünschte Verhalten nicht abdecken.
- Empfehlung 5: Versionieren und promoten Sie Container-Artefakte über klare Umgebungsstufen mit rollbackfähigen Tags.
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Automatisierungs-Schnittstellenstrategie: Definieren Sie, wo API, CLI, SDK und IaC-Werkzeuge als Primärschnittstellen eingesetzt werden.
- IaC-Tool-Strategie: Entscheiden Sie Terraform versus OpenTofu versus Pulumi anhand von Skills, Governance und Ecosystem-Fit.
- Modul- und Repository-Strategie: Definieren Sie wiederverwendbare Modulgrenzen, Versionierung und Ownership.
- Pipeline-Control-Modell: Implementieren Sie Validierung, Policy-Prüfungen, Freigaben und Promotion-Gates.
- Artefakt- und Release-Strategie: Definieren Sie Registry-Nutzung, Image-Versionierung und Rollback-Standards.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Wiederverwendbare Automatisierungs-Baseline: IaC-Module, Templates und Konfigurations-Playbooks mit Ownership-Modell.
- Delivery-Blueprint: CI/CD-Flow mit Qualitäts-Gates, Policy-Prüfungen und gestufter Promotion.
- Integrations-Toolkit: Standardisierte Nutzung von CLI- und SDK-Automatisierung für Betrieb und produktspezifische Workflows.
- Release-Baseline: Versionierter Artefakt-Lifecycle in der Container Registry mit rollbackfähigen Praktiken.
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Zu viele Automatisierungs-Paradigmen: Parallele Tool-Stacks ohne klare Ownership oder Governance-Modell.
- Provisioning und Konfiguration ad hoc vermischt: Keine klare Trennung zwischen IaC-Provisioning und Ansible-Konfiguration.
- Keine Artefakt-Disziplin: Veränderliche Container-Tags und unklare Release-Nachverfolgbarkeit.
- CLI-Skripte ohne Git- und Pipeline-Kontrollen: Betriebsautomatisierung ist nicht verlässlich auditierbar oder reproduzierbar.
Überblick: Platform Landing Zones
Abschnitt betitelt „Überblick: Platform Landing Zones“Die Platform Landing Zone ist die unternehmensweite Ziel-Basis für die Cloud-Nutzung auf STACKIT. Sie definiert die übergreifenden Kontrollen und Plattformleitplanken, die alle Produktteams übernehmen.
Ohne diese Basis entstehen häufig inkonsistente Sicherheitsniveaus, doppelte Architekturentscheidungen und verzögerte Freigaben in den Migrationswellen.
Kernfähigkeiten
Abschnitt betitelt „Kernfähigkeiten“Account Governance
Organisationen, Projekte und Umgebungen mit klaren Ownership-Grenzen strukturieren.
Identität und Zugriff
IAM-Modell, Rollenprinzipien, Least Privilege und Funktionstrennung festlegen.
Security und Compliance
Verbindliche Kontrollen, Logging, Nachweise und Policy-Durchsetzung etablieren.
Netzwerkarchitektur
Segmentierung, Konnektivitätsmuster und sichere Kommunikationsstandards definieren.
Kostensteuerung
Tagging, Budgetgrenzen, Chargeback/Showback und Kostentransparenz umsetzen.
Automatisierung
Die Basis konsistent per OpenTofu/Terraform-basierter Infrastructure as Code bereitstellen.
Typische Eingaben und Voraussetzungen
Abschnitt betitelt „Typische Eingaben und Voraussetzungen“- Organisationsmodell: Geschäftsbereiche, Ownership-Grenzen und Umgebungsstrategie.
- Regulatorische Vorgaben: Branchenanforderungen, Audit-Scope und Nachweispflichten.
- Security-Standards: Identitätsmodell, Verschlüsselungsstandards, Secret-Handling und Incident Response.
- Konnektivitätsanforderungen: On-Prem-, Partner-, Internet- und Service-Integrationen.
- Betriebsmodell-Vorgaben: Rollen, Eskalationswege und Übergabeschnittstellen.
Typische Umsetzungsreihenfolge
Abschnitt betitelt „Typische Umsetzungsreihenfolge“- Governance- und Kontrollziele mit Enterprise-Stakeholdern abstimmen.
- Plattform-Basis für Identität, Netzwerk, Security und Kostensteuerung designen.
- Baseline-Automatisierung und Policy-Leitplanken als wiederverwendbare Module implementieren.
- Kontrollen mit Pilot-Workloads validieren und Lücken schließen.
- Betrieb mit Ownership-Modell, Runbook-Standards und Change-Prozess verstetigen.
Designprinzipien
Abschnitt betitelt „Designprinzipien“- Erst standardisieren, dann Ausnahmen zulassen: Ausnahmen explizit, genehmigt und zeitlich befristet führen.
- Kontrollen automatisieren: Policies und Baseline als Code etablieren, um Drift zu reduzieren.
- Nachweise früh mitdenken: Compliance-Evidenz bereits im Plattformdesign berücksichtigen.
- Auf Skalierung auslegen: Von Beginn an mehrere Teams und Applikationsarten einplanen.
Überblick: Platform Landing Zones
Abschnitt betitelt „Überblick: Platform Landing Zones“Die Platform Landing Zone ist die unternehmensweite Ziel-Basis für die Cloud-Nutzung auf STACKIT. Sie definiert die übergreifenden Kontrollen und Plattformleitplanken, die alle Produktteams übernehmen.
Ohne diese Basis entstehen häufig inkonsistente Sicherheitsniveaus, doppelte Architekturentscheidungen und verzögerte Freigaben in den Migrationswellen.
Kernfähigkeiten
Abschnitt betitelt „Kernfähigkeiten“Account Governance
Organisationen, Projekte und Umgebungen mit klaren Ownership-Grenzen strukturieren.
Identität und Zugriff
IAM-Modell, Rollenprinzipien, Least Privilege und Funktionstrennung festlegen.
Security und Compliance
Verbindliche Kontrollen, Logging, Nachweise und Policy-Durchsetzung etablieren.
Netzwerkarchitektur
Segmentierung, Konnektivitätsmuster und sichere Kommunikationsstandards definieren.
Kostensteuerung
Tagging, Budgetgrenzen, Chargeback/Showback und Kostentransparenz umsetzen.
Automatisierung
Die Basis konsistent per OpenTofu/Terraform-basierter Infrastructure as Code bereitstellen.
Typische Eingaben und Voraussetzungen
Abschnitt betitelt „Typische Eingaben und Voraussetzungen“- Organisationsmodell: Geschäftsbereiche, Ownership-Grenzen und Umgebungsstrategie.
- Regulatorische Vorgaben: Branchenanforderungen, Audit-Scope und Nachweispflichten.
- Security-Standards: Identitätsmodell, Verschlüsselungsstandards, Secret-Handling und Incident Response.
- Konnektivitätsanforderungen: On-Prem-, Partner-, Internet- und Service-Integrationen.
- Betriebsmodell-Vorgaben: Rollen, Eskalationswege und Übergabeschnittstellen.
Typische Umsetzungsreihenfolge
Abschnitt betitelt „Typische Umsetzungsreihenfolge“- Governance- und Kontrollziele mit Enterprise-Stakeholdern abstimmen.
- Plattform-Basis für Identität, Netzwerk, Security und Kostensteuerung designen.
- Baseline-Automatisierung und Policy-Leitplanken als wiederverwendbare Module implementieren.
- Kontrollen mit Pilot-Workloads validieren und Lücken schließen.
- Betrieb mit Ownership-Modell, Runbook-Standards und Change-Prozess verstetigen.
Designprinzipien
Abschnitt betitelt „Designprinzipien“- Erst standardisieren, dann Ausnahmen zulassen: Ausnahmen explizit, genehmigt und zeitlich befristet führen.
- Kontrollen automatisieren: Policies und Baseline als Code etablieren, um Drift zu reduzieren.
- Nachweise früh mitdenken: Compliance-Evidenz bereits im Plattformdesign berücksichtigen.
- Auf Skalierung auslegen: Von Beginn an mehrere Teams und Applikationsarten einplanen.
Überblick: Platform Landing Zones
Abschnitt betitelt „Überblick: Platform Landing Zones“Die Platform Landing Zone ist die unternehmensweite Ziel-Basis für die Cloud-Nutzung auf STACKIT. Sie definiert die übergreifenden Kontrollen und Plattformleitplanken, die alle Produktteams übernehmen.
Ohne diese Basis entstehen häufig inkonsistente Sicherheitsniveaus, doppelte Architekturentscheidungen und verzögerte Freigaben in den Migrationswellen.
Kernfähigkeiten
Abschnitt betitelt „Kernfähigkeiten“Account Governance
Organisationen, Projekte und Umgebungen mit klaren Ownership-Grenzen strukturieren.
Identität und Zugriff
IAM-Modell, Rollenprinzipien, Least Privilege und Funktionstrennung festlegen.
Security und Compliance
Verbindliche Kontrollen, Logging, Nachweise und Policy-Durchsetzung etablieren.
Netzwerkarchitektur
Segmentierung, Konnektivitätsmuster und sichere Kommunikationsstandards definieren.
Kostensteuerung
Tagging, Budgetgrenzen, Chargeback/Showback und Kostentransparenz umsetzen.
Automatisierung
Die Basis konsistent per OpenTofu/Terraform-basierter Infrastructure as Code bereitstellen.
Typische Eingaben und Voraussetzungen
Abschnitt betitelt „Typische Eingaben und Voraussetzungen“- Organisationsmodell: Geschäftsbereiche, Ownership-Grenzen und Umgebungsstrategie.
- Regulatorische Vorgaben: Branchenanforderungen, Audit-Scope und Nachweispflichten.
- Security-Standards: Identitätsmodell, Verschlüsselungsstandards, Secret-Handling und Incident Response.
- Konnektivitätsanforderungen: On-Prem-, Partner-, Internet- und Service-Integrationen.
- Betriebsmodell-Vorgaben: Rollen, Eskalationswege und Übergabeschnittstellen.
Typische Umsetzungsreihenfolge
Abschnitt betitelt „Typische Umsetzungsreihenfolge“- Governance- und Kontrollziele mit Enterprise-Stakeholdern abstimmen.
- Plattform-Basis für Identität, Netzwerk, Security und Kostensteuerung designen.
- Baseline-Automatisierung und Policy-Leitplanken als wiederverwendbare Module implementieren.
- Kontrollen mit Pilot-Workloads validieren und Lücken schließen.
- Betrieb mit Ownership-Modell, Runbook-Standards und Change-Prozess verstetigen.
Designprinzipien
Abschnitt betitelt „Designprinzipien“- Erst standardisieren, dann Ausnahmen zulassen: Ausnahmen explizit, genehmigt und zeitlich befristet führen.
- Kontrollen automatisieren: Policies und Baseline als Code etablieren, um Drift zu reduzieren.
- Nachweise früh mitdenken: Compliance-Evidenz bereits im Plattformdesign berücksichtigen.
- Auf Skalierung auslegen: Von Beginn an mehrere Teams und Applikationsarten einplanen.
Überblick: Platform Landing Zones
Abschnitt betitelt „Überblick: Platform Landing Zones“Die Platform Landing Zone ist die unternehmensweite Ziel-Basis für die Cloud-Nutzung auf STACKIT. Sie definiert die übergreifenden Kontrollen und Plattformleitplanken, die alle Produktteams übernehmen.
Ohne diese Basis entstehen häufig inkonsistente Sicherheitsniveaus, doppelte Architekturentscheidungen und verzögerte Freigaben in den Migrationswellen.
Kernfähigkeiten
Abschnitt betitelt „Kernfähigkeiten“Account Governance
Organisationen, Projekte und Umgebungen mit klaren Ownership-Grenzen strukturieren.
Identität und Zugriff
IAM-Modell, Rollenprinzipien, Least Privilege und Funktionstrennung festlegen.
Security und Compliance
Verbindliche Kontrollen, Logging, Nachweise und Policy-Durchsetzung etablieren.
Netzwerkarchitektur
Segmentierung, Konnektivitätsmuster und sichere Kommunikationsstandards definieren.
Kostensteuerung
Tagging, Budgetgrenzen, Chargeback/Showback und Kostentransparenz umsetzen.
Automatisierung
Die Basis konsistent per OpenTofu/Terraform-basierter Infrastructure as Code bereitstellen.
Typische Eingaben und Voraussetzungen
Abschnitt betitelt „Typische Eingaben und Voraussetzungen“- Organisationsmodell: Geschäftsbereiche, Ownership-Grenzen und Umgebungsstrategie.
- Regulatorische Vorgaben: Branchenanforderungen, Audit-Scope und Nachweispflichten.
- Security-Standards: Identitätsmodell, Verschlüsselungsstandards, Secret-Handling und Incident Response.
- Konnektivitätsanforderungen: On-Prem-, Partner-, Internet- und Service-Integrationen.
- Betriebsmodell-Vorgaben: Rollen, Eskalationswege und Übergabeschnittstellen.
Typische Umsetzungsreihenfolge
Abschnitt betitelt „Typische Umsetzungsreihenfolge“- Governance- und Kontrollziele mit Enterprise-Stakeholdern abstimmen.
- Plattform-Basis für Identität, Netzwerk, Security und Kostensteuerung designen.
- Baseline-Automatisierung und Policy-Leitplanken als wiederverwendbare Module implementieren.
- Kontrollen mit Pilot-Workloads validieren und Lücken schließen.
- Betrieb mit Ownership-Modell, Runbook-Standards und Change-Prozess verstetigen.
Designprinzipien
Abschnitt betitelt „Designprinzipien“- Erst standardisieren, dann Ausnahmen zulassen: Ausnahmen explizit, genehmigt und zeitlich befristet führen.
- Kontrollen automatisieren: Policies und Baseline als Code etablieren, um Drift zu reduzieren.
- Nachweise früh mitdenken: Compliance-Evidenz bereits im Plattformdesign berücksichtigen.
- Auf Skalierung auslegen: Von Beginn an mehrere Teams und Applikationsarten einplanen.
R-Strategie mit dem Landing-Zone-Design verbinden
Leiten Sie aus der gewählten R-Strategie und Zielarchitektur jeder Anwendung die Landing-Zone-Fähigkeiten, Kontrollen, Connectivity und Service-Muster ab, die ihre Migration benötigt.
Ergebnis
Abschnitt betitelt „Ergebnis“Das Modul Design erstellt für jede in Discovery erfasste Anwendung ein ausführbares Design für die Migration. Es geht nicht um ein abstraktes Papier, sondern um ein konkretes Paket, das eine Migration Factory stabil umsetzen kann.
Zielbild je Anwendung
Definiert Zielarchitektur, Service-Auswahl, Integrationsansatz und Randbedingungen im STACKIT Kontext.
R-Strategie-Entscheidungsnachweis
Dokumentiert die gewählte Migrationsstrategie und begründet, warum Alternativen verworfen wurden.
Factory-fähiges Migrations-Runbook
Liefert eine Schritt-für-Schritt-Anleitung mit Rückfallpfad und Validierungspunkten.
Handover-Paket
Übergibt alle benötigten Ergebnisse an Migration Factory Setup, Landing Zone und Migrationsplan.
Abgrenzung
Abschnitt betitelt „Abgrenzung“Die Module sind stark verzahnt, haben aber unterschiedliche Aufgaben:
Design (dieses Modul)
Entscheidet pro Anwendung Zielbild und Migrationsstrategie und erstellt ausführbare Runbooks.
Migration Factory Setup
Ermöglicht die Umsetzung durch Auswahl und Vorbereitung des passenden Factory-Modells, Partners und Werkzeugkastens.
Landing Zone
Liefert die Plattform-Grundlage und Governance Controls, die im Zielbild berücksichtigt werden müssen.
Migrationsplan
Überführt fertige Designs in realistische Wellen, Reihenfolgen, Abhängigkeiten und Meilensteine.
Methode
Abschnitt betitelt „Methode“Die R-Strategie-Methodik ist das zentrale Modell in diesem Modul. Für jede Anwendung muss die gewählte Strategie mit Architektur-, Business-, Risiko- und Argumenten für den Betrieb belegt werden.
Entscheidungskriterien je R-Strategie
Abschnitt betitelt „Entscheidungskriterien je R-Strategie“- Relocate: Sinnvoll, wenn eine schnelle Überführung von Virtualisierungs-Stacks möglich ist; je nach Wellenumfang tool-gestützt oder kontrolliert manuell ausführen.
- Rehost: Sinnvoll bei geringer Veränderungstoleranz und engem Zeitrahmen, wenn Geschwindigkeit vor sofortiger Modernisierung steht.
- Replatform: Sinnvoll, wenn begrenzte Anpassungen über die STACKIT Plattform klare Vorteile in Betrieb, Skalierung oder Kosten bringen.
- Repurchase: Sinnvoll für passende Angebote im STACKIT Ökosystem, in dieser Phase gezielt für Workspace by STACKIT, ServiceNow, RISE with SAP on STACKIT und STACKIT Domain Solutions.
- Refactor: Sinnvoll für strategische Anwendungen, wenn eine cloud-native Überarbeitung klaren Mehrwert in Agilität, Resilienz oder Kosten schafft.
- Retain: Retain bei zeitlichen, technischen oder Governance-Hürden in der aktuellen Welle.
- Retire: Retire bei fehlendem Geschäftswert im Verhältnis zum Betriebsaufwand.
Zentrale Schritte im Diagramm
Abschnitt betitelt „Zentrale Schritte im Diagramm“Das Diagramm ist nicht nur eine Visualisierung. Es ist der Referenzablauf für die Übergabe zwischen Modulen und für die zentralen Design-Governance-Checkpoints.
1. Discovery Input
Abschnitt betitelt „1. Discovery Input“Ausgangslage und Randbedingungen absichern: fachlicher Kontext, Workload-Inventar, Abhängigkeiten und Restriktionen für die folgenden Design-Entscheidungen.
2. Bewerten und priorisieren
Abschnitt betitelt „2. Bewerten und priorisieren“Kandidaten für das Design nach Kritikalität, Risiko, Aufwand und Eignung für Wellen priorisieren. Dieser Schritt steuert, wo Design-Kapazität zuerst eingesetzt wird.
3. Determine migration path
Abschnitt betitelt „3. Determine migration path“Die passende R-Strategie je Anwendung festlegen und in den jeweiligen Design-Pfad verzweigen (Relocate, Rehost, Replatform, Repurchase, Refactor, Retain oder Retire).
4. Validation
Abschnitt betitelt „4. Validation“Alle Design-Pfade in einem gemeinsamen Qualitäts-Gate betrachten. Annahmen zur Architektur, Security/Compliance, Runbook-Qualität und Betriebsreife validieren.
5. Transition
Abschnitt betitelt „5. Transition“Die kontrollierte Übergabe in den Migrationslauf vorbereiten: Release-Reife, Wellen-Fit, Koordinationsfenster und klare Übergabe der Verantwortung.
6. Production
Abschnitt betitelt „6. Production“Kriterien für den Produktiv-Handover und die Day-1-Betriebsbasis nach erfolgreicher Transition finalisieren. Damit ist der im Diagramm dargestellte Design-Prozess abgeschlossen.
Zielbild
Abschnitt betitelt „Zielbild“- Scope und Baseline aus Discovery bestätigen (Abhängigkeiten, Nutzung, Kritikalität, Restriktionen).
- Fachliche und technische Designziele festlegen, inklusive Verfügbarkeit, Security, Compliance und Performance.
- R-Strategie-Optionen gegen klare Kriterien bewerten und die gewählte Strategie begründet dokumentieren.
- Zielbild auf STACKIT Produkte und Plattform-Fähigkeiten abbilden, inklusive Netzwerk, Identität, Daten und Betrieb.
- Migrationsvorgehen spezifizieren (Cutover-Ansatz, Datenumzug, Integrationswechsel, Rückfallstrategie).
- Ausführbares Runbook für die Factory mit Aufgaben, Qualitätschecks und Abnahmekriterien erstellen.
- Design-Annahmen mit Architektur, Security, Plattform und Business-Ownern validieren.
- Freigegebenes Designpaket an Migration Factory Setup und Migrationsplan übergeben.
Mindestens folgende Inhalte sollten je Anwendung vorliegen:
- Zielarchitektur-Definition: Workload-Platzierung, Service-Mapping, Modell für Integrationen und nicht-funktionale Anforderungen.
- R-Strategie-Entscheidungsnachweis: Gewählte Strategie, Kriterien, geprüfte Alternativen und Haupt-Risiken.
- Migrations-Runbook: Reihenfolge der Ausführung, Checks vor dem Lauf, Rückfallpfad, Validierung und Go-live-Kriterien.
- Abhängigkeiten und Schnittstellen: Bedarf für Koordination mit vor- und nachgelagerten Systemen und Übergangsfenstern.
- Compliance- und Security-Controls: Verpflichtende Controls und Nachweise für Release-Reife.
Nutzen Sie die dedizierte Pattern-Seite, um vor Auswahl des Migrations-Runbooks ein klares Zielbild zu definieren.
Workload-Use-Case-Sicht für Migrationsvarianten
Abschnitt betitelt „Workload-Use-Case-Sicht für Migrationsvarianten“Nutzen Sie ergänzend zur R-Strategie die Workload-Sicht, um zu klassifizieren, was migriert wird, und um machbare Umsetzungsvarianten mit expliziten Rahmenbedingungen auszuwählen.
KI-gestützte Design-Assets
Abschnitt betitelt „KI-gestützte Design-Assets“KI-gestützte Design-Assets unterstützen Architekten dabei, Anwendungsanforderungen, Services aus der Ausgangslage und R-Strategie-Optionen in prüfbare Zielbildvorschläge zu überführen. Die Ergebnisse dienen als Input für Architektur-, Security-, Plattform- und Business-Validierung, bevor ein Migrationspfad freigegeben wird.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Runbook-Assets
Abschnitt betitelt „Runbook-Assets“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Wirkung
Abschnitt betitelt „Wirkung“Die Qualität der Migrationsplanung hängt direkt von der Design-Qualität ab. Reihenfolge der Wellen, Factory-Durchsatz und Liefer-Risiko werden durch die Präzision der Zielentwürfe und Ablaufpläne bestimmt. Unvollständige Designs führen in der Praxis zu instabilen Wellen und Verzögerungen.
Application Landing Zones
Überblick: Application Landing Zones
Abschnitt betitelt „Überblick: Application Landing Zones“Eine Application Landing Zone ist ein workload-spezifisches Umsetzungsprofil, das aus der Platform-Landing-Zone-Basis abgeleitet wird.
Sie übersetzt unternehmensweite Leitplanken in konkrete Muster für Applikationstypen, zum Beispiel VM-basierte Rehost-Szenarien, Container-Workloads oder datenintensive Plattformen.
Warum sie von Discovery abhängt
Abschnitt betitelt „Warum sie von Discovery abhängt“Application Landing Zones werden nicht isoliert entworfen. Sie benötigen validierte Discovery-Eingaben zu Abhängigkeiten, Datenklassifizierung, Laufzeitverhalten und betrieblichen Randbedingungen.
Typische Discovery-getriebene Eingaben:
- Abhängigkeitsprofil: Ein- und ausgehende Kommunikationspfade sowie Vertrauensgrenzen.
- Laufzeitprofil: Ressourcenverhalten, Verfügbarkeitsanforderungen und Skalierungsmuster.
- Daten- und Compliance-Profil: Klassifizierung, Aufbewahrung und Kontrollpflichten.
- Migrationsstrategie-Fit: Rehost-, Replatform- oder Refactor-Randbedingungen je Workload.
Typische Muster für Application Landing Zones
Abschnitt betitelt „Typische Muster für Application Landing Zones“Rehost-fähiges Muster
Zielprofil mit minimalen Änderungen für VM-basierte Workloads unter zentralen Kontrollen.
Container-Plattform-Muster
Segmentiertes, policy-gesteuertes Setup für Kubernetes-basierte Workload-Gruppen.
Daten-Workload-Muster
Landing-Zone-Profil für Datendienste, Integrationspfade und strengere Kontrollen.
Shared-Service-Muster
Isoliertes Setup für Basisdienste, die von mehreren Produktteams genutzt werden.
Vorgehen
Abschnitt betitelt „Vorgehen“- Workload-Archetypen aus Discovery-Ergebnissen und Zielstrategie klassifizieren.
- Plattform-Basiskontrollen je Archetyp abbilden und kontrollierte Abweichungen identifizieren.
- Wiederverwendbare IaC-Templates und Policy-Sets pro Landing-Zone-Profil erstellen.
- Mit Pilot-Workloads und produktionsnahen Cutover-Szenarien validieren.
- Templates, Runbooks und Onboarding-Leitfäden für Migrationswellen veröffentlichen.
Best Practices
Abschnitt betitelt „Best Practices“- Templates vor Einzellösungen: Wiederverwendbare Muster beschleunigen Migrationswellen.
- Abweichungen explizit dokumentieren: Risiko, Owner und Ablaufdatum transparent halten.
- Mit der Migration Factory verzahnen: Landing-Zone-Muster in Wellen-Runbooks integrieren.
- Kontinuierlich verbessern: Erkenntnisse aus Migrate und Run in den Template-Backlog zurückführen.
Überblick: Application Landing Zones
Abschnitt betitelt „Überblick: Application Landing Zones“Eine Application Landing Zone ist ein workload-spezifisches Umsetzungsprofil, das aus der Platform-Landing-Zone-Basis abgeleitet wird.
Sie übersetzt unternehmensweite Leitplanken in konkrete Muster für Applikationstypen, zum Beispiel VM-basierte Rehost-Szenarien, Container-Workloads oder datenintensive Plattformen.
Warum sie von Discovery abhängt
Abschnitt betitelt „Warum sie von Discovery abhängt“Application Landing Zones werden nicht isoliert entworfen. Sie benötigen validierte Discovery-Eingaben zu Abhängigkeiten, Datenklassifizierung, Laufzeitverhalten und betrieblichen Randbedingungen.
Typische Discovery-getriebene Eingaben:
- Abhängigkeitsprofil: Ein- und ausgehende Kommunikationspfade sowie Vertrauensgrenzen.
- Laufzeitprofil: Ressourcenverhalten, Verfügbarkeitsanforderungen und Skalierungsmuster.
- Daten- und Compliance-Profil: Klassifizierung, Aufbewahrung und Kontrollpflichten.
- Migrationsstrategie-Fit: Rehost-, Replatform- oder Refactor-Randbedingungen je Workload.
Typische Muster für Application Landing Zones
Abschnitt betitelt „Typische Muster für Application Landing Zones“Rehost-fähiges Muster
Zielprofil mit minimalen Änderungen für VM-basierte Workloads unter zentralen Kontrollen.
Container-Plattform-Muster
Segmentiertes, policy-gesteuertes Setup für Kubernetes-basierte Workload-Gruppen.
Daten-Workload-Muster
Landing-Zone-Profil für Datendienste, Integrationspfade und strengere Kontrollen.
Shared-Service-Muster
Isoliertes Setup für Basisdienste, die von mehreren Produktteams genutzt werden.
Vorgehen
Abschnitt betitelt „Vorgehen“- Workload-Archetypen aus Discovery-Ergebnissen und Zielstrategie klassifizieren.
- Plattform-Basiskontrollen je Archetyp abbilden und kontrollierte Abweichungen identifizieren.
- Wiederverwendbare IaC-Templates und Policy-Sets pro Landing-Zone-Profil erstellen.
- Mit Pilot-Workloads und produktionsnahen Cutover-Szenarien validieren.
- Templates, Runbooks und Onboarding-Leitfäden für Migrationswellen veröffentlichen.
Best Practices
Abschnitt betitelt „Best Practices“- Templates vor Einzellösungen: Wiederverwendbare Muster beschleunigen Migrationswellen.
- Abweichungen explizit dokumentieren: Risiko, Owner und Ablaufdatum transparent halten.
- Mit der Migration Factory verzahnen: Landing-Zone-Muster in Wellen-Runbooks integrieren.
- Kontinuierlich verbessern: Erkenntnisse aus Migrate und Run in den Template-Backlog zurückführen.
Überblick: Application Landing Zones
Abschnitt betitelt „Überblick: Application Landing Zones“Eine Application Landing Zone ist ein workload-spezifisches Umsetzungsprofil, das aus der Platform-Landing-Zone-Basis abgeleitet wird.
Sie übersetzt unternehmensweite Leitplanken in konkrete Muster für Applikationstypen, zum Beispiel VM-basierte Rehost-Szenarien, Container-Workloads oder datenintensive Plattformen.
Warum sie von Discovery abhängt
Abschnitt betitelt „Warum sie von Discovery abhängt“Application Landing Zones werden nicht isoliert entworfen. Sie benötigen validierte Discovery-Eingaben zu Abhängigkeiten, Datenklassifizierung, Laufzeitverhalten und betrieblichen Randbedingungen.
Typische Discovery-getriebene Eingaben:
- Abhängigkeitsprofil: Ein- und ausgehende Kommunikationspfade sowie Vertrauensgrenzen.
- Laufzeitprofil: Ressourcenverhalten, Verfügbarkeitsanforderungen und Skalierungsmuster.
- Daten- und Compliance-Profil: Klassifizierung, Aufbewahrung und Kontrollpflichten.
- Migrationsstrategie-Fit: Rehost-, Replatform- oder Refactor-Randbedingungen je Workload.
Typische Muster für Application Landing Zones
Abschnitt betitelt „Typische Muster für Application Landing Zones“Rehost-fähiges Muster
Zielprofil mit minimalen Änderungen für VM-basierte Workloads unter zentralen Kontrollen.
Container-Plattform-Muster
Segmentiertes, policy-gesteuertes Setup für Kubernetes-basierte Workload-Gruppen.
Daten-Workload-Muster
Landing-Zone-Profil für Datendienste, Integrationspfade und strengere Kontrollen.
Shared-Service-Muster
Isoliertes Setup für Basisdienste, die von mehreren Produktteams genutzt werden.
Vorgehen
Abschnitt betitelt „Vorgehen“- Workload-Archetypen aus Discovery-Ergebnissen und Zielstrategie klassifizieren.
- Plattform-Basiskontrollen je Archetyp abbilden und kontrollierte Abweichungen identifizieren.
- Wiederverwendbare IaC-Templates und Policy-Sets pro Landing-Zone-Profil erstellen.
- Mit Pilot-Workloads und produktionsnahen Cutover-Szenarien validieren.
- Templates, Runbooks und Onboarding-Leitfäden für Migrationswellen veröffentlichen.
Best Practices
Abschnitt betitelt „Best Practices“- Templates vor Einzellösungen: Wiederverwendbare Muster beschleunigen Migrationswellen.
- Abweichungen explizit dokumentieren: Risiko, Owner und Ablaufdatum transparent halten.
- Mit der Migration Factory verzahnen: Landing-Zone-Muster in Wellen-Runbooks integrieren.
- Kontinuierlich verbessern: Erkenntnisse aus Migrate und Run in den Template-Backlog zurückführen.
Überblick: Discovery
Abschnitt betitelt „Überblick: Discovery“Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.
Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.
Zentrale Ziele
Abschnitt betitelt „Zentrale Ziele“Vollständige Basis
Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.
Transparente Abhängigkeiten
Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.
Business-Abgleich
Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.
Planungsreife
Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.
Was Discovery typischerweise erfasst
Abschnitt betitelt „Was Discovery typischerweise erfasst“Inventarisierung
Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.
Abhängigkeitsanalyse
Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.
Ressourcennutzung
Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.
Betriebskontext
Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.
Input der Application Owner
Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.
Typisches Vorgehen
Abschnitt betitelt „Typisches Vorgehen“In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.
Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.
Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.
Zwei Evidence-Streams: technisch vs. human-driven
Abschnitt betitelt „Zwei Evidence-Streams: technisch vs. human-driven“Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:
- Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
- Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.
Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.
Discovery-Prozess auf einen Blick
Abschnitt betitelt „Discovery-Prozess auf einen Blick“Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.
Typische Analyse-Muster im Discovery-Tooling
Abschnitt betitelt „Typische Analyse-Muster im Discovery-Tooling“Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:
- Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
- Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
- Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
- Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
- Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
- Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
- Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.
Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.
KI-gestützte Discovery-Assets
Abschnitt betitelt „KI-gestützte Discovery-Assets“KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Methodik in der Praxis
Abschnitt betitelt „Methodik in der Praxis“- Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
- Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
- Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
- Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
- Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
- Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.
Warum Discovery kritisch ist
Abschnitt betitelt „Warum Discovery kritisch ist“- Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
- Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
- Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
- Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
- Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.
Relevanz für nachgelagerte Module
Abschnitt betitelt „Relevanz für nachgelagerte Module“Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:
Design
Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.
Security und Compliance
Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.
Landing Zone
Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.
Migrationsplan
Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.
Operating Model und Business Case
Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.
Ergebnisse aus Discovery
Abschnitt betitelt „Ergebnisse aus Discovery“Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:
- Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
- Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
- Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
- Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
- Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.
Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.
Überblick: Application Landing Zones
Abschnitt betitelt „Überblick: Application Landing Zones“Eine Application Landing Zone ist ein workload-spezifisches Umsetzungsprofil, das aus der Platform-Landing-Zone-Basis abgeleitet wird.
Sie übersetzt unternehmensweite Leitplanken in konkrete Muster für Applikationstypen, zum Beispiel VM-basierte Rehost-Szenarien, Container-Workloads oder datenintensive Plattformen.
Warum sie von Discovery abhängt
Abschnitt betitelt „Warum sie von Discovery abhängt“Application Landing Zones werden nicht isoliert entworfen. Sie benötigen validierte Discovery-Eingaben zu Abhängigkeiten, Datenklassifizierung, Laufzeitverhalten und betrieblichen Randbedingungen.
Typische Discovery-getriebene Eingaben:
- Abhängigkeitsprofil: Ein- und ausgehende Kommunikationspfade sowie Vertrauensgrenzen.
- Laufzeitprofil: Ressourcenverhalten, Verfügbarkeitsanforderungen und Skalierungsmuster.
- Daten- und Compliance-Profil: Klassifizierung, Aufbewahrung und Kontrollpflichten.
- Migrationsstrategie-Fit: Rehost-, Replatform- oder Refactor-Randbedingungen je Workload.
Typische Muster für Application Landing Zones
Abschnitt betitelt „Typische Muster für Application Landing Zones“Rehost-fähiges Muster
Zielprofil mit minimalen Änderungen für VM-basierte Workloads unter zentralen Kontrollen.
Container-Plattform-Muster
Segmentiertes, policy-gesteuertes Setup für Kubernetes-basierte Workload-Gruppen.
Daten-Workload-Muster
Landing-Zone-Profil für Datendienste, Integrationspfade und strengere Kontrollen.
Shared-Service-Muster
Isoliertes Setup für Basisdienste, die von mehreren Produktteams genutzt werden.
Vorgehen
Abschnitt betitelt „Vorgehen“- Workload-Archetypen aus Discovery-Ergebnissen und Zielstrategie klassifizieren.
- Plattform-Basiskontrollen je Archetyp abbilden und kontrollierte Abweichungen identifizieren.
- Wiederverwendbare IaC-Templates und Policy-Sets pro Landing-Zone-Profil erstellen.
- Mit Pilot-Workloads und produktionsnahen Cutover-Szenarien validieren.
- Templates, Runbooks und Onboarding-Leitfäden für Migrationswellen veröffentlichen.
Best Practices
Abschnitt betitelt „Best Practices“- Templates vor Einzellösungen: Wiederverwendbare Muster beschleunigen Migrationswellen.
- Abweichungen explizit dokumentieren: Risiko, Owner und Ablaufdatum transparent halten.
- Mit der Migration Factory verzahnen: Landing-Zone-Muster in Wellen-Runbooks integrieren.
- Kontinuierlich verbessern: Erkenntnisse aus Migrate und Run in den Template-Backlog zurückführen.
Überblick: Application Landing Zones
Abschnitt betitelt „Überblick: Application Landing Zones“Eine Application Landing Zone ist ein workload-spezifisches Umsetzungsprofil, das aus der Platform-Landing-Zone-Basis abgeleitet wird.
Sie übersetzt unternehmensweite Leitplanken in konkrete Muster für Applikationstypen, zum Beispiel VM-basierte Rehost-Szenarien, Container-Workloads oder datenintensive Plattformen.
Warum sie von Discovery abhängt
Abschnitt betitelt „Warum sie von Discovery abhängt“Application Landing Zones werden nicht isoliert entworfen. Sie benötigen validierte Discovery-Eingaben zu Abhängigkeiten, Datenklassifizierung, Laufzeitverhalten und betrieblichen Randbedingungen.
Typische Discovery-getriebene Eingaben:
- Abhängigkeitsprofil: Ein- und ausgehende Kommunikationspfade sowie Vertrauensgrenzen.
- Laufzeitprofil: Ressourcenverhalten, Verfügbarkeitsanforderungen und Skalierungsmuster.
- Daten- und Compliance-Profil: Klassifizierung, Aufbewahrung und Kontrollpflichten.
- Migrationsstrategie-Fit: Rehost-, Replatform- oder Refactor-Randbedingungen je Workload.
Typische Muster für Application Landing Zones
Abschnitt betitelt „Typische Muster für Application Landing Zones“Rehost-fähiges Muster
Zielprofil mit minimalen Änderungen für VM-basierte Workloads unter zentralen Kontrollen.
Container-Plattform-Muster
Segmentiertes, policy-gesteuertes Setup für Kubernetes-basierte Workload-Gruppen.
Daten-Workload-Muster
Landing-Zone-Profil für Datendienste, Integrationspfade und strengere Kontrollen.
Shared-Service-Muster
Isoliertes Setup für Basisdienste, die von mehreren Produktteams genutzt werden.
Vorgehen
Abschnitt betitelt „Vorgehen“- Workload-Archetypen aus Discovery-Ergebnissen und Zielstrategie klassifizieren.
- Plattform-Basiskontrollen je Archetyp abbilden und kontrollierte Abweichungen identifizieren.
- Wiederverwendbare IaC-Templates und Policy-Sets pro Landing-Zone-Profil erstellen.
- Mit Pilot-Workloads und produktionsnahen Cutover-Szenarien validieren.
- Templates, Runbooks und Onboarding-Leitfäden für Migrationswellen veröffentlichen.
Best Practices
Abschnitt betitelt „Best Practices“- Templates vor Einzellösungen: Wiederverwendbare Muster beschleunigen Migrationswellen.
- Abweichungen explizit dokumentieren: Risiko, Owner und Ablaufdatum transparent halten.
- Mit der Migration Factory verzahnen: Landing-Zone-Muster in Wellen-Runbooks integrieren.
- Kontinuierlich verbessern: Erkenntnisse aus Migrate und Run in den Template-Backlog zurückführen.
Landing Zone Accelerator vorstellen
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Platform-Basis etablieren
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Mit einer Standalone-Basis starten
Wählen Sie die kleinste Accelerator-Topologie, wenn Workloads unabhängige Netzwerke und direkten Internetzugang ohne gemeinsame private Connectivity benötigen.
Corporate Workloads privat verbinden
Führen Sie ein zentrales Connectivity-Projekt, eine gemeinsame Network Area und DNS ein, wenn Corporate Workloads private Ost-West-Kommunikation benötigen.
Egress-Inspektion zentralisieren
Erweitern Sie Hub-and-Spoke um eine OPNsense-Firewall, wenn Corporate Traffic einen einheitlichen Inspektionspunkt und kontrollierten Egress-Pfad benötigt.
Business-Unit-Domänen trennen
Geben Sie Finance und Research unabhängige Ownership, Adresspläne, Connectivity-Projekte und private Workload-Domänen innerhalb einer Organisation.
Regulierte und gemeinsame Workloads trennen
Erstellen Sie getrennte Network Areas und DNS-Zonen, wenn zwischen regulierten und gemeinsamen Workloads kein implizites privates Routing bestehen darf.
Unabhängige regionale Hubs aufbauen
Stellen Sie isolierte Basen in eu01 und eu02 bereit, wenn regionale Workloads eigene Connectivity-, Landing-Zone- und Plattformgrenzen benötigen.
Produktion von Nicht-Produktion isolieren
Nutzen Sie getrennte Network Areas und Firewalls, wenn Produktion eine stärkere Grenze benötigt, während Development und Test eine Nicht-Produktions-Domäne teilen können.
Mandanten-Connectivity isolieren
Erstellen Sie unabhängige Ownership, Adresspläne und private Connectivity-Domänen, wenn mehrere Mandanten eine Organisation teilen, aber nicht untereinander routen dürfen.
Application-Umgebungen bereitstellen
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Ü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:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- 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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Managed Landing Zone Service vorstellen
Service
Managed Landing Zone Service
STACKIT
Migration design-and-mobilize landing-zone managed-service opentofu terragrunt
STACKIT
Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.
Übersicht
Abschnitt betitelt „Übersicht“Dieses Managed Asset baut auf der STACKIT Landing Zone Foundation auf und ergänzt sie um strukturierte Beratung, Setup-Unterstützung und Umsetzungsbegleitung als Service.
Es richtet sich an Organisationen, die sowohl technische Beschleuniger als auch methodische Delivery-Governance für eine produktionsreife Cloud-Basis benötigen.
Leistungsumfang
Abschnitt betitelt „Leistungsumfang“- Beratung und Zieldesign: Definition von Scope, Kontrollmodell und Rollout-Vorgehen.
- Katalogbasierte Umsetzung: Strukturierter Aufbau entlang vordefinierter Fähigkeits- und Kontrollkataloge.
- Technische Befähigung: Umsetzungsunterstützung mit OpenTofu,
Terragruntund Boilerplate-Mustern. - Betriebsübergabe: Übergabe in das Kunden-Betriebsmodell mit klar dokumentierten Verantwortlichkeiten.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Steuerbare Plattform-Basis: Pflichtkontrollen und Ownership-Grenzen sind wirksam umgesetzt.
- Wiederverwendbarer Automatisierungs-Stack: IaC-Module und Konventionen sind standardisiert.
- Schnellere Migrations-Readiness: Produktive Wellen können ohne zentrale Plattform-Blocker starten.
- Reduziertes Umsetzungsrisiko: Plattform-, Security- und Applikationsteams arbeiten auf einem Modell.
Engagement-Modell
Abschnitt betitelt „Engagement-Modell“Typischerweise erfolgt die Umsetzung in enger Zusammenarbeit mit Plattform-, Security- und Applikations-Stakeholdern. Der Service kann als fokussierte Setup-Initiative oder als Teil einer Migration Factory bereitgestellt werden.
Übersicht
Abschnitt betitelt „Übersicht“Dieses Managed Asset baut auf der STACKIT Landing Zone Foundation auf und ergänzt sie um strukturierte Beratung, Setup-Unterstützung und Umsetzungsbegleitung als Service.
Es richtet sich an Organisationen, die sowohl technische Beschleuniger als auch methodische Delivery-Governance für eine produktionsreife Cloud-Basis benötigen.
Leistungsumfang
Abschnitt betitelt „Leistungsumfang“- Beratung und Zieldesign: Definition von Scope, Kontrollmodell und Rollout-Vorgehen.
- Katalogbasierte Umsetzung: Strukturierter Aufbau entlang vordefinierter Fähigkeits- und Kontrollkataloge.
- Technische Befähigung: Umsetzungsunterstützung mit OpenTofu,
Terragruntund Boilerplate-Mustern. - Betriebsübergabe: Übergabe in das Kunden-Betriebsmodell mit klar dokumentierten Verantwortlichkeiten.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Steuerbare Plattform-Basis: Pflichtkontrollen und Ownership-Grenzen sind wirksam umgesetzt.
- Wiederverwendbarer Automatisierungs-Stack: IaC-Module und Konventionen sind standardisiert.
- Schnellere Migrations-Readiness: Produktive Wellen können ohne zentrale Plattform-Blocker starten.
- Reduziertes Umsetzungsrisiko: Plattform-, Security- und Applikationsteams arbeiten auf einem Modell.
Engagement-Modell
Abschnitt betitelt „Engagement-Modell“Typischerweise erfolgt die Umsetzung in enger Zusammenarbeit mit Plattform-, Security- und Applikations-Stakeholdern. Der Service kann als fokussierte Setup-Initiative oder als Teil einer Migration Factory bereitgestellt werden.
Übersicht
Abschnitt betitelt „Übersicht“Dieses Managed Asset baut auf der STACKIT Landing Zone Foundation auf und ergänzt sie um strukturierte Beratung, Setup-Unterstützung und Umsetzungsbegleitung als Service.
Es richtet sich an Organisationen, die sowohl technische Beschleuniger als auch methodische Delivery-Governance für eine produktionsreife Cloud-Basis benötigen.
Leistungsumfang
Abschnitt betitelt „Leistungsumfang“- Beratung und Zieldesign: Definition von Scope, Kontrollmodell und Rollout-Vorgehen.
- Katalogbasierte Umsetzung: Strukturierter Aufbau entlang vordefinierter Fähigkeits- und Kontrollkataloge.
- Technische Befähigung: Umsetzungsunterstützung mit OpenTofu,
Terragruntund Boilerplate-Mustern. - Betriebsübergabe: Übergabe in das Kunden-Betriebsmodell mit klar dokumentierten Verantwortlichkeiten.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Steuerbare Plattform-Basis: Pflichtkontrollen und Ownership-Grenzen sind wirksam umgesetzt.
- Wiederverwendbarer Automatisierungs-Stack: IaC-Module und Konventionen sind standardisiert.
- Schnellere Migrations-Readiness: Produktive Wellen können ohne zentrale Plattform-Blocker starten.
- Reduziertes Umsetzungsrisiko: Plattform-, Security- und Applikationsteams arbeiten auf einem Modell.
Engagement-Modell
Abschnitt betitelt „Engagement-Modell“Typischerweise erfolgt die Umsetzung in enger Zusammenarbeit mit Plattform-, Security- und Applikations-Stakeholdern. Der Service kann als fokussierte Setup-Initiative oder als Teil einer Migration Factory bereitgestellt werden.
Übersicht
Abschnitt betitelt „Übersicht“Dieses Managed Asset baut auf der STACKIT Landing Zone Foundation auf und ergänzt sie um strukturierte Beratung, Setup-Unterstützung und Umsetzungsbegleitung als Service.
Es richtet sich an Organisationen, die sowohl technische Beschleuniger als auch methodische Delivery-Governance für eine produktionsreife Cloud-Basis benötigen.
Leistungsumfang
Abschnitt betitelt „Leistungsumfang“- Beratung und Zieldesign: Definition von Scope, Kontrollmodell und Rollout-Vorgehen.
- Katalogbasierte Umsetzung: Strukturierter Aufbau entlang vordefinierter Fähigkeits- und Kontrollkataloge.
- Technische Befähigung: Umsetzungsunterstützung mit OpenTofu,
Terragruntund Boilerplate-Mustern. - Betriebsübergabe: Übergabe in das Kunden-Betriebsmodell mit klar dokumentierten Verantwortlichkeiten.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Steuerbare Plattform-Basis: Pflichtkontrollen und Ownership-Grenzen sind wirksam umgesetzt.
- Wiederverwendbarer Automatisierungs-Stack: IaC-Module und Konventionen sind standardisiert.
- Schnellere Migrations-Readiness: Produktive Wellen können ohne zentrale Plattform-Blocker starten.
- Reduziertes Umsetzungsrisiko: Plattform-, Security- und Applikationsteams arbeiten auf einem Modell.
Engagement-Modell
Abschnitt betitelt „Engagement-Modell“Typischerweise erfolgt die Umsetzung in enger Zusammenarbeit mit Plattform-, Security- und Applikations-Stakeholdern. Der Service kann als fokussierte Setup-Initiative oder als Teil einer Migration Factory bereitgestellt werden.
meshStack vereinfacht das Management von Landing Zones
Architektur
Abschnitt betitelt „Architektur“
Übersicht
Abschnitt betitelt „Übersicht“Der STACKIT Landing Zone Accelerator stellt die Plattform-Basis als Code bereit. Diese Referenzarchitektur ergänzt die Schicht darüber: meshStack registriert die STACKIT-Plattform, ihre Landing Zones und eine Reihe von Building Block Definitions. Applikationsteams bestellen STACKIT-Projekte und geroutete Netzwerke damit selbst, anstatt ein Ticket beim Plattformteam zu eröffnen.
Die Umsetzung erfolgt als OpenTofu im meshStack Hub und wird einmal pro Workspace ausgerollt.
Zusammenspiel der beiden Teile
Abschnitt betitelt „Zusammenspiel der beiden Teile“Das Management-Modul des Accelerators erzeugt einen Automatisierungs-Service-Account, weist ihm owner auf Organisationsebene zu und legt dessen Key im Secrets Manager ab.
Genau dieses Credential benötigt die Referenzarchitektur: Sie erwartet einen STACKIT-Service-Account-Key mit resource-manager.admin auf der Organisation.
Beide Teile bilden damit einen gemeinsamen Stack: Accelerator ausrollen, den Automatisierungs-Key aus dem Secrets Manager lesen und an die meshStack Landing Zone übergeben.
Was bereitgestellt wird
Abschnitt betitelt „Was bereitgestellt wird“- STACKIT-Plattform und Landing Zones: Die Plattform
STACKIT Projectwird in meshStack samt ihren Landing Zones registriert und mit dem Service Account verbunden, der die Projekte anlegt. - Projekt-Building-Block: Eine Building Block Definition
stackit/project, über die Applikationsteams ein STACKIT-Projekt bestellen. meshStack-Rollen werden dabei auf STACKIT-Projektrollen abgebildet. - Optionales Hub-and-Spoke-Netzwerk: Eine gemeinsame Network Area mit dem IPv4-Adressplan sowie ein Building Block
stackit/networkauf Tenant-Ebene. Jede Bestellung bezieht ihr Subnetz aus dem gemeinsamen Plan, sodass sich zwei Teams nicht auf denselben CIDR-Bereichen überschneiden können. - Self-Service-Starterkit: Eine Definition
STACKIT Project Starterkit, die die beiden Building Blocks darüber zu einer einzigen Bestellung zusammenfasst. Sie wird immer registriert, und zur Auswahl stehen genau die Landing Zones, die das Deployment angelegt hat. - Ressourcenhierarchie: Ein dedizierter Resourcemanager-Folder für die Tenant-Projekte und ein Foundation-Projekt für den Service Account der Landing Zone.
Ohne Netzwerkkonfiguration wird nur die Sandbox-Basis ausgerollt. Das ist der kleinste sinnvolle Einstieg.
Was Applikationsteams erhalten
Abschnitt betitelt „Was Applikationsteams erhalten“- Ein fertiges Projekt aus einer Bestellung: Das Starterkit legt das Projekt in der gewählten Landing Zone an und weist die Rollen zu. Niemand muss die Einzelteile nacheinander bestellen.
- Ein Subnetz ohne Abstimmung: In der Landing Zone mit Netzwerk ergänzt dieselbe Bestellung ein geroutetes Netzwerk in diesem Projekt, dessen CIDR-Bereich aus dem gemeinsamen Adressplan zugewiesen wird.
- Sichtbare Verantwortlichkeit: Jedes Projekt und jedes Netzwerk hat ein benanntes verantwortliches Team. Darauf setzen Kostenzuordnung und Richtlinien-Reporting auf.
Geteilte Verantwortlichkeiten
Abschnitt betitelt „Geteilte Verantwortlichkeiten“| Verantwortlichkeit | Plattformteam | Applikationsteam |
|---|---|---|
| Plattform-Basis mit dem Accelerator bereitstellen | ✅ | ❌ |
| Plattform, Landing Zones und Building Block Definitions registrieren | ✅ | ❌ |
| Gemeinsamen Adressplan festlegen (bei aktiviertem Netzwerk) | ✅ | ❌ |
| STACKIT-Projekte über eine Landing Zone anfordern | ❌ | ✅ |
| Geroutete Netzwerke im eigenen Projekt bestellen | ❌ | ✅ |
| Workloads in den eigenen Projekten betreiben | ❌ | ✅ |
Referenz
Abschnitt betitelt „Referenz“- Quellcode: meshstack-hub auf GitHub
Architektur
Abschnitt betitelt „Architektur“
Übersicht
Abschnitt betitelt „Übersicht“Der STACKIT Landing Zone Accelerator stellt die Plattform-Basis als Code bereit. Diese Referenzarchitektur ergänzt die Schicht darüber: meshStack registriert die STACKIT-Plattform, ihre Landing Zones und eine Reihe von Building Block Definitions. Applikationsteams bestellen STACKIT-Projekte und geroutete Netzwerke damit selbst, anstatt ein Ticket beim Plattformteam zu eröffnen.
Die Umsetzung erfolgt als OpenTofu im meshStack Hub und wird einmal pro Workspace ausgerollt.
Zusammenspiel der beiden Teile
Abschnitt betitelt „Zusammenspiel der beiden Teile“Das Management-Modul des Accelerators erzeugt einen Automatisierungs-Service-Account, weist ihm owner auf Organisationsebene zu und legt dessen Key im Secrets Manager ab.
Genau dieses Credential benötigt die Referenzarchitektur: Sie erwartet einen STACKIT-Service-Account-Key mit resource-manager.admin auf der Organisation.
Beide Teile bilden damit einen gemeinsamen Stack: Accelerator ausrollen, den Automatisierungs-Key aus dem Secrets Manager lesen und an die meshStack Landing Zone übergeben.
Was bereitgestellt wird
Abschnitt betitelt „Was bereitgestellt wird“- STACKIT-Plattform und Landing Zones: Die Plattform
STACKIT Projectwird in meshStack samt ihren Landing Zones registriert und mit dem Service Account verbunden, der die Projekte anlegt. - Projekt-Building-Block: Eine Building Block Definition
stackit/project, über die Applikationsteams ein STACKIT-Projekt bestellen. meshStack-Rollen werden dabei auf STACKIT-Projektrollen abgebildet. - Optionales Hub-and-Spoke-Netzwerk: Eine gemeinsame Network Area mit dem IPv4-Adressplan sowie ein Building Block
stackit/networkauf Tenant-Ebene. Jede Bestellung bezieht ihr Subnetz aus dem gemeinsamen Plan, sodass sich zwei Teams nicht auf denselben CIDR-Bereichen überschneiden können. - Self-Service-Starterkit: Eine Definition
STACKIT Project Starterkit, die die beiden Building Blocks darüber zu einer einzigen Bestellung zusammenfasst. Sie wird immer registriert, und zur Auswahl stehen genau die Landing Zones, die das Deployment angelegt hat. - Ressourcenhierarchie: Ein dedizierter Resourcemanager-Folder für die Tenant-Projekte und ein Foundation-Projekt für den Service Account der Landing Zone.
Ohne Netzwerkkonfiguration wird nur die Sandbox-Basis ausgerollt. Das ist der kleinste sinnvolle Einstieg.
Was Applikationsteams erhalten
Abschnitt betitelt „Was Applikationsteams erhalten“- Ein fertiges Projekt aus einer Bestellung: Das Starterkit legt das Projekt in der gewählten Landing Zone an und weist die Rollen zu. Niemand muss die Einzelteile nacheinander bestellen.
- Ein Subnetz ohne Abstimmung: In der Landing Zone mit Netzwerk ergänzt dieselbe Bestellung ein geroutetes Netzwerk in diesem Projekt, dessen CIDR-Bereich aus dem gemeinsamen Adressplan zugewiesen wird.
- Sichtbare Verantwortlichkeit: Jedes Projekt und jedes Netzwerk hat ein benanntes verantwortliches Team. Darauf setzen Kostenzuordnung und Richtlinien-Reporting auf.
Geteilte Verantwortlichkeiten
Abschnitt betitelt „Geteilte Verantwortlichkeiten“| Verantwortlichkeit | Plattformteam | Applikationsteam |
|---|---|---|
| Plattform-Basis mit dem Accelerator bereitstellen | ✅ | ❌ |
| Plattform, Landing Zones und Building Block Definitions registrieren | ✅ | ❌ |
| Gemeinsamen Adressplan festlegen (bei aktiviertem Netzwerk) | ✅ | ❌ |
| STACKIT-Projekte über eine Landing Zone anfordern | ❌ | ✅ |
| Geroutete Netzwerke im eigenen Projekt bestellen | ❌ | ✅ |
| Workloads in den eigenen Projekten betreiben | ❌ | ✅ |
Referenz
Abschnitt betitelt „Referenz“- Quellcode: meshstack-hub auf GitHub
Projekte und Netzwerke über Self-Service bereitstellen
Architektur
Abschnitt betitelt „Architektur“
Übersicht
Abschnitt betitelt „Übersicht“Der STACKIT Landing Zone Accelerator stellt die Plattform-Basis als Code bereit. Diese Referenzarchitektur ergänzt die Schicht darüber: meshStack registriert die STACKIT-Plattform, ihre Landing Zones und eine Reihe von Building Block Definitions. Applikationsteams bestellen STACKIT-Projekte und geroutete Netzwerke damit selbst, anstatt ein Ticket beim Plattformteam zu eröffnen.
Die Umsetzung erfolgt als OpenTofu im meshStack Hub und wird einmal pro Workspace ausgerollt.
Zusammenspiel der beiden Teile
Abschnitt betitelt „Zusammenspiel der beiden Teile“Das Management-Modul des Accelerators erzeugt einen Automatisierungs-Service-Account, weist ihm owner auf Organisationsebene zu und legt dessen Key im Secrets Manager ab.
Genau dieses Credential benötigt die Referenzarchitektur: Sie erwartet einen STACKIT-Service-Account-Key mit resource-manager.admin auf der Organisation.
Beide Teile bilden damit einen gemeinsamen Stack: Accelerator ausrollen, den Automatisierungs-Key aus dem Secrets Manager lesen und an die meshStack Landing Zone übergeben.
Was bereitgestellt wird
Abschnitt betitelt „Was bereitgestellt wird“- STACKIT-Plattform und Landing Zones: Die Plattform
STACKIT Projectwird in meshStack samt ihren Landing Zones registriert und mit dem Service Account verbunden, der die Projekte anlegt. - Projekt-Building-Block: Eine Building Block Definition
stackit/project, über die Applikationsteams ein STACKIT-Projekt bestellen. meshStack-Rollen werden dabei auf STACKIT-Projektrollen abgebildet. - Optionales Hub-and-Spoke-Netzwerk: Eine gemeinsame Network Area mit dem IPv4-Adressplan sowie ein Building Block
stackit/networkauf Tenant-Ebene. Jede Bestellung bezieht ihr Subnetz aus dem gemeinsamen Plan, sodass sich zwei Teams nicht auf denselben CIDR-Bereichen überschneiden können. - Self-Service-Starterkit: Eine Definition
STACKIT Project Starterkit, die die beiden Building Blocks darüber zu einer einzigen Bestellung zusammenfasst. Sie wird immer registriert, und zur Auswahl stehen genau die Landing Zones, die das Deployment angelegt hat. - Ressourcenhierarchie: Ein dedizierter Resourcemanager-Folder für die Tenant-Projekte und ein Foundation-Projekt für den Service Account der Landing Zone.
Ohne Netzwerkkonfiguration wird nur die Sandbox-Basis ausgerollt. Das ist der kleinste sinnvolle Einstieg.
Was Applikationsteams erhalten
Abschnitt betitelt „Was Applikationsteams erhalten“- Ein fertiges Projekt aus einer Bestellung: Das Starterkit legt das Projekt in der gewählten Landing Zone an und weist die Rollen zu. Niemand muss die Einzelteile nacheinander bestellen.
- Ein Subnetz ohne Abstimmung: In der Landing Zone mit Netzwerk ergänzt dieselbe Bestellung ein geroutetes Netzwerk in diesem Projekt, dessen CIDR-Bereich aus dem gemeinsamen Adressplan zugewiesen wird.
- Sichtbare Verantwortlichkeit: Jedes Projekt und jedes Netzwerk hat ein benanntes verantwortliches Team. Darauf setzen Kostenzuordnung und Richtlinien-Reporting auf.
Geteilte Verantwortlichkeiten
Abschnitt betitelt „Geteilte Verantwortlichkeiten“| Verantwortlichkeit | Plattformteam | Applikationsteam |
|---|---|---|
| Plattform-Basis mit dem Accelerator bereitstellen | ✅ | ❌ |
| Plattform, Landing Zones und Building Block Definitions registrieren | ✅ | ❌ |
| Gemeinsamen Adressplan festlegen (bei aktiviertem Netzwerk) | ✅ | ❌ |
| STACKIT-Projekte über eine Landing Zone anfordern | ❌ | ✅ |
| Geroutete Netzwerke im eigenen Projekt bestellen | ❌ | ✅ |
| Workloads in den eigenen Projekten betreiben | ❌ | ✅ |
Referenz
Abschnitt betitelt „Referenz“- Quellcode: meshstack-hub auf GitHub
Architektur
Abschnitt betitelt „Architektur“
Übersicht
Abschnitt betitelt „Übersicht“Der STACKIT Landing Zone Accelerator stellt die Plattform-Basis als Code bereit. Diese Referenzarchitektur ergänzt die Schicht darüber: meshStack registriert die STACKIT-Plattform, ihre Landing Zones und eine Reihe von Building Block Definitions. Applikationsteams bestellen STACKIT-Projekte und geroutete Netzwerke damit selbst, anstatt ein Ticket beim Plattformteam zu eröffnen.
Die Umsetzung erfolgt als OpenTofu im meshStack Hub und wird einmal pro Workspace ausgerollt.
Zusammenspiel der beiden Teile
Abschnitt betitelt „Zusammenspiel der beiden Teile“Das Management-Modul des Accelerators erzeugt einen Automatisierungs-Service-Account, weist ihm owner auf Organisationsebene zu und legt dessen Key im Secrets Manager ab.
Genau dieses Credential benötigt die Referenzarchitektur: Sie erwartet einen STACKIT-Service-Account-Key mit resource-manager.admin auf der Organisation.
Beide Teile bilden damit einen gemeinsamen Stack: Accelerator ausrollen, den Automatisierungs-Key aus dem Secrets Manager lesen und an die meshStack Landing Zone übergeben.
Was bereitgestellt wird
Abschnitt betitelt „Was bereitgestellt wird“- STACKIT-Plattform und Landing Zones: Die Plattform
STACKIT Projectwird in meshStack samt ihren Landing Zones registriert und mit dem Service Account verbunden, der die Projekte anlegt. - Projekt-Building-Block: Eine Building Block Definition
stackit/project, über die Applikationsteams ein STACKIT-Projekt bestellen. meshStack-Rollen werden dabei auf STACKIT-Projektrollen abgebildet. - Optionales Hub-and-Spoke-Netzwerk: Eine gemeinsame Network Area mit dem IPv4-Adressplan sowie ein Building Block
stackit/networkauf Tenant-Ebene. Jede Bestellung bezieht ihr Subnetz aus dem gemeinsamen Plan, sodass sich zwei Teams nicht auf denselben CIDR-Bereichen überschneiden können. - Self-Service-Starterkit: Eine Definition
STACKIT Project Starterkit, die die beiden Building Blocks darüber zu einer einzigen Bestellung zusammenfasst. Sie wird immer registriert, und zur Auswahl stehen genau die Landing Zones, die das Deployment angelegt hat. - Ressourcenhierarchie: Ein dedizierter Resourcemanager-Folder für die Tenant-Projekte und ein Foundation-Projekt für den Service Account der Landing Zone.
Ohne Netzwerkkonfiguration wird nur die Sandbox-Basis ausgerollt. Das ist der kleinste sinnvolle Einstieg.
Was Applikationsteams erhalten
Abschnitt betitelt „Was Applikationsteams erhalten“- Ein fertiges Projekt aus einer Bestellung: Das Starterkit legt das Projekt in der gewählten Landing Zone an und weist die Rollen zu. Niemand muss die Einzelteile nacheinander bestellen.
- Ein Subnetz ohne Abstimmung: In der Landing Zone mit Netzwerk ergänzt dieselbe Bestellung ein geroutetes Netzwerk in diesem Projekt, dessen CIDR-Bereich aus dem gemeinsamen Adressplan zugewiesen wird.
- Sichtbare Verantwortlichkeit: Jedes Projekt und jedes Netzwerk hat ein benanntes verantwortliches Team. Darauf setzen Kostenzuordnung und Richtlinien-Reporting auf.
Geteilte Verantwortlichkeiten
Abschnitt betitelt „Geteilte Verantwortlichkeiten“| Verantwortlichkeit | Plattformteam | Applikationsteam |
|---|---|---|
| Plattform-Basis mit dem Accelerator bereitstellen | ✅ | ❌ |
| Plattform, Landing Zones und Building Block Definitions registrieren | ✅ | ❌ |
| Gemeinsamen Adressplan festlegen (bei aktiviertem Netzwerk) | ✅ | ❌ |
| STACKIT-Projekte über eine Landing Zone anfordern | ❌ | ✅ |
| Geroutete Netzwerke im eigenen Projekt bestellen | ❌ | ✅ |
| Workloads in den eigenen Projekten betreiben | ❌ | ✅ |
Referenz
Abschnitt betitelt „Referenz“- Quellcode: meshstack-hub auf GitHub
Architektur
Abschnitt betitelt „Architektur“
Übersicht
Abschnitt betitelt „Übersicht“Der STACKIT Landing Zone Accelerator stellt die Plattform-Basis als Code bereit. Diese Referenzarchitektur ergänzt die Schicht darüber: meshStack registriert die STACKIT-Plattform, ihre Landing Zones und eine Reihe von Building Block Definitions. Applikationsteams bestellen STACKIT-Projekte und geroutete Netzwerke damit selbst, anstatt ein Ticket beim Plattformteam zu eröffnen.
Die Umsetzung erfolgt als OpenTofu im meshStack Hub und wird einmal pro Workspace ausgerollt.
Zusammenspiel der beiden Teile
Abschnitt betitelt „Zusammenspiel der beiden Teile“Das Management-Modul des Accelerators erzeugt einen Automatisierungs-Service-Account, weist ihm owner auf Organisationsebene zu und legt dessen Key im Secrets Manager ab.
Genau dieses Credential benötigt die Referenzarchitektur: Sie erwartet einen STACKIT-Service-Account-Key mit resource-manager.admin auf der Organisation.
Beide Teile bilden damit einen gemeinsamen Stack: Accelerator ausrollen, den Automatisierungs-Key aus dem Secrets Manager lesen und an die meshStack Landing Zone übergeben.
Was bereitgestellt wird
Abschnitt betitelt „Was bereitgestellt wird“- STACKIT-Plattform und Landing Zones: Die Plattform
STACKIT Projectwird in meshStack samt ihren Landing Zones registriert und mit dem Service Account verbunden, der die Projekte anlegt. - Projekt-Building-Block: Eine Building Block Definition
stackit/project, über die Applikationsteams ein STACKIT-Projekt bestellen. meshStack-Rollen werden dabei auf STACKIT-Projektrollen abgebildet. - Optionales Hub-and-Spoke-Netzwerk: Eine gemeinsame Network Area mit dem IPv4-Adressplan sowie ein Building Block
stackit/networkauf Tenant-Ebene. Jede Bestellung bezieht ihr Subnetz aus dem gemeinsamen Plan, sodass sich zwei Teams nicht auf denselben CIDR-Bereichen überschneiden können. - Self-Service-Starterkit: Eine Definition
STACKIT Project Starterkit, die die beiden Building Blocks darüber zu einer einzigen Bestellung zusammenfasst. Sie wird immer registriert, und zur Auswahl stehen genau die Landing Zones, die das Deployment angelegt hat. - Ressourcenhierarchie: Ein dedizierter Resourcemanager-Folder für die Tenant-Projekte und ein Foundation-Projekt für den Service Account der Landing Zone.
Ohne Netzwerkkonfiguration wird nur die Sandbox-Basis ausgerollt. Das ist der kleinste sinnvolle Einstieg.
Was Applikationsteams erhalten
Abschnitt betitelt „Was Applikationsteams erhalten“- Ein fertiges Projekt aus einer Bestellung: Das Starterkit legt das Projekt in der gewählten Landing Zone an und weist die Rollen zu. Niemand muss die Einzelteile nacheinander bestellen.
- Ein Subnetz ohne Abstimmung: In der Landing Zone mit Netzwerk ergänzt dieselbe Bestellung ein geroutetes Netzwerk in diesem Projekt, dessen CIDR-Bereich aus dem gemeinsamen Adressplan zugewiesen wird.
- Sichtbare Verantwortlichkeit: Jedes Projekt und jedes Netzwerk hat ein benanntes verantwortliches Team. Darauf setzen Kostenzuordnung und Richtlinien-Reporting auf.
Geteilte Verantwortlichkeiten
Abschnitt betitelt „Geteilte Verantwortlichkeiten“| Verantwortlichkeit | Plattformteam | Applikationsteam |
|---|---|---|
| Plattform-Basis mit dem Accelerator bereitstellen | ✅ | ❌ |
| Plattform, Landing Zones und Building Block Definitions registrieren | ✅ | ❌ |
| Gemeinsamen Adressplan festlegen (bei aktiviertem Netzwerk) | ✅ | ❌ |
| STACKIT-Projekte über eine Landing Zone anfordern | ❌ | ✅ |
| Geroutete Netzwerke im eigenen Projekt bestellen | ❌ | ✅ |
| Workloads in den eigenen Projekten betreiben | ❌ | ✅ |
Referenz
Abschnitt betitelt „Referenz“- Quellcode: meshstack-hub auf GitHub