STACKIT · Fundament vor dem ersten Workload
STACKIT Landing Zone aufbauen und absichern
Struktur, Netzwerk, Rechte und Protokollierung als Code: SKAFFON baut die Basis, bevor Systeme einziehen, damit spätere Umbauten nicht an Netzwerk- oder Rechtemodell scheitern.
- Resource Manager, Network Area, IAM
- Terraform/OpenTofu-Repository
- Nummerierte Abnahme-Checkliste
01Ausgangslage
Was später teuer wird, wenn die Basis fehlt
Eine Landing Zone ist das Fundament, auf dem Ihre Workloads in STACKIT laufen: Organisations- und Projektstruktur, Netzwerk, Identitäten und Rechte, Protokollierung und Leitplanken, alles als Code. Wer ohne dieses Fundament startet, baut Netzwerk und Rechtemodell später unter laufenden Systemen um.
Die Seite richtet sich an IT-Leitung und Cloud-Verantwortliche. Das herstellerübergreifende Konzept beschreibt Landing Zones und Infrastructure as Code; hier steht die Umsetzung auf STACKIT.
02Zielbild
So sieht die Struktur aus
03Bausteine
Was STACKIT für eine Landing Zone mitbringt
Stand der Prüfung: 13.11.2026, Quelle docs.stackit.cloud.
| Baustein | Was die Dokumentation beschreibt |
|---|---|
| Organisation, Ordner, Projekte | Der Resource Manager verwaltet Ressourcen in Projekten, Ordnern und Organisationen. Resource Manager und IAM arbeiten laut Regionsdokumentation global; Dienste liegen in den Regionen eu01 (Deutschland) und eu02 (Österreich). |
| Netzwerk | Core Networking: Virtual Networks (isolierte, softwaredefinierte Netze mit eigenen Adressbereichen, Subnetzen und Routing), Network Areas (Verbindung mehrerer Projekte einer Organisation auf Netzwerkebene, auch zur Anbindung hybrider Umgebungen) und Security Groups als virtuelle Firewalls. Ausgehender Internetzugang: Jedes Virtual Network hat ein Gateway ins Internet und nutzt Source-NAT; aus dem Internet initiierter Verkehr erreicht Ihre Ressourcen darüber nicht. Für den Internetzugang braucht eine Ressource keine Public IP Address; STACKIT nennt sie (1:1-NAT) für Ressourcen, die aus dem Internet erreichbar sein oder mit einer exklusiv genutzten Adresse nach außen gehen sollen. Security Groups lassen ausgehenden Verkehr standardmäßig zu. In einer Network Area bestimmen Routing-Tabellen (Public Preview) den Weg ausgehenden Verkehrs; statische Routen können als Next Hop zum Beispiel eine IP-Adresse, ein Black Hole oder das Internet haben. |
| Identität | IAM mit Rollen und Berechtigungen; Service Accounts als technische Identitäten ohne Standardzugriff. Service Accounts werden sofort und endgültig gelöscht; ein Papierkorb existiert nicht. |
| Protokollierung | Der Audit Log erfasst administrative Aktivitäten standardmäßig; über den Telemetry Router lassen sich Audit-Logs an externe Ziele weiterleiten. Initiator-Kennung, E-Mail und Client-IP sind personenbezogene Daten und werden nicht maskiert. Das gehört in Ihr Datenschutzkonzept. Das Portal zeigt die Ereignisse der letzten 90 Tage für die gewählte Organisation, den Ordner oder das Projekt. Benutzerkonten brauchen zum Lesen die Berechtigung audit-log.entry.get; sie ist in den Rollen Owner, Editor, Reader und audit-log.reader enthalten, Service Accounts benötigen audit-log.reader (Audit-Log abrufen). |
| Schutz und Geheimnisse | Key Management Service (KMS) und Secrets Manager als STACKIT-Produkte. |
| Automatisierung | Der STACKIT Terraform Provider; einzelne Ressourcen sind laut Dokumentation Beta und nur mit ausdrücklicher Aktivierung nutzbar. Wir prüfen vor der Verwendung, welche Ressourcen im Entwurf davon betroffen sind. |
Damit Audit-Logs länger verfügbar sind als die 90 Tage, die das Portal zeigt, leiten wir sie per Telemetry Router an ein OpenTelemetry- oder S3-kompatibles Ziel weiter, dessen Aufbewahrungsdauer Sie festlegen. Welche Ziele eine Umgebung nach außen erreichen darf, legen wir im Entwurf als Egress-Regeln und Routen fest.
04Netzwerk
Adressplan und Trennung festlegen, bevor Verkehr fließt
Das Netzwerk ist die Entscheidung, die sich im Betrieb am schwersten korrigieren lässt. Wir legen sie mit Ihnen fest:
- Adressplan ohne Überschneidung mit Ihren Standorten und anderen Clouds.
- Trennung von Management, Anwendung und Daten.
- Anbindung an Rechenzentren und andere Clouds.
- Regeln für Security Groups nach dem Prinzip „standardmäßig geschlossen“.
05Entwurf
Fünf Entscheidungen, die wir gemeinsam treffen
Neben dem Netzwerk bestimmen diese Punkte, wie belastbar die Basis wird.
-
Struktur der Projekte
Wie viele Projekte und Ordner, und nach welchem Kriterium: Umgebung (Produktion, Test), Anwendung, Verantwortungsbereich. Service Accounts erhalten ihre Rollen laut Dokumentation innerhalb eines Projekts; die Projektgrenze ist damit eine zentrale Grenze für Rechte. Rollen, die auf Organisation oder Ordner vergeben sind, gelten laut IAM-Dokumentation auch für alle darunterliegenden Ordner und Projekte; eine Bindung auf tieferer Ebene schränkt geerbten Zugriff nicht ein, dafür muss die Bindung oben entfernt werden. Breite Rollen wie Owner, Editor und Reader vergeben wir deshalb, wie STACKIT empfiehlt, auf Ordner oder Projekte statt auf die Organisation. Als Strukturmuster nennt STACKIT unter anderem Organisation → Ordner je Umgebung → Projekt je Anwendung und Organisation → Ordner je Team → Projekt je Anwendung. Ordner gibt es in einer Ebene, und sie sind nicht in jeder Organisation freigeschaltet; das prüfen wir vor dem Entwurf.
-
Identität und Rechte
Anbindung Ihrer Benutzerverwaltung, Rollen nach Aufgabe, Notfallzugang, Service Accounts je Pipeline. Vertiefung: IAM und Zero Trust.
-
Protokollierung
Welche Ereignisse wohin gehen, wer lesen darf, wie lange aufbewahrt wird.
-
Leitplanken
Pflichtmerkmale an Ressourcen, erlaubte Regionen und Produkte, Prüfregeln in der Pipeline (Policy as Code). Was STACKIT selbst erzwingt und was wir als Prüfung im Code ergänzen, trennen wir im Entwurf ausdrücklich.
-
Verschlüsselung
Einsatz von KMS und Secrets Manager; Verantwortung für Schlüssel.
Pipeline-Zugriff
Automatisierung ohne dauerhaften Schlüssel
Die STACKIT-Dokumentation empfiehlt, für Automatisierung föderierte Identität (Workload Identity Federation mit kurzlebigen Tokens) statt statischer Schlüssel zu nutzen und Schlüssel nie im Quellcode abzulegen. Wir planen Service Accounts je Pipeline deshalb nach Möglichkeit ohne dauerhaften Schlüssel.
06Repository
Wie das Terraform/OpenTofu-Repository aufgebaut ist
Beispielstruktur, wie wir sie anbieten; sie wird an Ihre Organisation angepasst. State liegt in einem gesicherten Backend mit Sperre; der Zugriff der Pipeline läuft über einen Service Account mit föderierter Identität. Das Arbeiten mit Plan, Review und Freigabe beschreibt Infrastructure as Code.
bootstrap/: erste Ressourcen (Projekt für den Terraform-State, Service Account für die Pipeline); einmalig und von Hand freigegeben.foundation/: Organisationsstruktur, Netzwerke, Network Area, Basis-Rollen, Audit-Weiterleitung.modules/: wiederverwendbare Module (Projekt, Netzwerk, Cluster-Basis), versioniert.environments/<umgebung>/: Instanziierung je Umgebung mit eigenem State.policies/: Prüfregeln, die in der Pipeline vorapplylaufen.
07Abnahme
Neun Belege, bis die Landing Zone als abgenommen gilt
Eine Landing Zone gilt als abgenommen, wenn diese Punkte belegt sind:
- Alle Ressourcen der Basis sind im Repository beschrieben; ein Plan gegen die Umgebung zeigt keine Abweichung (Drift).
- Struktur und Rechte sind dokumentiert: wer darf in welchem Projekt was, ohne persönliche Dauerzugänge mit weitreichenden Rechten.
- Pipeline-Zugriff nutzt einen Service Account; statische Schlüssel sind nicht im Repository.
- Netzwerkplan und Security-Group-Regeln sind dokumentiert; ein Test belegt, dass nicht freigegebener Verkehr abgewiesen wird.
- Audit-Log-Weiterleitung ist eingerichtet und eine Testaktion ist im Ziel nachweisbar.
- Notfallzugang ist beschrieben und einmal getestet.
- State-Backend ist gesichert, gesperrt gegen parallele Läufe, und sein Backup ist wiederherstellbar.
- Mindestens ein Beispiel-Workload (zum Beispiel ein SKE-Cluster) wurde über das Muster bereitgestellt.
- Ein Betriebshandbuch für die Basis liegt vor.
08Danach
Von der Basis zu Migration und Betrieb
Die Landing Zone ist die Voraussetzung für die Migration zu STACKIT und für Betriebsmodelle nach Managed Cloud Services. Ein bestehendes STACKIT-Projekt ohne Struktur bringen wir nach einer Bestandsaufnahme in diesen Zustand.
09Passung
Lohnt sich der Aufwand für Ihre STACKIT-Umgebung?
Das passt
- Sie betreiben mehrere Umgebungen oder Projekte in STACKIT und brauchen ein einheitliches Netzwerk- und Rechtemodell.
- Sie wollen die Basis als Code im Repository, mit Review und Freigabe.
Das passt weniger
- Sie suchen ein fertiges Produkt zum Installieren: Eine Landing Zone ist ein Entwurf für Ihre Organisation.
- Sie suchen ein Compliance-Zertifikat: Wir liefern technische Umsetzung und Nachweise, keine Zertifizierung und keine Rechtsberatung.
- Sie wollen nur ein einzelnes Projekt ohne Mehrumgebungs-Betrieb: Dann genügt oft eine schlanke Projektstruktur ohne Network Area.