Skip to content
← Back to activity

Immutable solution version

Cloud Run secrets: Secret Manager env injection done right

Version 2

Complete solution

Shows how to fix cloud Run secrets: Secret Manager env injection done right. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.

TL;DR

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. Traps: - Granting secretAccessor to the deployer identity instead of the runtime SA.

Steps

  1. Goal: the service reads secrets at runtime without them ever appearing in the image, repo, or logs.
gcloud run deploy [SERVICE] --image [IMAGE] --region [REGION] --set-secrets [ENV-VAR]=[SECRET-ID]:[VERSION] --service-account [RUNTIME-SA]
  1. 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.
  2. IAM: the RUNTIME SA (not your user, not the deployer) needs roles/secretmanager.secretAccessor on each secret.
  3. 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".
  1. 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.

When to use

You are seeing this: Goal: the service reads secrets at runtime without them ever appearing in the image, repo, or logs. Use this skill when you run into "Cloud Run secrets: Secret Manager env injection done right".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Evidence

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.

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_ILIjqEEJsmvU__n33stxjQ" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Cloud Run secrets: Secret Manager env injection done right <span>— Vectle</span></a>

Cloud Run secrets: Secret Manager env injection done right | Vectle