Answers: <p>I have the same opinion as you, I see no point in using the Key Vault in such scenarios.</p>
  
  <p>Instead I utilize Azure App Configuration <a href="https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview</a> , 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.</p>
  
  <p>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.</p>
  
  <p>If ..settings.json is found, it means that I'm running locally. </p>
  
  <p>..settings.json is encrypted if it is not in gitignore file.</p>
  
  <p>It looks something like this: </p>
  
  <pre><code>var appConfigEndpoint = Environment.GetEnvironmentVariable("AppConfigEndpoint");
              var appConfigLabel = Environment.GetEnvironmentVariable("AppConfigLabel");
  
              if (!string.IsNullOrEmpty(appConfigEndpoint))
              {
                  config.AddAzureAppConfiguration(options =&gt;
                  {
                      options.Connect(appConfigEndpoint);
                      options.Use(keyFilter: "*", labelFilter: appConfigLabel);
                  });
              }
              else
              {
                  config.AddJsonFile("appsettings.test.json", optional: false);
              }
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-02T09:27:35.117Z
Answers: 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
Answers: RAM
Answers: CC BY-SA 4.0
Answers: 2019-05-09T19:26:31.293Z
Answers: 2019-05-09T19:26:31.293Z
Answers: Janus007
Answers: <p>We are planning to use below </p>
  
  <p><strong>Secrets</strong>  - <a href="https://azure.microsoft.com/en-us/services/key-vault/" rel="nofollow noreferrer">Azure Key-Vault</a></p>
  
  <ul>
  <li>Master Key rotation for <a href="https://docs.microsoft.com/en-us/azure/sql-database/sql-database-always-encrypted-azure-key-vault" rel="nofollow noreferrer">Always Encrypted</a> columns</li>
  <li>Certificate Store (can easily write a provider in .NET)</li>
  <li>Sensitive items like <strong>connection
  strings</strong> (hiding other resource info), passwords etc.</li>
  </ul>
  
  <p><strong>Configurations</strong> - <a href="https://docs.microsoft.com/en-us/azure/azure-app-configuration/" rel="nofollow noreferrer">Azure App Configurations</a> (still in preview)                     </p>
  
  <ul>
  <li>Watch is a wonderful method for service discovery especially if you
  need to update flags or values for operational uses.</li>
  <li>No need to re-initiate a container or instance. </li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2019-05-14T22:01:21.667Z
Answers: 2019-05-14T22:01:21.667Z
Answers: Vinay
Answers: <p>The key vault retrieval can be a performance problem. Reading from key vault takes several seconds. The Azure SLA only says it will take <a href="https://azure.microsoft.com/en-us/support/legal/sla/key-vault/v1_0/" rel="nofollow noreferrer">less than 5 seconds</a> 99.9% of the time. It does not guarantee the average time, but from my experience and hearsay, the average is about 2 seconds.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-29T12:51:03.890Z
Answers: You can get most of the application secrets just once during the application start.
Answers: Miroslav Holec
Answers: CC BY-SA 4.0
Answers: 2018-12-13T19:31:41.393Z
Answers: 2018-12-13T19:31:41.393Z
Answers: John Henckel
Answers: <p>The benefits as I see them are the general reasons to use Azure Key Vault</p>
  
  <ul>
  <li>Secrets are centrally stored with options for authorization, auditing, etc.</li>
  <li>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)</li>
  <li>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)</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-13T19:34:26.737Z
Answers: 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.
Answers: John Henckel
Answers: CC BY-SA 4.0
Answers: 2018-06-06T07:58:32.210Z
Answers: 2018-06-06T07:58:32.210Z
Answers: Nicolai Skovvart
Body: <p>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?</p>
  
  <p>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.</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-22T17:10:29.060Z
Comments: That's super cool to give your public database connection string on an error push on github :) (If you really need a reason)
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-03-22T17:12:14.643Z
Comments: 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.
Comments: Anonymous1
Comments: CC BY-SA 3.0
Comments: 2018-03-22T17:13:59.800Z
Comments: 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...
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-03-22T17:15:22.850Z
Comments: 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.
Comments: Anonymous1
Comments: CC BY-SA 3.0
Comments: 2018-03-22T17:21:28.663Z
Comments: Hu.. not really, something named 'DB_Cx_String' referenced in app setting is less problematic than 'jdbc://host:port/DBname' for exemple.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-03-22T17:35:18.130Z
Comments: 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.
Comments: Anonymous1
Comments: CC BY-SA 3.0
Comments: 2018-03-22T18:22:24.647Z
Comments: 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...
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-03-22T18:52:34.587Z
Comments: 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.
Comments: Anonymous1
Comments: CC BY-SA 3.0
Comments: 2018-03-22T20:31:24.893Z
Comments: 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)
Comments: Tensibai
Tags: <azure>
Title: Azure - Connection String in Key Vault vs Application Settings
UserDisplayName: Anonymous1
ThreadText: # Azure - Connection String in Key Vault vs Application Settings
  
  (Asked by: username_0 on 2018-03-22)
  
  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.
  
  **Tags:** azure
  
  > **Comments:**
  > **username_1**: That's super cool to give your public database connection string on an error push on github :) (If you really need a reason)  
  > **username_0**: 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.  
  > **username_1**: 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...  
  > **username_0**: 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.  
  > **username_1**: Hu.. not really, something named 'DB_Cx_String' referenced in app setting is less problematic than 'jdbc://host:port/DBname' for exemple.  
  > **username_0**: 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.  
  > **username_1**: 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...  
  > **username_0**: 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.  
  > **username_1**: 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)  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_7 on 2018-06-06. Score: 9 | Accepted answer
  
  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)
  
  > **Comments:**
  > **username_5**: 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.  
  
  ---
  
  ### Answer by username_2 on 2019-05-09. Score: 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);
              }
  
  ```
  
  > **Comments:**
  > **username_3**: 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  
  
  ---
  
  ### Answer by username_4 on 2019-05-14. Score: 0
  
  We are planning to use below
  
  **Secrets** - [Azure Key-Vault](https://azure.microsoft.com/en-us/services/key-vault/)
  
  * Master Key rotation for [Always Encrypted](https://docs.microsoft.com/en-us/azure/sql-database/sql-database-always-encrypted-azure-key-vault) 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](https://docs.microsoft.com/en-us/azure/azure-app-configuration/) (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.
  
  
  ---
  
  ### Answer by username_5 on 2018-12-13. Score: 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](https://azure.microsoft.com/en-us/support/legal/sla/key-vault/v1_0/) 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.
  
  > **Comments:**
  > **username_6**: You can get most of the application secrets just once during the application start.  
  
  ---
  
  