When developing a Azure Function App you will likely have configuration secrets such as 3rd party API keys and certificates that you really do not want to share with anyone. These secrets will accessed by your Function’s code both on Azure and locally when developing with the Core tools or Visual Studio. But otherwise you do not want them to be made available.

The standard way for handling this outside Microsoft tools is to have a .env (dotenv) file containing a set of NAME=VALUE lines. This file can be processed by various tools that set OS process environment variables that you code can then access via standard means. A Webpack plugin also makes the variables available to code running in the browser which doesn’t have access to any OS process data.

Of course you really don’t want to check this file into version control for others to read. So, you typically add it to something like the .gitignore file. But it’s still very easy to make mistakes or there may be back door ways to access file on the OS. Thus, encryption mechanism are often use for the file at rest. Even then, someone may be able to list the OS environment at runtime and so access the secrets.

Azure Functions take an alternative and somewhat mores secure approach. It provides a database of “App Settings” as part of the underlying App Service Application Settings. Note, don’t confuse these with the identically named Function App Settings tab. Again, these are name, value pairs that the code accesses as environment variables. Otherwise, access is restricted to interactive means in the portal and via specific authenticated APIs.

Here’s a summary of how the App Settings work:

• Azure App Settings are stored in a database for each Function App.
• Function ode accesses these as environment variables.
• They can be manually viewed, created and updated in the portal (but LFs cannot be entered, even as \n).
• Remote programmatic access to the App Settings is mediated by Azure through specific secure APIs.
• A local.settings.json file containing the settings can be generated by the portal as part of a Function App content download.
  • The file name is a tad confusing, but I see why.
  • There is a bug in the main key “Values” which is provided as “Value”.
• There appears to be no way in the portal to send a file into the App Settings.
• The AzureFunctions Core Tools CLI can send the local.settings.json contents to App Settings as part of a Function Application publish to Azure. Eg func azure functionapp publish <FunctionAppName> --publish-local-settings. The file itself is NOT uploaded. If you do upload the file (say via KUDU) it will be ignored.
• The App settings can be fetched into local.settings.json via the AzureFunctions CLI.
• There is no fully programmatic way to upload the App Settings as AzureFunctions CLI will involve some interactive login and requires fairly non deterministic state setting of the Subscription and needs to be in the correct directory when run. Ideally for fully automated CI/CD the Function App path, user and password could be specified on the command line.
• Visual Studio Azure Functions tools use the AzureFunctions Core Tools CLI under the hood,  so you will need specify the --publish-local-settings option.

Categories: Uncategorized

Tagged as: Functions