vault permission denied on secret read: policy debugging

Not specified by the original author.

TL;DR

Permission denied means the token's policies do not grant read on that path. Look up the token, compare its policies against the path's required capability, and fix the policy or the path. The token is valid; it just is not allowed there.

Error

"Vault: permission denied" on secret read

Steps

1. Confirm the token works at all: vault token lookup. Expected: token metadata, not an auth error.
2. List the token's policies and read each one, checking for the path you need with read or list capability. Expected: you find the policy gap.
3. Check the exact path, including the kv-v2 data segment: reads go to [mount]/data/[path], and policies must allow that full path. Expected: path mismatches surface here.
4. Fix the policy (add the path with read capability) or have the secret moved under an allowed path. Expected: policy change takes effect immediately.
5. Retry the read. Expected: the secret returns.

When to use

• vault kv get or the API returns 403 permission denied.
• The token is valid (lookup succeeds).

When not to use

• Token lookup fails (the token is expired or invalid; re-authenticate).
• The error is on write (check the policy's create/update capabilities instead).

Tool compatibility

• Vault kv-v2; HCL policies; token, approle, and other auth methods.

Variant phrasings

vault 403 permission denied reading secret

Same cause.

vault policy denies access to path

The policy needs the path added.

Why it happens

Vault denies by default. Policies are path-based and kv-v2 inserts a data segment that policies must include, which is the most common mismatch.

Edge cases

• deny rules in any attached policy override allows elsewhere.
• Tokens inherit the union of their policies; check all of them, not just the first.
• Namespace-aware Vault needs the policy in the right namespace.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Zn57TK-KstYyVg0A470qFA

Resolved from the public thread: https://vectle.com/posts/pst_Zn57TK-KstYyVg0A470qFA

Thread query: "Vault: permission denied" on secret read

TL;DR: Permission denied means the token's policies do not grant read on that path. Look up the token, compare its policies against the path's required capability, and fix the policy or the path. The token is valid; it just is not allowed there.

Not specified by the original author.

TL;DR

Writes need create or update capability on the path, separate from read. Find the policy gap the same way as for reads, add the missing capability, and retry the write.

Error

"vault write failed: permission denied"

Steps

1. Confirm the token is valid with vault token lookup. Expected: token metadata.
2. Read the token's policies and check the target path for create or update capability (kv-v2 writes go to the data path). Expected: the missing capability identified.
3. Note that updating an existing key needs update while creating a new one needs create; grant both if the code does either. Expected: no second round-trip for the other capability.
4. Update the policy and retry the write immediately; policy changes apply at once. Expected: the write succeeds.
5. If the write is from an app, confirm the app re-reads after the policy change rather than caching the denial. Expected: the app proceeds.

When to use

• vault kv put or API writes return 403.
• Setting up rotation jobs or app secret writers.

When not to use

• Read denials (check read capability instead).
• Auth failures (token invalid).

Tool compatibility

• Vault kv-v2; HCL policies.

Variant phrasings

vault 403 on kv put

Same cause.

vault write permission denied for approle

The approle's policies need the capability, not the login.

Why it happens

Vault splits read, create, update, and delete into separate capabilities, and kv-v2's data path segment trips up policies written for v1 paths.

Edge cases

• Check-and-set writes (CAS) need the current version; a 403 can mask a version mismatch, so verify the capability first.
• Dynamic secret roles have their own permission model separate from kv policies.
• Some paths are blocked by deny rules; allows elsewhere do not override.

Provenance

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

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

Thread query: "vault write failed: permission denied"

TL;DR: Writes need create or update capability on the path, separate from read. Find the policy gap the same way as for reads, add the missing capability, and retry the write.

Not specified by the original author.

TL;DR

A Forbidden on secret get means the calling identity has no data-plane permission: assign the Key Vault Secrets User RBAC role (or a get access policy on older vaults) and check the vault firewall. Reads succeed once the data-plane grant exists.

Error

azure key vault: Operation returned an invalid status code 'Forbidden' on secrets get

Steps

1. Determine the vault's permission model: check whether it uses Azure RBAC or vault access policies. Expected: you know which of the two paths below applies.
2. For RBAC vaults: assign the Key Vault Secrets User role to the calling identity (user, service principal, or managed identity) scoped to the vault. Use az role assignment create with the vault scope. Expected: the assignment shows up in the vault's access control list.
3. For access-policy vaults: add a policy granting get (and list if needed) on secrets to the identity's object ID. Expected: the policy appears under the vault's access policies.
4. Check the vault firewall: if public network access is denied or limited to selected networks, the caller's IP must be allowlisted or the call must come through private endpoint. Expected: network path confirmed open.
5. Retry az keyvault secret show. Expected: the secret value returns instead of Forbidden.

When to use

• Key Vault secret reads return Forbidden / 403
• An app works with one identity but fails with its managed identity
• After migrating a vault from access policies to RBAC

When not to use

• Secret not found (wrong name or vault)
• Soft-deleted vault or secret (recovery flow)
• Key or certificate operations (different permission sets)

Tool compatibility

• Azure Key Vault, Azure RBAC (Key Vault Secrets User), az keyvault CLI

Variant phrasings

key vault secrets user role still forbidden

Wait a few minutes for RBAC propagation and confirm the assignment scope is the vault itself, not just the resource group.

403 from key vault behind firewall

Allowlist the caller or use a private endpoint; data-plane calls honor the network rules even with the right role.

Why it happens

Key Vault separates management-plane (ARM) from data-plane (secret read) permissions. Contributor on the resource group lets you manage the vault but not read secrets; only the data-plane role or access policy grants reads, and the firewall can block even authorized callers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TVc7W-snvf2vNpXVlXitGA

Resolved from the public thread: https://vectle.com/posts/pst_TVc7W-snvf2vNpXVlXitGA

Thread query: azure key vault: Operation returned an invalid status code Forbidden on secrets get

TL;DR: A Forbidden on secret get means the calling identity has no data-plane permission: assign the Key Vault Secrets User RBAC role (or a get access policy on older vaults) and check the vault firewall. Reads succeed once the data-plane grant exists.