Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Changes to Key Management in Functions V2
Azure Functions currently supports two key storage mechanisms:
- file system
- blob storage
In functions V1, the file system is the default mode. Users can switch over to blob by setting
AzureWebJobsSecretStorageType app setting to 'blob'.
In functions V2, early builds had the same default of file system. This was changed in version 2.0.12050.0-alpha. If you're running this version or a later version, keys are stored in blob by default, and users can switch to files by setting the
AzureWebJobsSecretStorageType app setting to 'files'.
This default behavior was changed because there are various scenarios that are problematic when secrets are stored in the file system of the application. For example, if you enable slots, each slot gets its own file system - this results in each slot getting its own keys and those keys swapping at the same time the content is swapped. The net effect is that keys change when the user does a swap, which is never the desired behavior.
As part of the same release that changed the default, we implemented a temporary key migration code path that would automatically copy the app keys from the file system to blob storage. We implemented this to smooth the transition - otherwise every single function app would have had its keys changed when it was upgraded to 12050. However this code is not enabled in version 2.0.12115 or newer as it was somewhat error prone. So if you are on that version or newer and you switch between the key storage mechanisms you should expect that the keys will change.
Unfortunately, this implementation detail of where the keys are stored impacts the behavior of certain ARM APIs for working with keys. If you are invoking the
listkeys action on Function App resource, the current (as of early September 2018) implementation of that API will assume that the function app is storing its keys in the file system and return those keys. If the function app has been switched over to blob, then that API may detect this and return a 409 conflict, or it may return an invalid key from the file system (depending on which version of kudu you are running). The end result is that working with function keys over ARM when running on functions 2.0.12050.0-alpha or later is currently problematic. We are working on a solution to the issue.