Prerequisites
Azure Keyvaults – you will need two Azure Keyvaults setup. One for staging and one for production. For this post I will be using Azure Keyvaults named:
- blog-staging (stores staging secrets)
- blog-production (stores production secrets)
Secrets – in each keyvault there should be a secret by the name of “TestSecret” and the value will be “staging” in the blog-staging keyvault and “production” in the blog-production keyvault.
Azure Web Apps – just like Azure Keyvault you will need a staging and production versions of a Web App. For this post I will be using the Web Apps named:
- devdave-blog-staging
- devdave-blog-production
Asp.net Core Web Application – for this example use the template “Web Application (Model-View-Controller)”
Getting the code setup and running locally
The following nuget packages need to be installed:
Microsoft.Azure.Services.AppAuthentication
This package enables the ability to use Managed Service Identities. When running locally it uses your credentials to validate against resources (Azure Keyvault in this post). When running in Azure it uses the web apps service principal to validate against resources.
Microsoft.Extensions.Configuration.AzureKeyVault
This package adds the ability to intercept configuration requests to get app settings and route them to keyvault.
The code modifications:
Add the apsettings files for staging and production. Should look like this:
In Asp.net core 2.2 the convention is to use the value set in the environment variable “ASPNETCORE_ENVIRONMENT” to determine the appsettings file used for settings. For example if the “ASPNETCORE_ENVIRONMENT” environment variable was set to “Foo” then the system would try and load settings from a file named “appsettings.Foo.json”. If the “ASPNETCORE_ENVIRONMENT” environment variable is not set it defaults to the value “Production”.
Add a config setting to point at the correct keyvault based on environment by adding the following settings to the appsettings.Development.json and appsettings.Staging.json files.
Modify the appsettings.Production.json by adding the following settings.
Modify the program.cs file like so.
This will configure all future requests to confgi[“<key>”] to first look in the appsettings.json file, then the appsettings.<Environment>.json file and then look in the Azure Keyvault for the <key>.
Modify the HomeController like so
Then modify the Views\Home\Index.cshtml like so
The last thing is to add our user account that we login to visual studio with to the access policies of the staging and production keyvault.
You should now be able to run the Web App from your local machine. When viewing the https://localhost:####/ website you should see the value “Test Secret = staging” on the home page.
Getting the code running in Azure
Setting the environment variable
For both staging and production Web Apps set the “ASPNETCORE_ENVIRONMENT” to the correct value.
Setting up the Managed Identity for the Web App
For both staging and production go to the Identity section and turn it on. Click the Save button. Choose yes when asked if you want to create a service principal in Active Directory. Note the Object Id since you will need it in the next section.
Giving the Web App permissions in Keyvault
The last step is to allow the service principal created in the previous step to access Keyvault. Go to the staging keyvault and select the access policies and give the web apps service principal access. Best practice would be to allow the staging site access to the staging keyvault only and the production site access to the production keyvault only.
Configuration complete
The code deployed to the web app will now be able to access the key vault using its service principal. All this is using Managed Service Identity which means you no longer have to maintain any application id/secrets or certificates to access azure resources. Also none of the secrets need to be checked into source control, they can all live in keyvault where they are secure.
