Why does an App Service Key Vault reference fail when my account can read the secret?

In this example, a web app has a system-assigned identity and a versionless Key Vault reference. The administrator can read the secret in the portal, but the app reports an unresolved setting. The vault uses Azure RBAC. The administrator assigned Key Vault Contributor to the app identity and assumed that included secret access. What should be checked before granting broader permissions?

Compare the app identity’s object ID with the role assignment target. Then inspect the role’s data-plane permissions. Key Vault Contributor manages the vault resource; it does not give the app permission to read secret values. For this scenario, a narrowly scoped Key Vault Secrets User assignment is the relevant access to evaluate.

Keep the network path as a separate check. A correct role cannot repair a blocked private route. After the authorized role change, allow for propagation, inspect the reference status and exercise a minimal application operation. Do not log the resolved setting. The accepted result in this worked example represents the role mismatch being corrected, not a verified customer incident.

Would granting the same role to the deployment account make a difference?

The deployment account and runtime identity are different principals. Assign access to the identity that retrieves the reference; do not broaden the deployer merely to compensate for a runtime failure.

Also check whether a user-assigned identity was explicitly selected for Key Vault references. If so, inspecting only the system-assigned identity leads to the wrong conclusion even when the role name is correct.

Why does an App Service Key Vault reference fail when my account can read the secret?

Sources & further reading

2 answers

Your perspective belongs here.

0 question comments