An enterprise organization is designing a Continuous Integration and Continuous Delivery (CI/CD) pipeline on Google Cloud to deploy microservices to Google Kubernetes Engine (GKE). Security governance mandates that build jobs must execute strictly within non-public network perimeters, and pipeline processes must authenticate to GCP resources without storing static, long-lived credentials or service account key files in code repositories. Which architecture strategy should the cloud architect choose to meet these security and pipeline requirements?
- Configure Cloud Build triggers using private worker pools peered with your VPC network, and authenticate the build execution using short-lived credentials managed via Workload Identity Federation and least-privilege IAM service accounts.Answer
- BConfigure Cloud Build triggers to download JSON service account key files stored directly within the root of the application source code repository during the build step execution.
- CConfigure default Cloud Build workers on public pools and assign the primitive Project Editor role to the default build service account to simplify resource provisioning across environments.
- DAssign the Service Account Admin role (roles/iam.serviceAccountAdmin) to developer identities so the build pipeline trigger can impersonate deployment service accounts.
Answer
Configure Cloud Build triggers using private worker pools peered with your VPC network, and authenticate the build execution using short-lived credentials managed via Workload Identity Federation and least-privilege IAM service accounts.
The correct strategy uses Cloud Build private worker pools peered with a VPC to satisfy private network perimeter constraints, combined with short-lived credentials via Workload Identity Federation or dedicated service accounts to avoid embedding permanent credentials or service account keys in repositories.
Step-by-Step Solution
Key Concept
Secure CI/CD Pipeline Architecture with Cloud Build Private Pools and Workload Identity