Visual Studio (VS) now supports adding Azure Key Vault as a Connected Service, for Web Projects ( ASP.NET Core or any ASP.NET project). Enabling this from the Connected Service makes it easier for you to get started with Azure Key Vault. Below are the prerequisites to use the Connected Service feature
- An Azure subscription. If you do not have one, you can sign up for a free account.
- Visual Studio 2017 version 15.7 with the Web Development workload installed. Download it now.
- An ASP.NET 4.7.1 or ASP.NET Core 2.0 web project open.
When selecting ‘Secure Secrets with Azure Key Vault’ option from the list of Connected Services provided it takes you to a new page within Visual Studio with your Azure Subscription associated with Visual Studio Account and gives you the ability to add a Key Vault to it. VS does generate some defaults for the Vault Name, Resource Group, Location and the Pricing Tier which you can edit as per your requirement. Once you confirm to the Add the Key Vault, VS provisions the Key Vault with the selected configuration and modifies some things in your project.
In short, VS adds
- a bunch of NuGet packages to access Azure Key Vault
- Adds in the Keyvault Url details
- In ASP.NET Web project VS modifies the configuration file to add in the AzureKeyVaultConfigBuilder as shown below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
To start using Azure Key Vault from your application we first need to add some Secrets to the Key Vault created by Visual Studio. You can add a secret to the portal using multiple ways, the most straightforward being using the Azure Portal. Once you add the Secret to the Key Vault, update the configuration file with the Secret names. Below is how you would do for an ASP.NET Web Project. (MySecret and VersionedSecret keys)
1 2 3 4 5 6 7 8
The values dummy* are just dummy values and will be overridden at runtime from the Secret Values created in the Key Vault. If the Secret with the corresponding name does not exist in Key Vault, then the dummy values will be used.
When VS creates the Vault, it adds in the user logged into VS to the Access Policies list. When running the application, the AzureKeyVaultConfigBuilder uses the same details to authenticate with the Key Vault.
If you are not logged in as the same user or not logged in at all the provider will not be able to authenticate with the Key Vault and will fallback to use the dummy values in the configuration file. Alternatively you could specify connection option avaiable for AzureServiceTokenProvider
Secrets and Versioning
The AzureKeyVaultConfigBuilder requests to get all the Secrets in the Key Vault at application startup using the Secrets endoint. This call returns all the Secrets in the Key Vault. For whatever keys in the AppSettings that has a match with a Secret in the vault, a request is made to get the Secret details, which returns the actual Secret value for the keys. Below are the traces of the calls going out captured using Fiddler.
It looks like at the moment the AzureKeyVaultConfigBuilder get only the latest version of the Secrets. As you can tell from one of my Secret names (VersionedSecret), I have created two versions for the Secret, and the config builder picks the latest version. I don’t see a way right now whereby I can specify a specific secret version.
The Visual Studio Connected Services makes it easy to get started with Azure Key Vault and move your secrets to a more secure store, than having it around in your configuration files.