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.

  • That's super cool to give your public database connection string on an error push on github :) (If you really need a reason) – Tensibai Mar 22 '18 at 17:10
  • I don't see how that would happen. I'm talking about having the connection string in Application Settings, which is stored in the cloud and never touches the code base. – Anonymous1 Mar 22 '18 at 17:12
  • As long as it is done in the cloud as gui interactions all is ok, move to pure IaC where all your cloud confiugration is done as code, and this will happen one day, that's the main reason to use a vault. If you don't find it necessary then don't use it... – Tensibai Mar 22 '18 at 17:13
  • Yeah, it's just that the Secret Identfier seems just as secure/insecure as the DB connection string. You either need to change both or neither. – Anonymous1 Mar 22 '18 at 17:15
  • Hu.. not really, something named 'DB_Cx_String' referenced in app setting is less problematic than 'jdbc://host:port/DBname' for exemple. – Tensibai Mar 22 '18 at 17:21

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)
  • 1
    It seems to me that you are you saying the key vault is only useful if multiple app servers are sharing the SAME secrets. If the connection string is used by a single app server, then there is no advantage to the key vault. – John Henckel Dec 13 '18 at 19:34

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.Use(keyFilter: "*", labelFilter: appConfigLabel);
                config.AddJsonFile("appsettings.test.json", optional: false);
  • I am too late but if you still have the same opinion, you have to change it. Configuration(your reference) is not to store secrets, it is to store configuration. DB Connection string is a secret not a configuration. KeyVault is to store secrets, Configuration is to store configuration in a centralized store. I hope that makes sense – RAM Dec 2 '19 at 9:27

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.

  • 2
    You can get most of the application secrets just once during the application start. – Miroslav Holec Jan 29 '19 at 12:51

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.