App Service Configs with Key Vault Secrets
App service configs are great. They really help abstract out configuration values for app services and are way better than the old days of writing config transformations for IIS deployed apps.
But what about this strange issue when using key vault secrets to drive the app service config values?The documentation is there and it makes sense. There is just a certain level of cause and effect that would be nice if it worked more like expected. What am I referencing?
![](https://fullstackagents.com/wp-content/uploads/2023/01/Screen-Shot-2023-01-28-at-12.14.32-AM-1024x316.png)
There is a ton of value in using key vault secrets as app service config values. Here are two main reasons.
- To provide secrecy for sensitive values such as passwords or user information
- To centralize values used across app services
What Happens when Updating a Key Vault Secret
As helpful as it is to use a key vault secret, there is a drawback. If that key vault secret is used in an app service configuration value, the app service will really not refresh it immediately when the secret value is rotated or chamged. There is no event trigger to cause it to do so. As the app administrator, you can either wait up to 24 hours for when the app refreshes the value naturally. Or you can make a configuration change to the app service to force a restart.
So I know what you’re thinking. You will just restart the app service, right? Not going to work. The app service has to restart as a result of changing a configuration value for the key vault secret value to reload.
This process does not have to occur through the portal. It is proven in the video below that you can simply add a fake app config value through the Azure CLI and then immediately remove it to get the new key vault value to load. This is a hacky way to get this process working in a pipeline or some other process that is automated and doesn’t give the chance for manual intervention.