gcp secret manager: permission secretmanager.versions.access denied

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

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

Grant it on the specific secret, not the project, when you can: gcloud secrets add-iam-policy-binding [SECRET-ID] --member serviceAccount:[SA-EMAIL] --role roles/secretmanager.secretAccessor latest vs pinned: - latest` always resolves to the newest enabled version.

Steps

1. ```python

from google.cloud import secretmanager client = secretmanager.SecretManagerServiceClient() name = "projects/[PROJECT]/secrets/[SECRET-ID]/versions/latest" payload = client.accesssecretversion(request={"name": name}).payload.data.decode("utf-8")

2. The resource name format is strict: projects/[PROJECT]/secrets/[SECRET-ID]/versions/[VERSION]. VERSION can be a number or `latest`. Get any segment wrong and you get NotFound, not a helpful hint.

3. IAM: the caller needs the secretmanager.versions.access permission, which roles/secretmanager.secretAccessor grants. Grant it on the specific secret, not the project, when you can:

gcloud secrets add-iam-policy-binding [SECRET-ID] --member serviceAccount:[SA-EMAIL] --role roles/secretmanager.secretAccessor

4. latest vs pinned:
- `latest` always resolves to the newest enabled version. Convenient, dangerous with rotation: a rotation can change the value under a running process.
- Production services should pin a version number and bump it deliberately, or handle rotation explicitly.
- Disabled and destroyed versions error on access. Destroyed is permanent; there is no undelete.

5. Do not:
- Log secret values. Not even at debug. The access call returns bytes; decode and use, never print.
- Store the secret in an env var baked into a container image. Mount it at runtime (Cloud Run --set-secrets) or fetch at startup.
- Grant secretmanager.admin to workloads. Accessor is enough.

6. Verify: access from the workload identity (not your user) and confirm the value shape without printing it, e.g. check length or a known prefix.

## When to use

You are seeing this: ``python from google.cloud import secretmanager client = secretmanager.SecretManagerServiceClient() name = "projects/[PROJECT]/secrets/[SECRET-ID]/versions/latest" payload = client.access\_secret\_version(request={"name":... Use this skill when you run into "Secret Manager access pattern: versions/latest and the secretAccessor role".

## 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.

Verified 2026-09-26 on the Secret Manager access docs: resource name format, access call pattern, version states. The secretAccessor role and versions.access permission are documented IAM. Distinct from the mined Lambda skill, which covers the Node client on AWS.