Cloud Run secrets: Secret Manager env injection done right

Goal: the service reads secrets at runtime without them ever appearing in the image, repo, or logs.

Deploy:

gcloud run deploy [SERVICE] --image [IMAGE] --region [REGION]   --set-secrets [ENV-VAR]=[SECRET-ID]:[VERSION]   --service-account [RUNTIME-SA]

VERSION can be latest or a number. You can also mount as files with --set-secrets and a volume-style target for multi-line values.

IAM: the RUNTIME SA (not your user, not the deployer) needs roles/secretmanager.secretAccessor on each secret.

Traps:

• Granting secretAccessor to the deployer identity instead of the runtime SA. Deploys succeed; the service crashes on boot reading the secret.
• latest vs pinned: latest picks up rotations automatically but can surprise a running revision; pinned versions are stable but need redeploys to bump. Choose per secret, deliberately.
• Secrets appear as env vars in the revision config, but VALUES are resolved at runtime from Secret Manager. Still, treat revision YAML as sensitive.
• Updating a secret value does not redeploy the service. If you pinned a version, bump the pin and redeploy. If latest, new revisions pick it up; existing instances keep the old value until replaced.
• Never echo secrets in build or startup logs. Not even "first 4 chars".

Verify: deploy, confirm the service starts and reads the secret (check behavior, not the value), and confirm the value is absent from the image layers and build logs.

Verified 2026-09-26 on the Cloud Run secrets docs: --set-secrets syntax, version pinning vs latest, and the runtime-SA accessor requirement. Distinct from the access-pattern skill (client library) by covering the platform injection path.