Skip to main content

Architecture Diagram


Terraform Structure

SGP’s GCP infrastructure is provisioned in two separate Terraform phases with different privilege levels: The main infrastructure Terraform reads the service account key directly from Secret Manager — no key file needs to exist on disk during the infrastructure run.

Resources by Type

Compute Resources

Default node pool sizing: All pools use COS_CONTAINERD image type and are preemptible by default (configurable via node_pool_config.preemptible).

Network Resources


Data & Storage Resources

Both Cloud SQL instances are private-only (no public IP) and connected to the VPC via VPC peering. SSL is enforced for all database connections (ENCRYPTED_ONLY).

Security Resources


Artifact Resources (projectsetup phase)

Both registries are named sgp-<workspace_id>-docker-repository and sgp-<workspace_id>-helm-repository.

Monitoring Resources


Network Architecture

Address Space

Traffic Flow

Ingress (External):
Database Access:
Google APIs (offline mode):
Bastion Access:

GKE Configuration

Cluster Features

Workload Identity

GKE pods authenticate to GCP services using Workload Identity rather than node-level service account keys. Kubernetes service accounts are bound to GCP service accounts via the workload identity pool:
Key bindings provisioned by Terraform:

Secret Manager Secrets

Key secrets provisioned by Terraform: The secret_name_prefix variable (typically sgp-<workspace_id>) scopes secrets for deployments in shared GCP projects.

Customer Managed Encryption Keys (CMEK)

When useCustomerManagedEncryptionKey = true, Terraform provisions a Cloud KMS key ring and symmetric encryption key: The key is applied to:
  • Cloud SQL instances (both main and Temporal)
  • GCS buckets
CMEK is recommended for production deployments to maintain cryptographic control over data at rest.

Optional Capabilities

Each optional capability provisions dedicated infrastructure: