Update the Key Vault secret provider to use Azure.Identity

[liliankasem]

The existing Key Vault provider makes use of a library that is considered deprecated. We will update the Key Vault provider to use the following libraries instead: Azure.Identity, Azure.Security.KeyVault.Secrets

Motivation

What is the motivation for the change?

• Using a deprecated authentication library could lead to major security concerns in the future. It's always best to be up-to-date on security related dependencies. The impact on customers should be minimal as only the app settings change.

Impact

How many customers (roughly) would be impacted by this break? If not known, how can we figure it out? This may require host changes to gather metrics.

• // TODO: figure out impact

Compat-mode support

We'd like to enable compat-mode support for every breaking change. This may not be feasible in reality, but each proposal should include a plan to switch back to the previous behavior with a feature flag. This requirement will be evaluated on a case-by-case basis.

• As this is a potential security concern, we do not want to enable users to go back to using a deprecated library. Core behaviour will not change here, just the app settings.

Alternatives

Were any alternatives discussed? Is there any way to do this without a break?

• Connection strings are no longer an option in the new auth libraries so we would be forced in to a breaking change either way as the AzureWebJobsSecretStorageKeyVaultConnectionString app setting needs to be deprecated.

Detection

Can we detect that a customer is using this when they upgrade from v3? Is there a specific error that can be thrown with a link to migration guidance?

• //TODO: put together a query to find who will be impacted

Support

Will there be any incidents-per-day impact? Who will be the support contact? Does support need to be notified of this change? (SPOT)

• We will need to notify anyone who is currently using Azure Key Vault for secret storage

Documentation

We will need to update documentation to reflect the change in app settings.

Old

App Setting	Value
AzureWebJobsSecretStorageType	keyvault
AzureWebJobsSecretStorageKeyVaultName	Key Vault name
[Optional] AzureWebJobsSecretStorageKeyVaultConnectionString	Key Vault connection string

New

System-assigned managed identity

• Enabled system managed identity inside your Functions App
• Give the created identity Key Vault secret permissions through access policies

App Setting	Value
AzureWebJobsSecretStorageType	keyvault
AzureWebJobsSecretStorageKeyVaultUri	Key Vault URI

User-assigned managed identity

• Create a user-assigned managed identity
• Assign the user managed identity to your Functions App
• Give the created identity Key Vault secret permissions through access policies

App Setting	Value
AzureWebJobsSecretStorageType	keyvault
AzureWebJobsSecretStorageKeyVaultUri	Key Vault URI
AzureWebJobsSecretStorageKeyVaultClientId	User managed identity client ID

App registration

• Create an AAD app registration
• Give the created identity Key Vault secret permissions through access policies

App Setting	Value
AzureWebJobsSecretStorageType	keyvault
AzureWebJobsSecretStorageKeyVaultUri	Key Vault URI
AzureWebJobsSecretStorageKeyVaultTenantId	App registration tenant ID
AzureWebJobsSecretStorageKeyVaultClientId	App registration client ID
AzureWebJobsSecretStorageKeyVaultClientSecret	App registration client secret

I can't find any documentation that talks about setting AzureWebJobsSecretStorageKeyVaultName and ConnectionString to use Key Vault. I did find this documentation but this only talks about referencing key vault secrets in app settings. There's also one reference to AzureWebJobsSecretStorageType here.

I propose we add a new heading here to talk about how to use Key Vault for function secret storage.

Components impacted

What components does this change impact? Examples of areas (this list may not be exhaustive):

• Host

Performance

Does the change have any performance impact? There may need to be some implementation complete before this can be measured.

• N/A

[liliankasem]

PR: Azure/azure-functions-host#7683

[zydio]

@liliankasem I'm sorry to revive a closed issue, but there is actually a documentation page that describes those setting and is currently out of date: https://docs.microsoft.com/en-us/azure/azure-functions/security-concepts#secret-repositories

The page is still referring to AzureWebJobsSecretStorageKeyVaultName instead of AzureWebJobsSecretStorageKeyVaultUri

[liliankasem]

@mattchenderson looks like we still need more documentation updates for this breaking change, do you know who can help with that?

[jonas-lomholdt]

I have been struggling to get this working. I have followed the "new" way but nothing seems to work. When I try to create a host key I get a InternalServerError from Azure. I'm using runtime ~4.

[jonas-lomholdt]

Oh. I put my uri for AzureWebJobsSecretStorageKeyVaultUri without https:// in it. That breaks everything and will make it show InternalServerError when creating a key.

[liliankasem]

Yup, you need to use the full Vault URI as displayed in the Key Vault overview page. We can update the docs to make that more clear.

[jonas-lomholdt]

I'm suspecting for this to work with MSI it's required to use a user assigned identity @liliankasem? Otherwise how can you grant access to the vault before you have the function app principal id. Isn't this a chicken and egg problem?

[liliankasem]

I'm suspecting for this to work with MSI it's required to use a user assigned identity @liliankasem? Otherwise how can you grant access to the vault before you have the function app principal id. Isn't this a chicken and egg problem?

You can still use a system managed identity, you'll just have to go back to the vault and update the access policies to include the new function app principal ID. If we're talking about DevOps setup, there should be a way to get the principal ID as an output of a function app deployment and pass that to a keyvault creation or policy update task, but I'm not an expert on that.