Secret Management in .Net Core Application using Secret Manager and Azure Key Vault — PART 1
Here we will discuss about how to keep application secrets protected in development and production environment using .Net Core, Azure Key Vault and Azure DevOps.
This is a 3 part series in this first part we will manage the secret in development environment using Secret Manager. In part 2 we will cover how to manage secret using vault solution and in 3rd part we will cover how to manage secrets in CI/CD pipeline using Azure DevOps. So lets start with basic understanding of secrets.
What are Application Secrets?
Application ecret is a sensitive piece of information which should not widely known. All modern application use keys and passwords to communicate with other systems (such as databases, cloud api keys, payment gateways etc…). We need to keep application secrets safe to protect business from any liability or financial impact.
Managing secrets in development
In development environment it is a common practice to keep secrets in configuration file, environment variable, database or in code. This needs to be avoided as it may result in access to secrets for production environment to developers. If access management is incorrectly configured wider public will have access to it.
We need to make sure our application secrets are protected so, to do that first we will get secrets out of the code base while the application is in development and application is still be able to use the secrets. To do so we when the application starts up, secrets will also be loaded like other configuration into the memory. With this application will only get access to the secrets it’s permitted to have. In some way it will sync the process to access secrets from secret store in development and in production.
For development we will be using Secret manager which is a simple, lightweight command line tool to simulate the secret store. It is a cross platform tool works on both Windows and Linux. It stores the secret in a file by default under user profile. command line tool is capable of managing the secrets. It is important to note that it is only meant to be used in development only as, it has no explicit authentication mechanism and it stores the secret into plain text.
To start with first we have to initialize the app to use secret manager. user-secrets tool is available by default in .Net Core SDK 2.1 and above. I am using a application with following structure
To find the user-secrets tool go to root of WebAPI project (or startup project) and run command “dotnet user-secrets”, if we are using .Net Core SDK 2.1 or above we will get the following screen:
For using user-secrets command line first we have to enable the secret storage by using “dotnet user-secrets init” command.
It will add UserSecrectsId inside .csproj file of WebApi project.
Once the user secret id is created as Guid it is not required for other developers to again initialize the project. This command will create a folder under User Profile with name secrets.json. We can directly go to the user profile and view the file or we can right click on WebApi project folder in visual studio and select “Manage User Secrets”.
Now lets consider the case of connection string but we can configure for any secrets used in our code. First remove the connection string from appsettings.json
It uses nested configuration where context is nested under ConnectionStrings. Now go to command line.
In order to define the key for connection string we need to use colon to denote the hierarchy. This is a convention in .net core. Once we enter, the secret will be added to secrets.json file
Now when we run the application and will see its still connecting to the database as before, without keeping connection string in appsettings.json. Similarly we can move other secrets and credentials out of our code.
To view the secrets locally we can use “dotnet user-secrets list” command.
Next we will see how to save the secrets in production using Vault solution…
Originally published at https://gagan1983.medium.com on April 21, 2020.
