Feature: Central Platform Kubernetes Module + Optional Application Namespace Service for Landing Zones #35

Summary

We want to extend the landing zone accelerator with a central Kubernetes capability in the platform context and an optional namespace service for application landing zones, following the existing module standards and schema conventions of this repository.

Background and Motivation

Current landing zone capabilities cover governance, management, connectivity, devops, and project landing zones.
A reusable central Kubernetes platform capability is required to host shared cluster infrastructure (for example external-dns and central cluster observability integration) and to enable optional namespace onboarding for application landing zones.
We already have implementation experience from a separate Kubernetes replatform repository and want to transfer only the suitable parts into this repository architecture and standards.

Goals

• Add a new optional central Kubernetes platform capability, similar in optionality and composition to existing platform modules.
• Deploy the SKE cluster centrally in a platform landing zone context.
• Support two cluster network modes:
  • with SNA-aware network configuration
  • without SNA, using the corresponding network creation path for SKE
• Add optional encrypted node volumes for SKE as a feature toggle.
• Integrate central SKE observability extension to a central observability instance in the same project as the cluster, explicitly for cluster/platform monitoring only.
• Reuse existing landing zone DNS setup by attaching DNS integration instead of redeploying base DNS services.
• Extend application landing zone capabilities with an optional namespace service in the central SKE cluster.
• Evaluate and implement integration path for DNS + workload namespace and Service Manager usage instead of classic secrets where applicable.
• Keep full compatibility with repository conventions:
  • module layout and naming conventions
  • variable object schema style with optional sections
  • output and tests style
  • provider/version and docs generation workflow

Non-Goals

• Not introducing a full workload deployment framework in this repo.
• Not replacing existing management/landing-zone responsibilities beyond necessary extension points.
• Not introducing unrelated network/firewall topology changes.

Scope Phase 1: Central Platform Kubernetes

• New optional module block at root level for central platform Kubernetes.
• Project creation and labels following existing naming and project patterns.
• SKE cluster creation with:
  • configurable node pools
  • network mode branching for SNA/non-SNA
  • optional encrypted volumes
  • observability extension integration
  • DNS integration by attaching to existing DNS zone strategy in landing zone context.
• Required outputs for cluster/project integration consumed by downstream optional services.

Scope Phase 2: Application Landing Zone Namespace Service

• Optional service toggle per application landing zone entry.
• Namespace creation in the central cluster.
• Optional DNS/workload integration model per namespace.
• Service Manager integration concept to avoid static Kubernetes secrets wherever possible.
• Role/permission model for tenant onboarding and namespace lifecycle.

High-Level Technical Approach

• Follow current module conventions:
  • numbered resource files per module
  • variables/outputs/terraform requirement files
  • tfdocs-generated README
  • tests in current tftest style
• Introduce a platform-kubernetes module as optional object configuration at root input level.
• Keep central cluster as single control point for app landing zone namespace onboarding.
• Add explicit integration contracts via outputs consumed by namespace service logic.
• Add/extend tests for standalone, hub-spoke, and hub-spoke without firewall relevant to the new optional features.

Acceptance Criteria

• Root module supports optional platform Kubernetes configuration without impacting existing deployments when unset.
• SKE cluster deploys in hub-spoke without firewall baseline and supports network mode branching for SNA/non-SNA.
• Encrypted volumes can be enabled/disabled via explicit toggle and validate in plan/apply.
• Central observability extension is wired and points to central instance in same project.
• DNS integration does not duplicate existing DNS foundational deployment and works with selected namespace/workload model.
• Application landing zone can optionally request namespace service creation in central cluster.
• Service Manager based secret flow is defined and implemented for supported use cases.
• Documentation and generated tfdocs are updated.
• E2E validation for a full hub-spoke without firewall landing zone setup is executed using test company service account access.

Implementation Task Breakdown

• Design input schema extensions at root and module boundaries.
• Implement platform-kubernetes module with SKE, observability extension, DNS attach path, optional encryption.
• Implement namespace service extension for application landing zones.
• Add IAM/RBAC and cross-project access model for DNS and namespace operations.
• Add tests and example config variants.
• Update docs and migration guidance.
• Run E2E hub-spoke without firewall validation and collect verification outputs.

Risks and Design Constraints

• Provider/resource capability constraints for namespace lifecycle and service-manager-backed secret flow.
• Cross-project IAM for DNS record management from central cluster.
• SNA network parameter correctness per provider schema and region constraints.
• Drift between central cluster intent and app landing zone optional services.
• Backward compatibility for existing users with null/optional defaults.

Open Questions (to be resolved before implementation)

• Central cluster tenancy model:
  • one central cluster globally
  • one per region
  • one per environment
• Module placement:
  • separate new module at root (recommended)
  • extension of existing devops module
• Namespace service implementation location:
  • in landing-zone module directly
  • separate namespace-service module consuming landing-zone map
• Kubernetes provider introduction:
  • acceptable to add kubernetes provider to this repo
  • or strict stackit-provider-only requirement
• SNA decision model:
  • explicit boolean mode flag
  • implicit behavior based on provided network fields
• DNS delegation strategy for workloads:
  • per-namespace subzone
  • per-landing-zone subzone
  • shared zone with naming convention and ownership boundaries
• External-dns ownership model:
  • one central external-dns instance
  • namespace-scoped tenancy with filters
• Service Manager integration target:
  • runtime secret retrieval in workloads
  • provisioning-time secret handover
  • both
• Encrypted volume default:
  • opt-in default false
  • opt-out default true for regulated environments
• Node pool baseline:
  • fixed two-AZ baseline
  • configurable list-based pool schema aligned with current repo style
• Observability ownership boundary:
  • cluster-only platform monitoring (as requested) confirmed
  • no app workload telemetry coupling in this module
• E2E scope and guardrails:
  • allowed budget/quota limits for test company
  • cleanup expectations after validation
  • acceptable apply runtime and retry policy

Definition of Ready
Implementation starts only after open questions above are answered and accepted in this issue.

Finalized Design Decisions (2026-06-11)

The following open points are now resolved and are binding for implementation:

1. Cluster topology: One central platform Kubernetes setup per region.
2. Module strategy: Introduce a new dedicated module (no DevOps module extension).
3. Providers: Kubernetes provider is allowed and required for Kubernetes objects (e.g. namespaces).
4. DNS model: Use the Landing Zone project DNS zone as the namespace/workload DNS base for that landing zone.
5. Secrets integration: Requirement is STACKIT Secrets Manager integration (not Service Manager).
6. Encrypted volumes: Optional feature, default = disabled, easy to enable.
7. Validation cadence: Run E2E checks after each milestone.
8. Destroy caveat: Not all objects are destroyable (e.g. folders with retention constraints), so cleanup must be conservative and explicit.

Milestone Tracking

• M1: Dedicated platform-kubernetes module scaffold + root wiring
• M1: Central SKE cluster resource with per-region design
• M1: SNA/non-SNA aware network handling in cluster config
• M1: Observability extension wiring (central cluster monitoring scope)
• M1: DNS extension wiring to Landing Zone DNS zone model
• M1: Optional encrypted volume support (default off)
• M1: Baseline tests/config updates + validation run
• M2: Application Landing Zone optional namespace service
• M2: Namespace onboarding + DNS combination model per landing zone
• M2: Secrets Manager integration path for namespace/workload setup
• M2: Extended tests + milestone validation run

Progress Log

• 2026-06-11: Requirements clarified and design decisions finalized with stakeholder.
• 2026-06-11: Dev container trust fixed for Zscaler MITM CA; HTTPS downloads working.
• 2026-06-11: Terraform and OpenTofu installed in container and verified.
• 2026-06-11: GitHub CLI installed and authenticated for issue lifecycle updates.