Architecture Overview

Badal Foundations is a layered GCP landing zone built with Terraform, based on the Google Cloud Security Foundations blueprint (Cloud Foundation Toolkit). It implements a strict sequential pipeline where each stage builds upon the outputs of previous stages via terraform_remote_state backed by a shared GCS bucket.

Pipeline Architecture

The 5-Stage Pipeline

Each stage is a separate Terraform root module in its own Git repository, deployed sequentially. Stages communicate through terraform_remote_state data sources reading from a shared GCS state bucket (bkt-prj-b-seed-tfstate-*).

Stage	Repository	Service Account	Purpose
0-bootstrap	gcp-foundations-bootstrap	sa-terraform-bootstrap	Seed project, CI/CD, service accounts, state bucket
1-org	gcp-foundations-org	sa-terraform-org	Folders, shared projects, org policies, logging, SCC
2-environments	gcp-foundations-envs	sa-terraform-env	Environment folders and per-env shared infrastructure
3-networks	gcp-foundations-networks	sa-terraform-net	Shared VPCs, DNS hub, firewalls, VPC-SC, NAT
4-projects	gcp-foundations-projects	sa-terraform-proj	Project factory, BU creation, workload projects

State Dependency Chain

Each stage reads from all preceding stages. For example, stage 3-networks reads bootstrap (for region config), org (for folder and project IDs), and environments (for environment folder IDs).

GCP Organization Hierarchy

Organization (foundation.badal.io / 758951886862)
|
+-- fldr-bootstrap/
|   +-- prj-b-seed          (Terraform state, SAs, KMS)
|   +-- prj-b-cicd-wif-gh   (GitHub Actions OIDC/WIF)
|
+-- fldr-common/
|   +-- prj-c-logging           (Centralized audit logs)
|   +-- prj-c-billing-logs      (Billing export + BigQuery)
|   +-- prj-c-kms               (Organization-wide KMS)
|   +-- prj-c-secrets           (Organization-wide Secret Manager)
|   +-- prj-c-artifact-registry (Shared Artifact Registry)
|   +-- prj-c-scc               (Security Command Center notifications)
|   +-- BU common folders:
|       +-- platform-0r4dp/  (WIF host project)
|       +-- devex-9c9dl/     (WIF host project)
|       +-- data-80r13/      (WIF host project)
|
+-- fldr-network/
|   +-- prj-c-dns-hub              (DNS Hub VPC)
|   +-- prj-c-interconnect         (Cloud Interconnect)
|   +-- prj-d-shared-base          (Dev base Shared VPC host)
|   +-- prj-d-shared-restricted    (Dev restricted Shared VPC host)
|   +-- prj-n-shared-base          (Non-prod base Shared VPC host)
|   +-- prj-n-shared-restricted    (Non-prod restricted Shared VPC host)
|   +-- prj-p-shared-base          (Prod base Shared VPC host)
|   +-- prj-p-shared-restricted    (Prod restricted Shared VPC host)
|   +-- prj-c-shared-base          (Common base Shared VPC host)
|   +-- prj-c-shared-restricted    (Common restricted Shared VPC host)
|
+-- fldr-pci-dss/                  (Excluded from org policies)
|
+-- fldr-development/
|   +-- {bu-name}-{suffix}/        (BU folders per environment)
|       +-- prj-{tenant}-d-{suffix}  (Tenant projects)
|
+-- fldr-non-production/
|   +-- {bu-name}-{suffix}/
|       +-- prj-{tenant}-n-{suffix}
|
+-- fldr-production/
    +-- {bu-name}-{suffix}/
        +-- prj-{tenant}-p-{suffix}

Network Topology

The network layer implements a dual Shared VPC model with a centralized DNS hub.

• Base Shared VPC: Standard workloads with internet egress via Cloud NAT
• Restricted Shared VPC: Sensitive workloads protected by VPC Service Controls, Private Google Access only
• DNS Hub: Central DNS resolution with forwarding to on-premises

Full Resource Inventory

Bootstrap Resources

• 1 folder (fldr-bootstrap)
• 2 projects (seed, CI/CD)
• 5 Terraform service accounts
• 1 GCS state bucket (KMS-encrypted)
• 1 GitHub OIDC Workload Identity pool + provider
• Google Groups (required + optional)

Organization Resources

• 3 top-level folders (common, network, pci-dss)
• 8+ shared projects (logging, billing-logs, kms, secrets, artifact-registry, scc, dns-hub, interconnect)
• 8 per-environment network host projects (base + restricted for each of 4 envs including common)
• 14+ boolean org policies
• 3+ list org policies
• Centralized log sinks (GCS, Pub/Sub, Log Bucket)
• SCC notification config
• Access Context Manager policy
• Tag keys and values (managed by tag-enforcement module)

Environment Resources (per environment)

• 3 environment folders (development, non-production, production)
• 9 shared projects (3 x monitoring, secrets, KMS)
• Tag bindings per environment folder

Network Resources (per environment)

• 2 Shared VPCs (base + restricted) with primary and secondary subnets
• Cloud NAT routers (2 per region per VPC)
• Private Service Connect endpoints
• Hierarchical firewall policies
• VPC Service Controls perimeters (restricted VPC only)
• DNS peering zones
• Tenant subnets (JSON-driven)

Project Resources

• Business unit folders (per environment)
• Workload projects attached to Shared VPCs
• Artifact Registry repositories
• WIF providers per tenant

Platform Layer

The platform layer sits on top of the 5-stage foundations pipeline and provides self-service business unit and tenant provisioning.

• Business Units create per-environment folders under foundation environment folders, a common folder with a WIF host project, a GitHub repository, and a Terraform Cloud workspace
• Tenants create per-environment GCP projects inside BU folders, a GitHub repository, per-env Workload Identity Federation service accounts, and optional Artifact Registry repositories
• Workload Repos use the foundations-template scaffold with YAML-driven configuration and CI/CD via reusable workflows

Deployed Business Units

Business Unit	Suffix	Environments	GAR Formats	Tenants
data	80r13	dev, non-prod, prod	DOCKER, PYTHON	governance, template
devex	9c9dl	non-prod, prod	DOCKER, NPM	backstage
platform	0r4dp	dev, non-prod, prod	--	gke-argocd

CI/CD Architecture

All foundation stages use GitHub Actions with Workload Identity Federation (WIF) for keyless authentication to GCP. Each stage has a dedicated service account that authenticates via OIDC through the WIF pool configured in the bootstrap CI/CD project.

The CI/CD flow is:

1. Pull request triggers terraform plan with the stage-specific SA
2. Merge to main (or environment branch) triggers terraform apply
3. For environments and networks stages, branch-per-environment deployment is used (development, non-production, production branches)

Terraform Cloud is used for platform-layer workspaces (business units and tenants), with VCS-driven runs connected to GitHub repositories.