Cloud KMS, Secret Manager, Parameter Manager and Secret Injection

What it is

Pipelines and services need configuration (feature settings, endpoints) and secrets (passwords, API tokens, TLS keys). Neither belongs in source code or container images.

Google Cloud gives each kind of value its own managed home, controlled by IAM and audited. The skill the exam tests is choosing the right store and injecting values at the right moment.

How it works

Which service holds what

Cloud KMS basics

Keys live in key rings in a location. Each key has versions; set a rotation period so new versions are created automatically, while old versions still decrypt older data.

Grant roles/cloudkms.cryptoKeyEncrypterDecrypter on the single key to the service agent or workload that needs it, never broadly on the project.

Secret Manager

printf 's3cr3t-value' | gcloud secrets create db-password \
  --replication-policy=automatic --data-file=-
gcloud secrets add-iam-policy-binding db-password \
  --member="serviceAccount:web-runtime@shop-web-prod.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

• Grant Secret Manager Secret Accessor per secret to the runtime identity only.
• Rotation: a rotation schedule sends Pub/Sub notifications; a function adds a new version and updates the backend.
• Pin a specific version in production, or use latest deliberately, and disable old versions before destroying them.
• Choose user-managed replication or regional secrets when the secret must stay in certain locations.

Workload Identity Federation

An external pipeline presents its own OIDC or SAML token to a workload identity pool provider. Google exchanges it for a short-lived token, and the pipeline acts with roles granted to the federated identity, or by impersonating a service account.

Restrict the provider with an attribute condition, for example only one GitHub repository and branch. For GKE, Workload Identity Federation for GKE lets a Kubernetes service account act with IAM roles, so pods need no key files either.

Build versus runtime secret injection

steps:
- name: node:20
  entrypoint: bash
  args: ['-c', 'npm config set //registry.npmjs.org/:_authToken=$$NPM_TOKEN && npm ci']
  secretEnv: ['NPM_TOKEN']
availableSecrets:
  secretManager:
  - versionName: projects/acme-ci/secrets/npm-token/versions/latest
    env: NPM_TOKEN

gcloud run deploy web --image="$IMAGE" --region=europe-west1 \
  --set-secrets=DB_PASSWORD=db-password:3,/secrets/api/key=api-key:latest

The first mapping sets an environment variable from version 3; the second mounts the latest version as a file. Prefer runtime injection for application secrets: the image stays secret-free, the same image runs in every environment, and rotation needs no rebuild.

A worked example

An audit finds a database password in a Dockerfile and a service account key stored as a GitHub secret. The engineer moves the password to Secret Manager, grants Secret Accessor to the Cloud Run runtime service account only, and mounts it at runtime.

GitHub Actions now authenticates through Workload Identity Federation, with an attribute condition for the one repository. The key is deleted and key creation is blocked by organization policy.

How the exam asks about this

• "A GitHub Actions workflow must deploy to Google Cloud without storing any long-lived credential." Use Workload Identity Federation with an attribute condition on the repository.
• "The application must pick up a rotated API key without rebuilding the image." Inject it at runtime from Secret Manager.
• "Data in Cloud Storage must be encrypted with a key the company controls and rotates." Use a Cloud KMS key with a rotation period as CMEK.