What permissions does the App Service need to read Key Vault secrets?

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.

Should I include the secret version in the reference?

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.

Azure Key Vault Reference Builder

IAM & SecurityAzure

Build Key Vault secret references for App Service and Functions configuration.

Key Vault Reference Configuration

Vault Name

3-24 characters, alphanumeric and hyphens only

Secret Name

1-127 characters, alphanumeric and hyphens only

Secret Version (optional)

Leave empty to always resolve the latest version

Output Format

Key Vault Reference Output

Output will appear here...

About This Tool

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.

When to Use This Tool

•Generating Key Vault references for App Service configuration settings that pull database connection strings from a vault at runtime
•Building versioned secret references that pin to a specific secret version for controlled rotation and rollback
•Creating references for Azure Functions app settings that use system-assigned managed identity for authentication
•Generating the correct reference syntax for multi-vault architectures where different secrets come from different Key Vaults

Frequently Asked Questions

What permissions does the App Service need to read Key Vault secrets?: 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.
Should I include the secret version in the reference?: 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.

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.