STACKIT Landing Zone Accelerator

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.

Code & registry github.com Landing Zone Accelerator architecture Review the implementation architecture, deployment configurations, and network behavior in the source repository. Open the repository

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.