The case of the inconsistent Azure Functions host key
I recently ran into a situation using the Azure Functions default host key where I did not understand the behavior I was observing. Thanks to the help of some fantastic colleagues, we figured out what was going on. I understand what is happening now. I want to share here in hopes that my experience will help others that may run into a similar challenge.
Scenario
I needed to create an Azure Function app via an ARM template. The ARM template should create the Function app resource and set the necessary application settings. One of those app settings should be a Key vault reference to a secret which contains the default host key for the function app. My function’s application code would retrieve that and invoke another function in the app.
Also, please see Benjamin Perkin’s “Azure Function keys, keys and more keys, regenerated and synced” blog post for more observations on Azure Function key generation.
It all seems straight-forward enough. I’m very comfortable with Azure Functions and feel that I’ve got a decent grasp on ARM templates. Famous last words.
How it started
The snippet below shows my starting ARM template. Can you spot the error?
|
|
You can find the full problematic ARM template on my GitHub repo here.
The problem
After running the template, I noticed that the Key Vault secret value for the default host key was not the same value as the Azure Function portal showed.
I had two different host keys! How is this possible?
The analysis
The problem is where the FUNCTIONS_EXTENSION_VERSION application setting was set. By default, Azure Functions apps are set to use the v1 runtime. The Azure Functions v1 runtime persists its key in Azure Files (see also this).
When creating the function app via the ARM template, I did not explicitly set the FUNCTIONS_EXTENSION_VERSION app setting. Thus, the runtime was set to the v1 runtime. When retrieving the key in the ARM template (setting to a Key Vault secret), the Azure Functions runtime returned the key from Azure Files (the v1 key).
In my template, another ARM resource block set the function’s application settings, and it is there where the FUNCTIONS_EXTENSION_VERSION was set to ~3 (the v3 runtime). By setting the application setting in a separate step, that forced a restart of the function. Any change to the application settings triggers an application restart. A consequence of this restart was the Azure Functions’ runtime changing to v3.
The v3 runtime uses Azure Blob storage for persisting the keys. Thus, when inspecting at the host key via the Azure portal after the template finished executing, the key returned was the key from Azure Blob storage (the v3 key).
To summarize, the Key Vault secret value was set, and then the function app restarted. Meaning, the default host key that was retrieved and set in the Key Vault secret was a v1 key, not a v3 key. The sequence was as follows:
- Create a function app with the default runtime (~1).
- Retrieve the function’s default host key and set as a Key Vault secret.
- Set the function app’s application settings.
- The function app restarts.
- Function is running a v3 (~3) runtime.
The solution
The “fix” is to set the FUNCTIONS_EXTENSION_VERSION at the same time as the function app is created. Which, is exactly what this documentation indicates. Figures.
If I set the FUNCTIONS_EXTENSION_VERSION to ~3 at app creation time, I get the expected default host key value in Key Vault, and in the portal. They keys are the same!
It all seems so simple . . . until it is not.
The downside is that there is now a need to define the application settings twice! The majority of the application settings should be set during function creation. The site resource needs to be created before the Key Vault resource in order to set the Key Vault’s access policy allowing the site access to the Key Vault’s secrets. Thus, I need to define, again, the app settings in a separate resource block, just like I had originally! The template’s Microsoft.Web/Sites
resource looks as follows:
|
|
You can find the full ARM template on my GitHub repo.
Application settings are defined as a block. Meaning, I cannot set just the MyFunctionHostKey
. All the settings need to be defined again. I end up duplicating the settings, which I do not like.
Summary
I learned the key is to explicitly set the FUNCTIONS_EXTENSION_VERSION to the desired runtime at creation time. Setting it afterwards will result in an app restart and may yield unexpected results.