Build Key Vault secret references for App Service and Functions configuration.
Last verified: May 2026
3-24 characters, alphanumeric and hyphens only
1-127 characters, alphanumeric and hyphens only
Leave empty to always resolve the latest version
Output will appear here...The builder constructs an @Microsoft.KeyVault(SecretUri=...) reference string by URL-assembling the vault name, secret name, and optional version into the canonical https://{vault}.vault.azure.net/secrets/{name}/{version} format. It validates each segment against Key Vault naming rules (vault names: 3-24 lowercase alphanumeric and hyphens, secret names: alphanumeric and hyphens) before generating the reference, preventing typos that would deploy successfully but resolve to nothing at runtime.
Azure App Service and Functions can reference secrets stored in Key Vault directly from application settings using a special reference syntax, eliminating the need to store sensitive values in configuration files or environment variables. The reference format @Microsoft.KeyVault(SecretUri=https://vault-name.vault.azure.net/secrets/secret-name/version) requires precise formatting and the correct combination of managed identity permissions, Key Vault access policies, and network configurations to work. This builder generates correctly formatted references and provides guidance on the required identity and access setup.
Your team migrated app secrets from appsettings to Key Vault references last sprint, and the staging deploy looked fine. Production deploys but the app starts throwing 500s on every database call. You check the configuration blade and the Key Vault reference shows 'Resolution status: Initializing' instead of green. The production App Service's managed identity was never granted the Secrets User role on the prod vault — only staging was. You add the role assignment, restart the app, and the references resolve. Lesson: validate Key Vault references in a tool like this before deploy, and add managed identity role checks to your deployment runbook.
Use the @Microsoft.KeyVault syntax with system-assigned managed identity instead of connection strings or static secrets in App Service. This eliminates the bootstrap problem of needing a credential to fetch credentials, since the managed identity is provisioned by Azure itself.
Versionless Key Vault references (.../secrets/MySecret/) only refresh after an App Service restart or 24 hours, whichever comes first. If you rotate a secret and need immediate uptake, restart the app — don't wait for the cache to expire silently.
If a Key Vault reference shows up in the portal as 'Source: Key vault Reference' but with no value, the most common cause is the managed identity missing the Secrets User RBAC role. Check role assignments at the Key Vault scope, not the subscription.
The App Service's managed identity needs the Key Vault Secrets User role (for RBAC) or GET permission on secrets (for access policies). If using RBAC, assign the role at the Key Vault scope. If the Key Vault uses a firewall, you must also add the App Service's outbound IPs to the allowed list or enable the 'Allow trusted Microsoft services' exception. The reference will fail silently with a generic error if any of these are missing.
It depends on your rotation strategy. Without a version, the reference always resolves to the latest secret version — when you rotate the secret, the app picks up the new value on restart. With a version, the reference is pinned and requires a configuration update to use a new secret version. Versionless references are simpler for automated rotation, while versioned references give you explicit control and rollback capability.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.