How to properly handle secrets in a local.settings.json file when adding the function source code to a source control repository

user_1088979 0
Viewed 6047

I have an Azure function with a few secrets in its local.settings.json file.

What are the best practices when I want to share the source code of my function in GitHub?

So far I can think of the following options, but each option has some issues or challenges:

1- Remember to change the secrets in local.settings.json anytime I commit my changes. Once the commit is done, undo changes, so I can run the function and debug it. This option is very error-prone and tedious.

2- Add local.settings.json to the .gitignore file. With this approach, people who get the code from GitHub need to remember to restore the local.settings.json

3- Store the secrets in Azure Key Vault. But this is too much for such little function that I am creating.

I wanted to ask here what are the best practices how to handle the secrets in local.settings.json in a source control repository.

azure-functions security git
4 Answers

As described here, you can add another config file (secret.settings.json) for your secrets.

{
    "ConnectionStrings": {
        "SqlConnectionString": "server=myddatabaseserver;user=tom;password=123;"
    },
    "MyCustomStringSetting": "Override Some Name",
    "MailSettings": {
        "PrivateKey": "xYasdf5678asjifSDFGhasn1234sDGFHg"
    }
}

Add your new settings file to the .gitignore. Then remove local.settings.json from the .gitignore and redact any secret values.

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    },
    "ConnectionStrings": {
        "SqlConnectionString": "--SECRET--"
    },
    "MyCustomStringSetting": "Some Name",
    "MyCustomNumberSetting": 123,
    "MailSettings": {
        "FromAddress": "local-testing123@email.com",
        "ToAddress": "receiver@email.com",
        "MailServer": "smtp.mymailserver.com",
        "PrivateKey": "--SECRET--"
    }
}

Then make sure that your extra config file is included.

var config = new ConfigurationBuilder()
    .SetBasePath(context.FunctionAppDirectory)
    .AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
    .AddJsonFile("secret.settings.json", optional: true, reloadOnChange: true)
    .AddEnvironmentVariables()
    .Build();

With this technique, at least all settings are being tracked in source control. Any secret values are safely redacted.

user_33110010

Remember to change the secrets in local.settings.json anytime I commit my changes

Use the smudge-clean mechanism. The smudge-clean is a mechanism which allows you to modify the file when it passes through the index.

The smudge/clean are filters which are runs whenever you commit file (clean) and checkout file to a working directory (smudge).

Smudge / clean

Read all about it and to set it up here:
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes

It turns out that you can write your own filters for doing substitutions in files on commit/checkout.

These are called clean and smudge filters.

In the .gitattributes file, you can set a filter for particular paths and then set up scripts that will process files just before they’re checked out (“smudge”) and just before they’re staged (“clean”).

These filters can be set to do all sorts of fun things.
So you can write your own filters for doing substitutions in files on commit/checkout.

enter image description here

user_17555980

You could commit your Json file without the secrets, then add the secrets locally and never stage the file again for commit.

Also, if you commit your file with secrets in the past and then commit it again without secrets, your secrets are still in the repository. You'll have to remove the file with pickaxe (check the filetree command, I think).

user_71365650

You should really use user secrets as described here. This works for Azure Functions too. Like this, the unencrypted file at least is stored in user profile directory and cannot be read by other users on that machine.

You don't even have to register configuration source for user secrets or environment variables. That's done by the Azure Function runtime automatically. You can access configurations from environment variables, local.settings.json and secrets.json all the same way by injecting IConfiguration:

using Burckhardt.IoT.Compressor.Data.Function.Interfaces;
using System.Text.Json;
using Microsoft.Extensions.Configuration;

namespace Burckhardt.IoT.Compressor.Data.Function.Configuration
{
    public abstract class ConfigurationLoader<T> : IConfigurationLoader<T>
        where T : class, new()
    {
        private readonly string _environmentVariableName;
        private readonly IConfiguration _configuration;

        protected ConfigurationLoader(IConfiguration configuration, string environmentVariableName)
        {
            _environmentVariableName = environmentVariableName;
            _configuration = configuration;
        }

        public T Load()
        {
            var environmentVariableValue = _configuration.GetSection(_environmentVariableName).Value;
            return JsonSerializer.Deserialize<T>(environmentVariableValue);
        }
    }
}
user_60716400
Related