Question
Integrating Azure App Service with Azure Key Vault: How to securely reference secrets via managed identities
Ira Cedar
0 reputation · 18 Apr 2020, 08:50 UTC
54.2K views1
Loading…
0 reputation · 18 Apr 2020, 08:50 UTC
We need to expose a Key Vault secret to an Azure App Service web app using a managed identity, so that the secret value can be resolved at runtime without embedding credentials in code or configuration.
Key Vault access must be granted to the App Service’s system‑assigned or user‑assigned identity. The App Service plan must run on a runtime stack that supports the built‑in secret reference syntax (Azure App Service 2.0+). Cross‑subscription scenarios require tenant‑level Azure AD permissions, and secret rotation does not automatically refresh the value in a running instance unless the app is restarted or the “restart on secret change” feature is enabled.
While the documentation states that the @Microsoft.KeyVault(SecretUri=…) syntax works on all 2.0+ stacks, older stacks may silently ignore the reference, and access policy changes can cause intermittent 500 errors if the identity temporarily loses permission. Latency spikes can occur when the Key Vault resides in a different subscription or region.
26525 reputation · 18 Apr 2020, 12:58 UTC
App Service can resolve Key Vault secrets at runtime using a managed identity and the @Microsoft.KeyVault reference in Application Settings. The identity must be granted permission to Get the secret, and secret values are cached by the platform.
Confirmed: With Azure RBAC, assign Key Vault Secrets User to the App Service managed identity. This role grants secrets get permission.
Confirmed for Access Policies: The identity needs Secret Get permission on the Key Vault. Secret List is only required if you enumerate secrets; a direct SecretUri reference works with Get alone.
Confirmed: App Service caches the resolved secret value. Rotating the secret in Key Vault does not automatically update the value seen by a running instance.
Refresh requires an App Service restart or a new instance start. The platform does not push updates to in-memory settings. If you need near-real-time refresh, you must restart the app or fetch the secret via code using the identity.
Confirmed: Cross-subscription access uses the same tenant Azure AD token. Authorization latency is not subscription-dependent; network distance between App Service and Key Vault is the dominant factor.
Likely explanation: Latency spikes are more likely from region distance, Key Vault throttling, or firewall/private endpoint hops than from subscription boundaries.
Measure with Application Insights dependency telemetry for keyvault.azure.net calls, and Key Vault diagnostic logs for request duration and origin IP. Compare p50/p95 latency before and after the change.
One diagnostic detail that changes the recommendation: Is the Key Vault configured with a firewall, private endpoint, or VNet service endpoint restrictions? That determines whether outbound App Service IPs are allowed and whether you need to allow traffic or use regional peering.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 18 Apr 2020, 15:47 UTC
To avoid the "silent failure" mentioned in the uncertainty section—where a reference is treated as a literal string rather than a secret—you can verify the resolution status directly in the Azure Portal. In the Configuration blade of the App Service, a successfully resolved Key Vault reference will display a green checkmark and a "Resolved" status next to the setting.
If the status is "Unresolved" or shows a red X, check for these common configuration gaps:
azure@Microsoft.KeyVault(SecretUri=...) without trailing spaces.Key Vault Secrets User role is the same one currently active on the App Service.