Security proposition for KeyVault secret usage

[FranckSix]

In many Azure services, we can use Key Vault references directly in configuration values:

@Microsoft.KeyVault(SecretUri=https://MyDevKv.vault.azure.net/secrets/SqlPassword)

This approach keeps the secret inside Key Vault and allows the application to resolve it at runtime.

With ARM templates, this scenario was natively supported through Key Vault parameter references:

"keyVaultSqlPassword": {
   "reference": {
      "keyVault": {
         "id": "/subscriptions/id/resourceGroups/rgName/providers/Microsoft.KeyVault/vaults/MyDevkv"
      },
      "secretName": "SqlPassword"
   }
}

With Bicep, the closest equivalent is:
kv.getSecret('SqlPassword')
or
az.getSecret(id, rgName, MyDevkv, SqlPassword)

However, this retrieves the actual secret value during deployment. and in WepApp Environnement variable.

Before (ARM / Key Vault Reference)

{
    "name": "SqlPassword",
    "value": "@Microsoft.KeyVault(SecretUri=https://MyDevkv.vault.azure.net/secrets/SqlPassword)",
    "slotSetting": false
}

The application setting contains only a reference to Key Vault.

After (Bicep with getSecret())

{
    "name": "ApplicationInsightKey",
    "value": "MySuperStrongPassword!",
    "slotSetting": false
}

The actual secret value is stored in the Web App configuration.

Why this matters
Secrets are no longer isolated in Key Vault.
Application administrators can potentially view sensitive values.
Secret rotation becomes more complicated.
The intent is less clear during code reviews.
It encourages retrieving secrets rather than referencing them.

Proposed enhancement

Add support for a Key Vault reference API that expresses intent clearly:

Usage:

appSettings: {
   SqlPassword: kv.getReference('SqlPassword')
}

Which would compile to:
@Microsoft.KeyVault(SecretUri=https://MyDevKv.vault.azure.net/secrets/SqlPassword)

This would provide a secure and intuitive migration path from ARM templates while promoting the principle of keeping secrets in Key Vault whenever possible.

[stephaniezyen]

Is your original ARM Template example code block in your parameters.json file?

[FranckSix]

Yes stephaniezyen, its from my original parameters file json. I removed personnal data before supply.

[shenglol]

Thanks for the proposal. There are two different mechanisms involved here:

• A Key Vault reference in an ARM parameters file is resolved by ARM at deployment time. Bicep models this scenario with getSecret().
• @Microsoft.KeyVault(...) in an app setting is an App Service/Functions runtime convention. From Bicep and ARM's perspective, it is simply a string value that the resource provider interprets later.

Adding kv.getReference() would therefore introduce resource-provider-specific domain knowledge into the Bicep language, which we don't plan to support. You can preserve the runtime Key Vault reference without retrieving the secret during deployment by constructing the string directly, for example:

value: '@Microsoft.KeyVault(VaultName=${keyVault.name};SecretName=SqlPassword)'

You can also use the SecretUri= form from the issue. If no secret version is specified, App Service uses the latest version and automatically refreshes it after rotation. See Use Key Vault references as app settings for the supported formats and behavior.

Closing this as not planned because the desired deployment behavior can already be expressed in Bicep without adding an RP-specific language feature.