README.de.md

Separates Application-Landing-Zone-Root

English | Deutsch

Dieses Root plant eine neue Anwendungsinstanz unter Wiederverwendung von ../modules/landing-zone. Es erstellt keine Plattformordner, SNAs, Plattformdienste oder anderen Anwendungen. Es funktioniert mit manuell aufgelösten CLI-Eingaben oder vom Configurator erzeugten Eingaben. Für die direkte CLI-Nutzung sind weder Configurator-API, Datenbank, Sitzung, Jobfreigabe noch Template-Engine erforderlich. Migrieren Sie bestehenden kombinierten State nicht durch Verzeichniswechsel oder das Löschen seiner landing_zones-Einträge: Dies kann destruktive Änderungen planen.

Der Configurator löst Templates auf und prüft seine eigenen Identitäts-/Freigaberichtlinien. CLI-Nutzer geben die aufgelösten Werte direkt an, einschließlich Eigentümer und Diensteinstellungen. In beiden Betriebsarten setzen STACKIT IAM und Backend-Richtlinien Berechtigungen durch; Eingabemetadaten, Template-Versionen und Herkunftslabels sind keine IAM-Grenze.

Das wiederverwendete Modul erstellt ein Projekt, ein Automatisierungsdienstkonto mit Schlüssel, Object-Storage-Buckets/-Zugangsdaten sowie die ausgewählten Secrets-Manager- und Observability-Dienste. Corporate-Instanzen referenzieren eine plattformeigene SNA und erstellen ihr Projektnetzwerk/Routing. Public-Instanzen können optional mit network_enabled ein lokales Projektnetzwerk und optional mit network_prefix_length eine Präfixlänge festlegen. Dieses Netzwerk wird nicht über die SNA geroutet; bisherige öffentliche Eingaben ohne diese Option erstellen weiterhin kein Netzwerk. Templates mit Schema 2 legen diese Werte fest, statt Überschreibungen bei Bestellungen zu erlauben. Das Root stellt eine nicht geheime project_network-Referenz bereit, keine Dienstzugangsdaten. Ein lokales Netzwerk qualifiziert sein privates CIDR nicht als Observability-ACL-Quelle. Dieser Umfang muss bei Template-Veröffentlichung und Plan-Prüfung sichtbar sein. Generierte Zugangsdaten verbleiben im geschützten Application-State; sie werden nicht über Root-Ausgaben offengelegt.

Bei Corporate-Projekten übernimmt network_prefix_length = null den aktuellen Standard der SNA-Region durch eine lesende Provider-Abfrage während des Plans. Explizite Präfixe und konfigurierte DNS-Server bleiben erhalten. Der verwendete Zugang benötigt Leserechte für die SNA-Region. Ein geänderter SNA-Standard kann in einem späteren Plan einen Austausch des Netzes bewirken; diese Änderung vor Apply prüfen. Das funktioniert mit vorhandenen Plattformverträgen und benötigt weder ein zusätzliches Vertragsfeld noch eine State-Migration.

Projektverantwortung und Workload-Automation

application.owner_email bezeichnet die verantwortliche bestellende Person. Standardmäßig ist sie zugleich der initiale Projekt-Owner; bestehende Eingaben bleiben damit kompatibel. Ein ausdrücklich gesetztes application.initial_owner_email erstellt das Projekt stattdessen mit dem geprüften zentralen Benutzer oder Service Account. Die gewünschten Projektrollen der bestellenden Person werden über role_assignments vergeben. Das erzeugt kein Projekt ohne Owner. application.automation_role wählt davon unabhängig die Projektrolle des Automation-Service-Accounts, einschließlich einer unter custom_roles definierten eigenen Rolle. Der Standard bleibt aus Kompatibilitätsgründen owner. Die Ressourcenadresse sa_owner bleibt auch bei einer anderen ausgewählten Rolle erhalten.

Änderungen dieser Felder in bestehenden Installationen sind als IAM-Migration zu prüfen; bestehende Berechtigungen werden nicht stillschweigend entfernt. Eigene Rollen werden vor ihrer Automation-Zuweisung erstellt. Eine eingeschränkte Rolle hebt direkte, gruppenbezogene oder geerbte Owner-Rechte nicht auf. Wer einen privilegierten Automation-Schlüssel auslesen kann, kann dessen Rechte erhalten; State und Zugangsdaten sind daher separat zu schützen. Dies sind native Fähigkeiten. Die Veröffentlichung im Configurator benötigt separat geprüfte Quell-, Identitäts- und Freigabeverträge. Ein erfolgreicher Mock-Plan belegt keine reale Least-Privilege-Abnahme.

Unabhängiger zweiphasiger CLI-Ablauf

Phase 1: Plattform

Verwenden Sie das normale Accelerator-Bootstrap-Verfahren. Konfigurieren Sie für eine neue, reine Plattforminstallation ausdrücklich landing_zones = {}, sandboxes = [] und landing_zone_namespace_services = {} vor dem ersten Apply. Behalten Sie die erforderlichen Plattformdienste und Governance-Ordner bei. Das bestehende Root bleibt mit kombinierten Installationen kompatibel; ein separates physisches Plattform-Root und die Migration bestehender States werden hier nicht eingeführt.

Exportieren Sie nach Prüfung und Anwendung des Plattformplans nur die nicht geheime Übergabe:

tofu -chdir=src output -json platform_contract > platform-contract.json

Diese enthält Referenzen auf Organisation, Ordner, Region, SNA, Next-Hop und Nameserver, nicht den vollständigen Plattform-State oder Zugangsdaten. Ihre Revision ist eine deterministische UUID, abgeleitet aus Namespace und exportierten Referenzen. Geänderte Referenzen ändern die Revision; bewahren Sie das geprüfte Artefakt mit der Anwendungskonfiguration auf. tenant_id ist ein logischer Namespace, standardmäßig die Organisations-UUID. Das optionale platform_contract_namespace erlaubt eine andere stabile UUID, beispielsweise den vorgesehenen Configurator-Workspace. Für die CLI-Nutzung ist keine vom Configurator ausgestellte UUID erforderlich. Öffentliche Ziele sind public-eu01/public-eu02; Corporate-Zielschlüssel enthalten einen stabilen Hash des Area-Schlüssels, damit beliebige Area-Namen keine ungültigen oder kollidierenden normalisierten Zielnamen erzeugen können. Nur vorhandene Governance-Ordner/SNAs werden exportiert. Ein exportiertes Ziel ist eine Ressourcenreferenz, keine Berechtigung zur Bereitstellung dort.

Phase 2: Anwendung

Beginnen Sie mit dem aufgelösten JSON-Beispiel. Alle Beispiel-IDs sind fiktiv. Ersetzen Sie platform_contract durch das Artefakt aus Phase 1 und füllen Sie die Anwendungswerte manuell aus. Template-Rendering ist nicht erforderlich. Setzen Sie application.tenant_id und application.platform_revision exakt aus diesem Artefakt; wählen Sie einen seiner Zielschlüssel. Vergeben Sie instance_id einmalig (beispielsweise uuidgen | tr '[:upper:]' '[:lower:]') und halten Sie sie stabil. template_id/template_version dokumentieren die gewählte Ausgangsbasis; ein veröffentlichtes Configurator-Template ist nicht erforderlich. Eigentümer, Rollen, Netzwerk- und Diensteinstellungen müssen nach den Bereitstellungsrichtlinien Ihrer Organisation geprüft werden.

Stellen Sie vor dem ersten Application-Plan einen Application-State-Bucket bereit. Verwenden Sie das Backend-Beispiel, ersetzen Sie Bucket/Schlüssel und halten Sie den Schlüssel applications/<namespace>/<instance>/terraform.tfstate eindeutig und unverändert. Verwenden Sie angemessen eingeschränkte Backend-Zugangsdaten, keine Zugangsdaten, die einem Application Owner Zugriff auf Plattform-State geben. Übergeben Sie S3-Zugangsdaten über AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY und Provider-Zugangsdaten über die Standardumgebung des STACKIT-Providers. Speichern Sie keine Geheimnisse in einem der Artefakte. Der projekteigene tfstate-Bucket kann seinen ersten Plan nicht selbst bootstrappen.

Führen Sie mit geprüften Dateien namens application.tfvars.json und backend.hcl im Application-Verzeichnis vom Repository-Root aus Folgendes aus:

tofu -chdir=src/application init -backend-config=backend.hcl
tofu -chdir=src/application validate
tofu -chdir=src/application plan -var-file=application.tfvars.json -out=application.tfplan
tofu -chdir=src/application apply application.tfplan
tofu -chdir=src/application plan -var-file=application.tfvars.json

Prüfen Sie den gespeicherten Plan, bevor Sie ihn ausdrücklich anwenden. Halten Sie State, gespeicherte Pläne und Zugangsdaten privat. Deaktivieren Sie niemals die Sperrung, um einen anderen aktiven Job zu umgehen. Verwenden Sie pro Instanz eine separate initialisierte Arbeitskopie; wechseln Sie Instanzschlüssel nicht beiläufig im selben Arbeitsverzeichnis. Upgrades erfordern einen geprüften neuen Plan, keine automatischen Änderungen bei Veröffentlichung eines Templates oder Plattformvertrags.

Herkunft

Ressourcen mit Label-Unterstützung erhalten landing_zone_accelerator = "true". Direkte CLI-Nutzung behauptet keine Configurator-Ausführung. Der Configurator setzt application.configurator_execution = true, ergänzt landing_zone_configurator = "true" und behält seine bisherigen lzc_*-Labels bei. Labels sind beschreibend und können von berechtigten Cloud-Nutzern eingesehen/geändert werden; sie sind kein manipulationssicherer Ausführungsnachweis. Bestehende festgelegte Runner-Quellen werden durch diese Quelländerungen weder umgeschrieben noch aktiviert.

Offline-Prüfungen (ohne Kundenzugangsdaten oder -ressourcen):

tofu -chdir=src/application init -backend=false
tofu -chdir=src/application validate
tofu -chdir=src/application test

Die Configurator-Release-CI führt diese Prüfungen auch über npm run test:plan in einer isolierten vorübergehenden Kopie mit leerer Zugangsdatenumgebung und deaktiviertem Backend aus.

Tests verwenden ausschließlich Mock-Provider und Plan-Befehle. Mock-UUIDs sind Testdaten. Bekannte Provider-Deprecation-Warnungen stammen aus bestehenden Observability-Ausgaben des gemeinsamen Moduls. Die Root-/Provider-Lockdatei sollte beibehalten werden, wenn dieser Prototyp in die geprüfte Runner-Revision übernommen wird.

Das eingecheckte manuelle Beispiel ist in den Mock-Tests enthalten. Der unabhängige Test für den reinen Plattformexport läuft ohne den Configurator:

LZC_TEST_TOFU_BIN="$(command -v tofu)" bash src/tests/check-cli-contract.sh

Der Helfer benötigt außerdem Node.js für strukturierte JSON-Prüfungen. Er wertet das tatsächliche Standalone-Beispiel aus und prüft zusätzlich zu den nativen Mock-Tests ohne Zugangsdaten das Ordnerschema des geprüften Providers.

Noch abzunehmen: echter, separat autorisierter zweiphasiger CLI-Plan/Apply, Backend-Sperrung/-Wiederherstellung, minimal berechtigte Zugangsdaten, ausdrückliche Migration bestehender States und vollständiger Configurator-Dispatch. Mock-Tests sind keine Cloud-Abnahme.

Requirements

Name	Version
terraform	>= 1.11
stackit	0.114.0
time	0.14.1

Providers

Name	Version
terraform	n/a

Modules

Name	Source	Version
application	../modules/landing-zone	n/a

Resources

Name	Type
terraform_data.contract	resource

Inputs

Name	Description	Type	Default	Required
application	Resolved application instance supplied manually or by the Configurator. Identity and deployment authorization are enforced by the caller's IAM permissions.	object({ configurator_execution = optional(bool, false) tenant_id = string instance_id = string platform_revision = string template_id = string template_version = number name = string env = optional(string, null) owner_email = string initial_owner_email = optional(string, null) automation_role = optional(string, "owner") target_key = string network_enabled = optional(bool, false) network_prefix_length = optional(number, null) secretsmanager_enabled = bool custom_roles = optional(list(object({ name = string description = string permissions = list(string) })), []) role_assignments = optional(list(object({ role = string subject = string })), []) observability = object({ enabled = bool plan_name = string acl = list(string) access_source = optional(string, "explicit-cidrs") }) })	n/a	yes
bucket_naming	Object Storage bucket naming scheme: legacy preserves existing names; project-id includes the complete owning project UUID for STACKIT-wide uniqueness. Changing this for existing buckets requires a reviewed migration.	string	"project-id"	no
platform_contract	Reviewed non-secret platform references supplied as a CLI artifact or by the Configurator. No remote-state access.	object({ schema_version = number tenant_id = string revision = string organization_id = string targets = map(object({ folder_id = string region = string corporate = bool network_area_id = optional(string, null) firewall_next_hop_ip = optional(string, null) ipv4_nameservers = optional(list(string), null) })) })	n/a	yes

Outputs

Name	Description
application_resources	Non-secret resource references; never publish service credentials or complete state.