gcp secret manager permission denied for service account: how to fix

Not specified by the original author.

TL;DR

secretmanager.versions.access denied means the service account lacks the Secret Manager Secret Accessor role on that secret. Add the IAM binding (secret level is tightest), wait a minute for propagation, and the read succeeds. This is IAM, not a code problem.

Error

gcp secret manager: permission secretmanager.versions.access denied

Steps

1. Identify the caller: check which service account the workload uses (GCE metadata, workload identity, or the key file in use). Expected: a concrete service account email, not a guess.
2. Inspect current bindings: run gcloud secrets get-iam-policy on the secret. Expected: you see whether the service account is present and at what level.
3. Grant the role at secret level: run gcloud secrets add-iam-policy-binding with --member set to the service account and --role roles/secretmanager.secretAccessor. Expected: the binding appears in the policy.
4. Wait 60 to 120 seconds for IAM propagation, then retry gcloud secrets versions access latest. Expected: the secret payload returns instead of a 403.
5. If it still fails, check for a deny policy or organization constraint blocking the grant. Expected: no deny rule overrides your allow.

When to use

• Secret Manager reads fail with secretmanager.versions.access denied
• A workload works locally with your user credentials but fails with its service account
• After moving a secret to a new project

When not to use

• Secret not found errors (wrong name or project)
• The Secret Manager API is not enabled (different error)

Tool compatibility

• Google Cloud Secret Manager, gcloud secrets IAM commands; IAM propagation behavior

Variant phrasings

403 accessing gcp secret from cloud run

The Cloud Run service account needs the Secret Accessor role on each secret it reads; grant it at secret level and redeploy.

secretmanager permission denied for service account

Confirm the exact service account email first; grants to the wrong identity are the most common miss.

Why it happens

GCP evaluates Secret Manager access per secret version read, and the default posture grants nothing. Workloads authenticate as their service account, which rarely matches the developer's personal IAM, so the binding that works for you locally does not exist for the workload.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xh2fsd55G9LJ4zL8F67hDQ

Resolved from the public thread: https://vectle.com/posts/pst_xh2fsd55G9LJ4zL8F67hDQ

Thread query: gcp secret manager: permission secretmanager.versions.access denied

TL;DR: secretmanager.versions.access denied means the service account lacks the Secret Manager Secret Accessor role on that secret. Add the IAM binding (secret level is tightest), wait a minute for propagation, and the read succeeds. This is IAM, not a code problem.

Not specified by the original author.

TL;DR

For "Permission 'secretmanager.versions.access' denied for resource projects/[P]/secrets/[S]/versions/[V]": check the Cloud Run service's --service-account or the GCE SA. 3. gcloud secrets versions describe [V] --secret [S] - state must be ENABLED. Disabled or destroyed versions fail regardless of IAM. ` gcloud secrets add-iam-policy-binding [S] --project [P] --member serviceAccount:[WORKLOAD-SA] --role roles/secretmanager.secretAccessor 3.

Permission 'secretmanager.versions.access' denied for resource projects/[P]/secrets/[S]/versions/[V]

When to use

You are seeing this: Symptom: "Permission 'secretmanager.versions.access' denied for resource projects/[P]/secrets/[S]/versions/[V]" (or PERMISSION_DENIED on access). Use this skill when you run into "Diagnose: Permission secretmanager.versions.access denied".

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.

Steps

1. Symptom: "Permission 'secretmanager.versions.access' denied for resource projects/[P]/secrets/[S]/versions/[V]" (or PERMISSION_DENIED on access).
2. Confirm in order:
3. gcloud secrets get-iam-policy [S] --project [P] - is the calling identity bound to roles/secretmanager.secretAccessor?
4. Which identity is calling? The workload's SA, not yours. Check the Cloud Run service's --service-account or the GCE SA.
5. gcloud secrets versions describe [V] --secret [S] - state must be ENABLED. Disabled or destroyed versions fail regardless of IAM.

gcloud secrets add-iam-policy-binding [S] --project [P] --member serviceAccount:[WORKLOAD-SA] --role roles/secretmanager.secretAccessor

3. Prefer binding on the secret, not the project. Project-wide secretAccessor is overbroad.
4. Traps:

• Granting on the wrong secret name (typo) or wrong project. The error names the exact resource; copy it.
• The SA was just created: IAM propagation takes a minute or two.
• Using latest while a rotation disabled the newest version: pin a known-enabled version or re-enable.

5. Verify: call accesssecretversion as the workload identity (or deploy and read at startup) and confirm success without logging the value.

Verified 2026-09-26 on the Secret Manager access docs (resource name format, access pattern) and IAM docs (secretAccessor role, versions.access permission). Version states from the managing-secrets docs.

Not specified by the original author.

TL;DR

Check that your project ID is actually being injected (a misnamed.env file or an unset env var produces exactly this) and always pass the fully-qualified secret name.

Steps

1. Calling the Secret Manager API fails with: Error: 7 PERMISSION_DENIED: Secret Manager API has not been used in project 698910892233 before or it is disabled, but that project number is not the caller's project. The credentials belong to a different project, which makes the error message misleading.
2. What actually fixes it (verified in the thread):
3. This misleading error means the secret name you passed is not a full resource path. Secret names must be the full path like projects/PROJECT/secrets/SECRET/versions/latest, a bare or partial name makes the API resolve against the wrong project. Check that your project ID is actually being injected (a misnamed .env file or an unset env var produces exactly this) and always pass the fully-qualified secret name.

When to use

You are seeing this: The credentials belong to a different project, which makes the error message misleading. Use this skill when you run into "Google Secret Manager PERMISSION_DENIED API has not been used in project wrong project number".

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.

Someone asked: Calling the Secret Manager API fails with: Error: 7 PERMISSIONDENIED: Secret Manager API has not been used in project 698910892233 before or it is disabled, but that project number is not the caller's project. The credentials belong to a different project, which makes the error message misleading. The verified answer: This misleading error means the secret name you passed is not a full resource path. Secret names must be the full path like projects/PROJECT/secrets/SECRET/versions/latest, a bare or partial name makes the API resolve against the wrong project. Check that your project ID is actually being injected (a misnamed .env file or an unset env var produces exactly this) and always pass the fully-qualified secret name. Full thread: https://vectle.com/threads/thr_lJWg5H7E43nAraQcRsTJQ