8

For Azure Functions and WebJobs, is there any benefit to putting connection strings as Secrets in Key Vault instead of putting them directly in Application Settings (and referencing them using ConfigurationManager.ConnectionStrings)? Are Azure Key Vault Secrets primarily meant for VMs and such rather than Azure Functions and WebJobs?

It seems like it's just adding an extra step in both development (update the Secret in Key Vault and the Secret Identifier in Application Settings) and an extra step in runtime (an additional retrieval from Key Vault), with the only benefit being that the Secret in the Application Settings is an identifier instead of the actual Secret. I don't see the security benefit here, whereas there are detriments.

Anonymous1
  • 305
  • 3
  • 7

4 Answers4

9

The benefits as I see them are the general reasons to use Azure Key Vault

  • Secrets are centrally stored with options for authorization, auditing, etc.
  • Azure can be scripted to update the secrets on a timer - so in case a connection string gets in to the wrong hands, it is only valid for a day (or a week, or whatever)
  • In case the secret is shared between multiple applications, you only have to update it in one place (not the greatest benefit, but still nice)
Nicolai Skovvart
  • 106
  • 1
  • 2
3

I have the same opinion as you, I see no point in using the Key Vault in such scenarios.

Instead I utilize Azure App Configuration https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview , where I simply store all application settings. And the only string I store together within the actual app service/ func/ web job, would be the connection string for accessing the Azure App Configuration.

In my Startup where the configuration settings is applied I either read from ..settings.json, and if not present (which it should not be if running on Azure), I look for the connection string to the Azure App Configuration.

If ..settings.json is found, it means that I'm running locally.

..settings.json is encrypted if it is not in gitignore file.

It looks something like this: 

var appConfigEndpoint = Environment.GetEnvironmentVariable("AppConfigEndpoint");
            var appConfigLabel = Environment.GetEnvironmentVariable("AppConfigLabel");

            if (!string.IsNullOrEmpty(appConfigEndpoint))
            {
                config.AddAzureAppConfiguration(options =>
                {
                    options.Connect(appConfigEndpoint);
                    options.Use(keyFilter: "*", labelFilter: appConfigLabel);
                });
            }
            else
            {
                config.AddJsonFile("appsettings.test.json", optional: false);
            }
Janus007
  • 131
  • 2
0

The key vault retrieval can be a performance problem. Reading from key vault takes several seconds. The Azure SLA only says it will take less than 5 seconds 99.9% of the time. It does not guarantee the average time, but from my experience and hearsay, the average is about 2 seconds.

Unless your web app is "always on", it will be unloaded if idle for 5-20 minutes. That means, unless you have a lot of traffic, your site response times will frequently suck.

John Henckel
  • 101
  • 1
0

We are planning to use below

Secrets - Azure Key-Vault

  • Master Key rotation for Always Encrypted columns
  • Certificate Store (can easily write a provider in .NET)
  • Sensitive items like connection strings (hiding other resource info), passwords etc.

Configurations - Azure App Configurations (still in preview)

  • Watch is a wonderful method for service discovery especially if you need to update flags or values for operational uses.
  • No need to re-initiate a container or instance.
Vinay
  • 131
  • 1