Service accounts

A service account is the identity of a workload rather than a person. The GCP platform gives every project one deployer, every pipeline and workload an account of its own, and blocks service account keys everywhere, so every credential is short-lived.

What it does

A service account is an IAM principal that a VM, a Cloud Run service, a pipeline or another principal acts as. Its credentials can come from a key (a long-lived file) or, without any file, from impersonation: a principal holding roles/iam.serviceAccountTokenCreator on the account asks for a short-lived token in its name. Every project also has Google-created service agents, the accounts Google services use to act inside it, and a default Compute Engine service account that older projects granted Editor.

How BuiltForProd uses it

One deployer per project. The project-baseline unit creates sa-acme-terraform-deployer in every one of the 14 projects and makes it Owner of that project only. Token Creator on it goes to the CI accounts allowed to change the project (the Baseline's account in the core projects; the Baseline and the four blueprint repositories in the stage projects) and to the acme-platform-leads@company.com group for local runs. The generated provider of every unit impersonates its project's deployer in CI, and locally when TG_IMPERSONATE=1 is set.

Organization-scoped units. Fifteen Baseline units act at the organization or folder level, or across projects, which a project deployer cannot reach: organizations, groups and IAM, PAM, the Shared VPC host and attachments, the organization firewall and Cloud Armor policies, logging sinks, the metrics scope, Security Command Center, the secrets syncer, VPC Service Controls and the runners. Each carries a marker file org-scoped.hcl, and root.hcl then generates its provider without impersonation, so in CI it runs as sa-acme-baseline-ci itself. That account holds the organization roles those units need, roles/owner on the core and plat folders, and roles/billing.user on the billing account, but never Owner at the organization.

Workload accounts. Each workload has its own account with only the roles its job needs:

Account	Project	Used by
sa-acme-secrets-syncer	acme-core-security	The Secrets Blueprint's sync workflow
sa-acme-scc-notifier	acme-core-security	The optional Security Command Center notifier
sa-acme-runner-nodes	acme-core-auto	The optional self-hosted runner cluster's nodes
sa-acme-bastion-<domain>	acme-core-network	The optional bastions; holds no roles
sa-acme-gke-nodes	each stage project	The Web App Blueprint's GKE nodes
sa-acme-frontend	each stage project	The Web App Blueprint's front-end Cloud Run service
sa-acme-usw1-prd-spark, -etltrig, -evt (prod; one set per stage)	each stage project	The Data and ETL Blueprint's Spark batches, trigger service and Eventarc trigger

Application pods use no Google service account: Workload Identity Federation for GKE binds roles to their Kubernetes service accounts directly.

No keys. The organization policies iam.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyUpload block keys in every project, and iam.automaticIamGrantsForDefaultServiceAccounts stops new default accounts from receiving Editor. The project baseline also removes Editor from the default Compute Engine account of any project that already had it.

Terms you will see

Term	Meaning
Deployer	sa-acme-terraform-deployer, Owner of its own project, used only by impersonation.
Impersonation	Acting as a service account through a short-lived token, with Token Creator on it.
CI account	sa-acme-<key>-ci in acme-core-auto, one per repository.
Organization-scoped unit	A unit with org-scoped.hcl that runs as the Baseline's CI account.
Service agent	A Google-managed account a service uses inside the project.

Where to read more

• GCP Enterprise Baseline overview for the pipelines of the landing zone.
• Identity and Access Management for the roles these accounts hold.
• Least privilege for one identity per job.