Configuring your Azure Functions

The app settings for a function app are similar to the app settings you would configure for a website: in the app settings, you insert the global options that are valid for all of the functions contained in the function app.

When you develop an Azure Function, you can have local settings—that is, the settings you want to use only when you run your functions locally (for example, using the local storage emulator or a test key for a particular service)—and Azure settings—that is, the settings you want to run when you deploy your functions in a function app.

Moreover, you have settings that are related to the runtime (for example, the configured extensions, and the logger settings).

For the local settings, you can use a file called local.settings.json. This file is, generally, created by Azure Function Core Tools (or by Visual Studio or Visual Studio Code), and it is located in the same folder that contains the project. If you don't find this file in the folder, you can simply create it. It is a JSON file that looks like this:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "MySettingValue1": "Value1",
        "MySettingValue2": "Value2"
    }
}

If you create the file by yourself, make sure that this kind of file is contained in the .gitignore file. To check this, open the .gitignore file and check whether there is a line that looks like this:

.
.
# Azure Functions localsettings file
local.settings.json
.
.

Thanks to this line, the local settings file is not included in the Git source code control, and therefore you can also enter secrets (for example, the API key to external services or a connection string to access to your database) inside it, because the file will remain exclusively on the disk of your PC; therefore, there is no possibility that your secrets will be shared with others.

The local.settings file allows you to configure the local environment, but when you push your functions to Azure, you need to configure them.

Previously in this section, you saw that you can configure the app settings using ARM template but if you want to configure your function app (and, of course, your functions running in that app), you can use two different ways:

Azure portal
PowerShell

If you want to use the Azure portal, you have to go into the function app blade and select the Configuration link in the Platform features tab:

The configuration page for the Azure Functions is exactly the same as you would have for an App Service. The differences are that for the Azure Functions, you cannot define the default documents and the path mappings, as you can do in an App Service.

In the following screenshot you can see the app settings page for a function app:

In the General settings tab, you can set the platform configuration, such as the number of bits (32-bit or 64-bit), the type of pipeline version (classic or integrated), whether you want to enable the remote debugger, and so on.

The Application settings tab, instead, contains your settings, and in particular the application settings and the connection strings.

If you want to add a new application setting, simply click on + New application setting, and insert the setting name (the key that you will use to retrieve the value) and the value:

The Update button allows you to save the new setting while the deployment slot setting option allows you to define the setting only for a slot deployment.

By default, in the setting blade, the setting values are hidden, but you can see them by clicking on the eye icon to the left of the value itself.

If you want to have more security in your settings, you can retrieve the actual value for a setting directly from an Azure key vault. You will learn how to do this later in this section.

The other way you can set the application settings is by using PowerShell, and in particular the Get-AzWebApp and Set-AzWebApp cmdlets

These cmdlets are contained in the AZ.Websites module (so remember to import the module before you use the commands using the Import-Module cmdlet) and allows you to get and push settings from and into the App Service.

Take care when you use the Set-AzWebApp because the cmdlet overwrites the entire set of the setting values, so if you want to add a new setting, you must get the settings using the Get-AzWebApp cmdlet, add a new one to the existing list, and then set the settings using the Set-AzWebApp cmdlet.

The following script shows how you can do this:

param (
 [string]$resourceGroupName, 
 [string]$appFunctionName
)

Write-Host "Retrieving settings from webapp"
$webApp = Get-AzWebApp -ResourceGroupName $resourceGroupName -Name $appFunctionName

$newAppSettings = @{}
ForEach ($item in $webApp.SiteConfig.AppSettings) {
    $newAppSettings[$item.Name] = $item.Value
}

$newAppSettings["newAppSetting01"] = "newSettingValue01"
Write-Host "Set new settings into web app"
$webApp = Set-AzWebApp -AppSettings $newAppSettings -ResourceGroupName $resourceGroupName -Name $appFunctionName

When you run the script, it retrieves all the app settings configured in the App Service, copies them into a new hashtable, modifies the newAppSetting01 value, and then applies the new hashtable into the App Service. If the newAppSetting01 exists, the script modifies it; otherwise, if the value doesn't exist, the script inserts it.

You can use a KeyVault to store secrets and tell the App Service to retrieve the configuration values directly from the key vault.

Using a KeyVault, you have the advantage that you can hide the actual values you use in a secure place. No one can enter if they don't have the credentials to access the key vault. This is the only way to ensure that sensitive data contained in the settings (for example, password, connection strings, API keys) is secure.

To retrieve a value from a key vault, you simply have to use the following syntax for the value you store in the app settings:

@Microsoft.KeyVault({referenceString})

The value of referenceString may be one of the following:

SecretUri=secretUri
VaultName=vaultName;SecretName=secretName;SecretVersion=secretVersion

You can retrieve the information to format the referenceString directly in the key vault blade by going through the following steps:

Open your key vault blade and select Secrets on the left side:

Select the secret you want to use (if you don't have the secret, you can create a new one using the Generate/Import button at the top of the blade):

Retrieve the information you need to format the referenceString mentioned before:

For example, using the information shown in the previous screenshot, the setting value to read the secret in the key vault is as follows:

@Microsoft.KeyVault(SecretUri=https://masteringserverlesskv.vault.azure.net/secrets/mysecret/067bc78c6ef648d3ad49779f3acca4ba)

Create an identity for the function app to allow the communication between the function app and the key vault. You can do this using the Identity feature that you can find in the Platform features tab:

Then, enable the system-assigned identity provided by Azure for the function app:

Add the system identity created previously in the access policies for the key vault. To do this, go to the Access policies tab in the Key Vault blade and click on the + Add new button to add a new system identity:

Finally, choose the permissions you want to give to the identity (you can do this using a template, as shown in the previous picture, or by selecting the permissions for key, secret, and certificate using the three combinations that are shown under the principal) and the identity itself (it has the same name as the function app):

If you don't give the right permission to the function app, then when you read the setting value, you can retrieve the string you insert in the settings and not the value referenced by it in the key vault.