Cloud Build Gke Secret Manager Injection Iam

What this solution is

This approach uses Secret Manager as the centralized secrets store while strictly separating build-time and runtime execution phases and identities, applying the principle of least privilege through granular Identity and Access Management (IAM) role assignments.

How it meets the requirements

• Build-time dependency retrieval: By defining availableSecrets (with secretManager) in cloudbuild.yaml, the secret is exposed only to designated ephemeral build steps via secretEnv. The API key is consumed dynamically during compilation without persisting in the intermediate image layers or final container image artifact.
• Runtime access without static keys: Using GKE Workload Identity, the Kubernetes Service Account used by the application Pod is mapped directly to a runtime Google Cloud Service Account (GSA). The application retrieves database credentials at runtime directly from Secret Manager via the API client library or Secrets Store CSI driver without needing exported service account keys.
• Proper IAM and Access Controls: The Cloud Build service account is granted roles/secretmanager.secretAccessor only for the private repository secret, while the application runtime service account is granted roles/secretmanager.secretAccessor only for the database secret.

Key advantages

• Zero credential persistence: Prevents secrets from being committed to source control or baked into container images.
• Granular IAM bindings: Limits blast radius by assigning roles/secretmanager.secretAccessor at the individual secret level rather than project-wide.
• Elimination of static keys: Workload Identity eliminates long-lived service account private key management and rotation overhead.
• Full auditability: All secret access requests from both Cloud Build and GKE workloads are captured in Cloud Audit Data Access logs.