Azure-docs: Key Vault reference works without version number

[TsuyoshiUshio]

Key Vault reference works without version number like this.

@Microsoft.KeyVault(SecretUri=https://<MYKEYVAULT>.vault.azure.net/secrets/eShopStorageAccountCS/)

However, this documentation said that It is not available.

> Versions are currently required. When rotating secrets, you will need to update the version in your application configuration.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7feaa3d0-7233-a3cb-cb9b-a9a55b1f0d7a
• Version Independent ID: f41f9d51-52f8-1f45-1043-1344a3b74458
• Content: Key Vault references - Azure App Service
• Content Source: articles/app-service/app-service-key-vault-references.md
• Service: app-service
• GitHub Login: @mattchenderson
• Microsoft Alias: mahender

[MonikaReddy-MSFT]

@TsuyoshiUshio ,Thanks for brining this to our attention. We will investigate it further and update you shortly.

[MonikaReddy-MSFT]

@TsuyoshiUshio , Thanks again for bringing this to our attention! The Document has been updated. We will now proceed to close this thread as resolved, but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

[jacobmohl]

Hi again - The refrence without version works only with the SecretURI format and not with the alternate format with VaultName, SecretName.

Ex.
WORKS: @Microsoft.KeyVault(SecretUri=https://[MYKEYVAULT].vault.azure.net/secrets/[MYSECRET]/)
DONT WORKS: @Microsoft.KeyVault(VaultName=[MYKEYVAULT];SecretName=[MYSECRET])

Is that desired behavior?

[MonikaReddy-MSFT]

Hello @jacobmohl and @TsuyoshiUshio - Thank you for bringing this to our attention. However after finding out with Product team here, they have mentioned that the Feature doesn't fully support references without versions yet. The Scenario you have shared is undefined behavior that we wont remove but do not support either. And thats why I removed the command without the version number.

I hope this information helps.!!

[scholtes]

I believe you actually can reference the latest version using the alternative format. Like so:

1. ✔️ @Microsoft.KeyVault(SecretUri=https://[MYKEYVAULT].vault.azure.net/secrets/[MYSECRET]/)
2. ❌ @Microsoft.KeyVault(VaultName=[MYKEYVAULT];SecretName=[MYSECRET])
3. ✔️ @Microsoft.KeyVault(VaultName=[MYKEYVAULT];SecretName=[MYSECRET];SecretVersion=)

The trick here being to include SecretVersion= without specifying a value after it. I tested this in an Azure Function application setting and it seems to work (i.e., the application settings UI validates them accordingly, and the test Azure Function that I ran successfully grabbed the secret when using option 3, but not option 2).

If this is intended behavior, it might be useful to include in the docs (edit: pinging @MonikaReddy-MSFT, sounds like you might be able to verify with the Product team whether this behavior is a recent change or still a side-effect of the unsupported behavior).

---

On a side note (I can open a separate issue for this if desired), what I would also like to see in the documentation is whether the alternative syntax will automatically resolve the URI's correct domain for Azure Clouds other than commercial (e.g. US Government cloud). For example, suppose I have an application with a Key Vault reference that looks like so:

@Microsoft.KeyVault(SecretUri=https://[MYKEYVAULT].vault.usgovcloudapi.net/secrets/[MYSECRET]/)

The domain name is coming from the page Access Azure Key Vault behind a firewall. Will this automatically resolve using the alternative syntax if the reference is in an application that is deployed in a US Government region? Like so:

@Microsoft.KeyVault(VaultName=[MYKEYVAULT];SecretName=[MYSECRET];SecretVersion=)

I believe the answer is yes, but I have not tested this yet. Would be good to mention in the documentation, because if this is supported, then it means that configuration which stores these references across multiple environments can be written to be agnostic of which cloud they are in reference to.

[mcalnd70]

This feature really does need a LATEST VERSION of a secret to be useful here. Hard-coding secret version numbers is doomed to failure