Most ASP .Net Core applications have configurations that contains secret keys or database connection strings that should not be stored in the configuration files or source control. This article shows you how to secure the configurations using the Secret Manager and the Azure Key Vault to make sure the sensitive information are not being exposed.
You can download the code or see the code at GitHub.
This project was built using the Paging and Sorting Application HERE as the starting point.
During Development
During development you can store the configurations using the Secret Manager so that the configurations are not checked into the source control. To get started, you can run the init command below in your project directory to initialize the Secret Manager:
|
1 |
dotnet user-secrets init |
The init command will create a unique identifier (GUID) that uniquely identifies the project, this unique identifier is inserted into the .csproj file after you run the init command:
|
1 2 3 4 |
<PropertyGroup> <TargetFramework>net5.0</TargetFramework> <UserSecretsId>15e7f8bc-956d-4945-8722-204e6b790614</UserSecretsId> </PropertyGroup> |
To create a key-value pair for a configuration, you can run the set command:
|
1 |
dotnet user-secrets set [configKey] [configValue] |
To list all the configuration you can run the list command:
|
1 |
dotnet user-secrets list |
Below is an example:
If you have connection strings defined in the ConnectionStrings section in the appsettings file such as:
|
1 2 3 |
"ConnectionStrings": { "StarterConn": "Data Source=serverName;Initial Catalog=databaseName;Integrated Security=True;" } |
You can just prefix the configuration section followed by a colon, for example:
|
1 |
dotnet user-secrets set ConnectionStrings:StarterConn "Data Source=serverName;Initial Catalog=databaseName;Integrated Security=True;" |
Below are the list of commands you can use in the Secret Manager:
|
1 2 3 4 5 |
clear Deletes all the application secrets init Set a user secrets ID to enable secret storage list Lists all the application secrets remove Removes the specified user secret set Sets the user secret to the specified value |
It will be best to document the configurations needed in the README file for each project so that others can easily set up the project.
Note that the configurations stored in the Secret Manager will take higher precedence than the configurations in the appsettings file. This is due to the code inside the Host.CreateDefaultBuilder in Program.cs.
Deploying to Azure
For securing the configurations in Azure you can store the configurations in Azure Key Vault and point the application configurations to the Key Vault using Managed Identities. First you need to enable the System Assigned Identity for your Web Application or API by going to Settings -> Identity, set the Status to On and save it. I have set my front end application as below:
The Object ID generated is the identity of your application that is needed in Key Vault. Next add a secret to an Azure Key Vault resource. In this case I have created a secret named APIUrl (which is the name of the configuration, but you can give it a different name if you prefer) that has the URL of the API:
Next click on the Access Policies of the Key Vault and add an Access Policy:
Grant the Get permission to the front end application by pasting the Object Id of the front end application:
Be sure to save the Access Policy:
Now you can point your front end application’s configuration to the Key Vault secret with the syntax:
|
1 |
@Microsoft.KeyVault(VaultName=NameOfKeyVault;SecretName=NameOfSecret) |
as shown below:
Besides the application configurations, you can also do the same for the database connection strings in the API as shown below:
And that’s all. Hope this will help you in securing your application configurations.
[…] For instructions on how to use the .net Secret Manager check out Securing ASP .Net Core configurations using the Secret Manager and Azure Key Vault. […]