The possibility to add configuration sources in Azure Functions has just been released with latest version of Microsoft.Azure.Functions.Extensions nuget package. I have been waiting for this feature for a long time (like many people I think) because it brings to Azure Functions all the things we are used to with configuration in ASP.NET Core 😻. But that is not the only reason, it is also because with this feature you almost don't need to use keyvault references!
But before to deep dive into this topic, let's give a bit of context about configuration and secrets in Azure Functions (just skip the next section if you already are familiar with all that).
A quick reminder about configuration and secrets in Azure Functions
Configuration used by functions in a Function App are stored in settings that can be set in the Configuration section of a Function App in Azure Portal. When developing locally you have to use a local.settings.json file that will contain copies of the settings stored in Azure portal. The settings from local.settings.json will be loaded as environment variables when debugging in local. But as its name suggests, the purpose of this file is to be used for local development only: its settings are not used when the function runs on Azure. Furthermore this file should never be committed to avoid putting settings corresponding to secrets in source control.
Speaking of secrets, they should never be directly stored in application settings of a Function App (same goes for App Services by the way). Why not ? Because secrets would be available to anyone who has access to the Function App in the Azure Portal. The right way is to use an Azure Key Vault which is the Azure component for securely storing and accessing secrets 🔒. Once your secrets are in the key vault, you have to grant the Key Vault access to the identity of your Function App and you can then reference the secrets you need directly in your application settings. These are called Key Vault references because an application setting does not contain directly the value of a secret but a reference to the secret which is stored in Key Vault. When running, your function will automatically have access to the secret and its value as an environment variable, as if it was a normal application setting.
Key Vault references work for both App Services and Function Apps and are particularly useful for existing applications that have their secrets stored in settings because securing the secrets with Azure Key Vault references does not require any code change.
The downside of Key Vault references: the local debugging experience
You remember when I told you that the local settings file should not be committed to your git repository ? Well what you might not have realized is that it means when someone of your team clones the git repository containing your function he won't have this local.settings.json file which is mandatory to run your function app locally. And even if he creates manually the file, he will not necessarily know which settings to put in it. But we want to avoid him to manually copy all the settings from the azure portal or to ask a colleague to send his local settings file by email (which is a really bad practice if it contains secrets). Hopefully there are some ways to fill or generate this file.
If you use Visual Studio there is a GUI that will help you compare/modify local settings and Azure settings.
And whether or not you are using Visual Studio, you can generate the local settings file filled with Azure settings with a few Azure Functions cli commands:
Gist d51ded28cfb84b7c2714627075dffe58 /?>
This is an example of a generated local.settings.json file:
However as you can see, the settings corresponding to secrets contain the Key Vault reference values that are used by Azure to link the settings to the secrets. But this is an Azure mechanism, locally the true secrets value won't be loaded into configuration. So you will have to manually retrieve the value of the secrets in your key vault and set them manually in your local settings file. That may be okay for one secret but that gets really annoying when you have many secrets. You don't want your team members to constantly loose time copying secret values from the key vault on their local environment. I don't even talk about the loss of time understanding what is wrong when a secret value has changed and you did not realized it or the bad habits it could lead to like sending secrets by email or chat messages.
This is a terrible local debugging experience and honestly you don't want that. What you want is that your function code just works when you or one of your colleague clones or pulls a new version of the function app code. When debugging locally the code of on a ASP.NET Core application deployed in an App Service you don't have this kind of problem because usually your code directly load the secrets from the Key Vault thanks to Key Vault configuration provider.
Here comes IFunctionsConfigurationBuilder
If you are already familiar with dependency injection in Azure Functions, you already know the Microsoft.Azure.Functions.Extensions nuget package that allows you to inherit from the FunctionStartup abstract class and register the different services you want to inject into your functions (you can find more about that in the documentation). In latest version of this nuget package, a new virtual method has been added to FunctionStartup: ConfigureAppConfiguration. It allows you to specify additional configuration sources you would need in your functions.
What is awesome is that you can use all the configuration providers you are used to in ASP.NET Core and that includes the Key Vault Configuration provider. I think you understand what I am getting at 😉: instead of using key vault references in your function app settings you can simply retrieve the secrets from your key vault thanks to the configuration provider.
This way, no more copying secret, no more storing secrets values locally, no more wondering is you have the latest version of a secret. Say good by to key vault references, pull latest version of your code, press F5 and it will work!
The triggers case
Well in my title I said "you almost not longer need key vault references" and the almost is important. As the Azure Functions documentation about customizing configuration sources mentions:
For function apps running in the Consumption or Premium plans, modifications to configuration values used in triggers can cause scaling errors. Any changes to these properties by the FunctionsStartup class results in a function app startup error.
Therefore, if you use a trigger that needs a secret (the connection string of an EventHub trigger for instance), you have no other choice than to use a key vault reference. But for everything else you are good to go with Azure Key Vault configuration provider.
To conclude
To summarize, after a quick recall of how Azure Functions configuration works we have seen how Key Vault references can help to avoid having secret values in settings. We talked about the downside of this approach for the local development experience and how using the Azure Key Vault configuration provider solved that except when a secret is needed in a trigger.
Top comments (0)