Managing sensitive information and secrets in config files is something we all have to deal with on a daily basis. Unfortunately, this is also something that we still get wrong:
a) config files with production secrets/keys
b) source controll littered with secrets/keys
c) obscure file transformations and processes to update secrets as we move from one environment to another.
However, there are a few options available to us.
- For local development, NET Core has the notion of User Secrets which we can use to store sensitive information outside the application folder and away from source control.
- Azure Key Vault (recommended way)
- Azure App Configuration Service (another solid approach)
Azure Key Vault and Azure App Configuration can be used for local development as well but they require a bit more setup to allow you app to authenticate and pull the necessary info. I've talked about using KeyVault in earlier posts.
In many cases, organizations may also choose to use multiple KeyVaults, usually one per environment, to help better manage and isolate application secrets. Unfortunately, this is not always an option, since many companies don't always allow access to Azure. So what's the next best option? User Secrets
User secrets is an stop-gap when you can't use the two Azure services mentioned above. User Secrets uses a local file (secrets.json) to store your applicaiton secrets. Depending on the OS, this file ends up in one of the following locations:
- Windows:
%APPDATA%\microsoft\UserSecrets\<userSecretsId>\secrets.json - Linux:
~/.microsoft/usersecrets/<userSecretsId>/secrets.json - Mac:
~/.microsoft/usersecrets/<userSecretsId>/secrets.json
Other Considerations
This approach should be used very sparingly as there are a lot of downsides:
- No automated way for cleaning up old
secrets.jsonfiles. Sensitive info in there can linger for ever secrets.jsonfiles store secrets in plain text. Anyone with access to your machine can look at the well-known location and start pulling secrets out of the files- it doesn't scale well with multiple team members. Each person has to have their own version of secrets
- it's only available for local development. When moving into production, you'll need a different way to access these secrets - so you may as well use Azure Key Vault :)
But there is one important benefit: no secrets in config files!
How to configure the User Secrets feature
This feature is not enabled by default so there are a few steps required in order to set it up. First, let's create a sample .NET Core project
dotnet new console -n <Choose a usefule Name>
Then add the necessary NuGet packages
cd <Your Project Name>
dotnet add package "Microsoft.Extensions.Configuration"
dotnet add package "Microsoft.Extensions.Configuration.UserSecrets"
Before adding secrets, we need to initialize the secret store (file) with this command: dotnet user-secrets init
Now we can add or remove a secret with the dotnet user-secrets command:
Consuming User Secrets in the code
To access our application secrets, we can use the same ConfigurationBuilder() that is available to all .NET Core.
In Program.cs add the following code to load and access the user secrets via the IConfiguration interface:
Summary
This was a quick and temporary way to store and access user secrets in Console apps. I will remind you again that you should only use this tool sparingly and always prefer storing these secret in a remote and secure secret store like Azure Key Vault and/or App Configuration Service