Support multi-area firewalls and single-stack multi-region connectivity

[lweberru]

Goal

Support concrete, directly applicable Hub-Spoke scenarios for multiple network areas, distinct business and tenant boundaries, and a single-stack eu01/eu02 regional topology.

Delivered

• Multiple network areas use stable map keys.
• Landing zones, DNS zones, and Platform Kubernetes select their network area explicitly.
• connectivity.firewalls creates a dedicated OPNsense appliance per network area with unique WAN/LAN CIDRs and optional HA.
• Legacy single-area connectivity.network_area and connectivity.firewall inputs remain supported.
• Static STACKIT provider aliases support single-stack regional hubs in eu01 and eu02.
• Regional landing zones and Platform Kubernetes use the matching regional provider and connectivity output.
• Regional connectivity outputs retain both region and network-area identity.
• Documentation explains the lack of private cross-SNA routing and the resulting shared-service trade-off.

Delivered scenarios

1. Standalone
2. Hub-Spoke
3. Hub-Spoke with Firewall
4. Regulated and Shared workloads
5. Finance and Research business units
6. Prod/Nonprod with Firewalls
7. Three-Tenant Isolation
8. Hub-Spoke Multi-Region

Multi-region boundary

Provider aliases are static: the root module supports eu01 and eu02. Adding a region requires a matching provider alias and regional module instances. Regional hubs are isolated by default. The STACKIT provider exposes Secrets Manager and Observability only in eu01, so the eu02 reference workload disables Secrets Manager and the eu02 Platform Kubernetes cluster disables Observability.

Multi-SNA shared-service boundary

A STACKIT project attaches to one SNA only. Separate SNAs have no shared private routing path, so centrally operated private services cannot attach directly to multiple SNAs. Shared services must be public or SaaS services, be duplicated per SNA, or use explicit external endpoints such as VPN over the internet.

Follow-up work

• Automate inter-region VPN connectivity and routing #64 automates optional inter-region VPN connectivity and routes.
• Automate firewall policies for multiple appliances #65 automates firewall policies and credentials for every configured appliance.

Acceptance criteria

• Multiple network areas can be configured with arbitrary stable keys.
• Corporate landing zones, DNS zones, and Platform Kubernetes select a network area explicitly.
• A multi-area deployment can create one firewall per area with independent network settings.
• Legacy single-area configurations retain the default-area behavior.
• Complete business-unit and tenant-isolation configurations exist.
• One root stack deploys regional hubs, Landing Zones, and Platform Kubernetes in eu01 and eu02.
• Multi-region outputs preserve region and network-area identity.
• The complete multi-region reference configuration passes an authenticated OpenTofu plan.