highIntermediateSymptom-first#keyvault#rbac#secrets#access-policy#authorization

Key Vault RBAC — insufficient privileges for secret and certificate access

az keyvault secret show returns Forbidden: insufficient permissions

Likely source:securityconfigurationconnectivity

Focused incident mode — strips away everything but this runbook.

Symptoms

  • az keyvault secret show returns Forbidden: insufficient permissions
  • Application receives 403 from Key Vault when reading secrets or certificates
  • Key Vault access policy is missing for the application identity

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Key Vault access policy

    az keyvault show --name <KV-NAME> --resource-group <RG> --query "properties.accessPolicies" -o json

  • Key Vault RBAC role assignments

    az role assignment list --scope <KV-SCOPE> --query "[].{role:roleDefinitionName,principal:principalName}" -o table

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • enableRbacAuthorization = false
  • Identity objectId is absent from accessPolicies

Confirm before fixing

az keyvault show --name <KV-NAME> --resource-group <RG> --query "properties.accessPolicies[].objectId" -o tsv
READ

Check access policy object IDs

Fix

az keyvault set-policy --name <KV-NAME> --resource-group <RG> --object-id <PRINCIPAL-ID> --secret-permissions get list --certificate-permissions get list
CHANGE

Add the identity to the vault access policy

Expected: Access policy updated.

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
az keyvault show --name <KV-NAME> --resource-group <RG> --query "properties.enableRbacAuthorization" -o tsv
READ

Determine the access model

2
az keyvault show --name <KV-NAME> --resource-group <RG> --query "properties.accessPolicies[].objectId" -o tsv
READ

Check current access policies

3
az keyvault set-policy --name <KV-NAME> --resource-group <RG> --object-id <PRINCIPAL-ID> --secret-permissions get list --certificate-permissions get list
CHANGE

Grant access via access policy

4
az role assignment create --assignee-object-id <PRINCIPAL-ID> --role "Key Vault Secrets User" --scope <KV-SCOPE>
CHANGE

Grant access via RBAC if the vault uses RBAC

Prevention

  • Standardize on RBAC for Key Vault and disable legacy access policies.
  • Grant least-privilege roles (Key Vault Secrets User) rather than Contributor.
  • Audit Key Vault access with Azure Monitor activity log alerts.
  • Use managed identity and grant roles during resource creation.

Related runbooks

Same stack, same failure family — worth a skim.

Managed Identity not enabled on Azure resource — authentication failureshigh

Application throws ClientAuthenticationError: ManagedIdentityCredential authentication failed

AzureIntermediate3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.