Integrating Azure App Service with Azure Key Vault: How to securely reference secrets via managed identities

Goal

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.

Constraints

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.

Uncertainty

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.

Questions

• What exact access policy permissions are required on the Key Vault for the App Service’s managed identity to retrieve a secret?
• Will rotating a secret in Key Vault automatically update the value seen by the web app, or is an explicit restart always necessary?
• How can we quantify the latency impact of cross‑subscription Key Vault access for a high‑traffic web app?