---
title: "STACKIT Landing Zone Accelerator"
description: "STACKIT base asset for building a platform landing zone with reusable OpenTofu/Terraform modules, enterprise baseline patterns, and central Kubernetes."
sidebar:
badge:
text: "STACKIT"
variant: success
scfAsset:
managed: false
category: "blueprint"
external: true
tags: ["design-and-mobilize", "landing-zone", "opentofu", "terraform", "template"]
maintainers:
- user: "lukas.weberruss"
role: true
website: true
source_url: "https://framework.stackit.cloud/migration/assetcontainer/stackit/landing-zone-foundation-opentofu/"
source_file: "docs/migration/assetcontainer/stackit/landing-zone-foundation-opentofu.mdx"
---
## Accelerator architecture
- GitHub repository
## Overview
This asset provides a reusable foundation for implementing a STACKIT platform landing zone.
It is designed for enterprise environments that need a structured baseline for governance,
security, networking, cost controls, and automation.
Repository:
- GitHub repository
## How the repository works
This repository is a single root-module accelerator with modular submodules.
- The root module in `src/main.tf` orchestrates all platform and landing-zone building blocks.
- Configuration is provided through flavor-specific variable files in `src/config/`.
- You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
## Deployment flavours and what they enable
The repository provides eight reference configurations in `src/config/`. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
## Standalone
Use `standalone.tfvars` for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
## Hub-and-spoke
Use `hub-and-spoke.tfvars` when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
## Hub-and-spoke with firewall
Use `hub-and-spoke-firewall.tfvars` when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
## Finance and research separation
Use `hub-and-spoke-finance-research.tfvars` when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
## Regulated and shared network areas
Use `hub-and-spoke-multi-area.tfvars` when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
## Independent regional hubs
Use `hub-and-spoke-multi-region.tfvars` for regional foundations in `eu01` and `eu02`. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
## Production and non-production isolation
Use `hub-and-spoke-prod-nonprod-firewall.tfvars` when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
## Tenant isolation
Use `hub-and-spoke-tenant-isolation.tfvars` for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
## Module-by-module breakdown
### 1. Governance module (`src/modules/governance`)
Purpose:
- Creates RM folder structure (`platform`, `landing_zones_corporate`, `landing_zones_public`, `sandboxes`).
- Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- **Platform Landing Zone**: core governance baseline.
### 2. Management module (`src/modules/management`)
Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- **Platform Landing Zone**: shared operations and automation control plane.
### 3. Connectivity module (`src/modules/connectivity`)
Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- **Platform Landing Zone**: shared network and routing baseline.
### 4. DevOps module (`src/modules/devops`)
Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- **Platform Landing Zone** in this accelerator's architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
### 5. Landing-Zone module (`src/modules/landing-zone`)
Purpose:
- Creates application-facing landing-zone projects (iterative via `for_each`).
- Supports **corporate** landing zones (network area-connected) and **public** landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- **Application Landing Zone**: primary ALZ implementation module.
### 6. Sandboxes module (`src/modules/sandboxes`)
Purpose:
- Creates lightweight sandbox projects in the dedicated `sandboxes` folder.
- Assigns project owners.
Landing-zone classification:
- **Application Landing Zone (supporting)**: non-production experimentation space close to ALZ usage patterns.
## Newly implemented scope in this asset
The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
### Platform landing zone for central Kubernetes
The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- **Central cluster foundation**: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- **Secrets policy readiness**: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- **Shared service model**: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- **Operational baseline**: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
### Application landing zone for namespace tenants
Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- **Namespace onboarding**: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- **Developer access path**: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- **Service exposure**: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- **Secrets integration**: Workloads can consume centrally governed secret flows while staying in namespace scope.
## Extra platform features used in this setup
- **External DNS automation**: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- **Central Kubernetes monitoring**: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- **Dashboard provisioning workflow**: Example dashboards are provisioned and imported for faster operational handover.
- **Encrypted volumes option**: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- **Flexible network posture**: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
## What developers get in an application landing zone
- **Ready-to-use namespace**: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- **Least-privilege access**: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- **Consistent endpoint model**: Predictable DNS and ingress patterns for service publication.
- **Governed secret usage**: Central secret governance with namespace-level consumption patterns.
- **Observability visibility**: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
## Platform vs application landing zone scope in this repository
- **Platform Landing Zone focus (majority of implementation)**:
- `governance`
- `management`
- `connectivity`
- `devops`
- **Application Landing Zone scope (narrower by design)**:
- `landing-zone` (core ALZ provisioning)
- `sandboxes` (supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
## How to use this asset in migration programs
- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the `landing-zone` map in your variable files.
- Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
## What you get
- **Reusable baseline modules**: Building blocks for account/project structure, IAM, network, and controls.
- **Policy-oriented setup**: Guardrails and conventions for secure and governed cloud usage.
- **IaC-first approach**: OpenTofu/Terraform implementation model for repeatable provisioning.
- **Enterprise extensibility**: Designed as a baseline to be adapted to customer-specific requirements.
## Typical use in migration programs
- **Early platform stream**: Start foundation setup in parallel with discovery.
- **Control baseline before production move**: Ensure mandatory controls are in place before productive migrations.
- **Template source for application landing zones**: Reuse and refine baseline modules for workload archetypes.
## Recommended prerequisites
- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.