Allow App Service to Access Secret without version
Currently an App Service can access Secrets App Service Identity - but the secret version must be part of this configuration.
What would be helpful is to allow the App Service to get the latest version of the secret - that way a value can be centrally changed - without having to update the App Service configuration (to use the new version of the secret).
This will allow management of the data in the Key Vault - without requiring updates to the App Service to get the new value.
Greg Bryniarski
shared this idea
Hi all,
This work is underway. Please keep the feedback coming.
- Matthew
10 comments
-
Peter
commented
Any updates on this?
-
PaulE
commented
At the very least, a quick and easy way to track down all of the App Services using the Vault would be helpful so we can manually update them when an Access Secret is updated. App Registrations have had a similar issue for several years, but it wasn't really possible to track down which apps were using the expiring(ed) secrets. Since the App Services are contained within Azure the same as Key Vault, it should be rather straightforward to update the App Service whenever the Key Vault Access Secret is updated. Or, at least notify the user of which App Services should be considered for update. A value in the Key Vault reference for the secretVersion of something like "latestSecret" would certainly give us all a leg up on managing App Services using Key Vault.
-
Casper Schmidt Wandahl-Liper
commented
Any updates?
-
Lars
commented
The work has been underway for some time now. Any update?
-
J
commented
Is there any news on this update yet?
-
Priya Sajja
commented
Any update on this? ETA please.
-
Kalen Swan
commented
I see that this work started in October which is great. Any update on progress?
-
Timo Rahm
commented
In current preview version of Key Vault references for Application Settings it's possible to refer to latest version of a Key Vault Secret value without explicit version number like this: "@Microsoft.KeyVault(SecretUri=https://xyz.vault.azure.net/secrets/xyzConnectionString/)". This is logical and we like it.
You have chosen to disable this feature in GA, enforcing customers to always use specific secret version identifier at the end of the uri. Please don't do that. At the very least, please move this to a new version of the Key Vault api so that going GA won't break existing deployments.
When rotating secrets we have to create a new version of the secret value in Azure Portal, make note of the Version identifier and then go through all our ARM template parameter files of all tiers of deployment and paste the new identifier in. If the app code is not in deployable state at that point, we have to manually go through each running app's settings, update the Key Vault references and restart the apps to clear the caches.
This is a time-consuming, error-prone manual process and causes serious gaps in service availability. It makes Key Vault practically unusable in such scenarios.
Other (imho less feasible) option to fix this is to enable editing of a specific version of Key Vault secret value, so the version identifier of the secret value can stay unchanged.
-
Andy Welch
commented
KeyVault references in App Settings is a welcome improvement in KeyVault integration.
One lingering aspect to improve, I think, is to allow us to expect the latest secret version - such that we can specify the secret name and can forget about versioning if we wish. Clearly versioning also supports a stricter process. -
Anonymous
commented
is there anything we can do to help get this scheduled quickly? i do not want to write all of the tech debt code for each of the update scenarios that having this fixed would prevent me from having to write...