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
  • 2
  • 7
  • 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
  • Right, but 'DB_Cx_String' is what's referenced in the app, just from the Application Settings in the cloud instead of from the Azure Key Vault. – Anonymous1 Mar 22 '18 at 17:35
  • I said in apps settings, when you will define the whole stack in automation, your XX string won't appear anywhere, just retrieved in app from vault... – Tensibai Mar 22 '18 at 18:22
  • If your secret identifier gets compromised, you then need to rotate both your DB key and your secret identifier. But on the other hand, you can restrict the secret identifier so that only the app in question can access it, so there may be some benefit if you're storing the automation script in a way where people can access the automation script but not the actual app. – Anonymous1 Mar 22 '18 at 18:52
  • The main goal is that the connection string never appear anywhere out of app runtime, of course the acl to restrict reading of the secret has to be properly defined. That's the overall idea behind any vault, the advantage is that you can rotate the secret without redeploying the app (no code change if the app ask for it in case of failure) – Tensibai Mar 22 '18 at 20:31

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
  • 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
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
  • 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 02 '19 at 09:27
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