DEV Community

Ghassan Karwchan
Ghassan Karwchan

Posted on

Using Secret Manager for Configuration in .NET

It is critical not to store passwords or API keys in our code.

For all environments for the development process: (QA, UAT, Pre-Production, and Production), it is easier to place it in a safe place (Azure Key Vault for example), and access it during deployment.

For developer machines, we can use Secret Manager, or sometimes called User Secrets, which has a built-in support in ASP.NET.

 

Enable Secret Storage:

In the project you want to add a secret run this command:

dotnet user-secrets init
Enter fullscreen mode Exit fullscreen mode

This will generate a secret file, which is a json file called secrets.json, in a folder with a GUID generated name.

The location of the folder is

Operating System Location
Windows %APPDATA%\Microsoft\UserSecrets<user_secrets_id>\secrets.json
Linux/MacOS ~/.microsoft/usersecrets//secrets.json

And that generated GUID will be added to the project file .csproj as follows

<UserSecretsId>d87e6676-57eb-45c8-98d4-c6a3be58debb</UserSecretsId>
Enter fullscreen mode Exit fullscreen mode

 

Add a key secret

Let's supposed we want to add a key-api for google-map, where the appsettings.json file the entry will look like:

  "googleMapApi" : {
    "apiKey": "Enter anything here",
    "apiUrl": "https://maps.googleapis.com/maps/api/json?"
  }
Enter fullscreen mode Exit fullscreen mode

To add that, we run the following command line

dotnet user-secrets set "googleMapApi:apiKey" "<real key goes here>"
Enter fullscreen mode Exit fullscreen mode

Access a secret in ASP.NET

For ASP.NET application, the WebApplicationBuilder add most of the configuration providers that are used by developers like environment variable provider, appsetting provider, command-line provider, and last but not least the user secret provider.

So, in ASP.NET you access it as any other configuration setting using IConfiguration injected by DI:


// pass this to the constructor to be injected by DI
private readonly IConfiguration _configuration;
// and then inside the controller

var key  = _configuration["googleMapApi:apiKey"]
// or the following:

var key = _configuration.GetSection("googleMapApi")["apiKey"];

Enter fullscreen mode Exit fullscreen mode

 

Access a secret in console application

.NET console application don't provide built-in capability to read the user secrets or even any configuration provider, and we have to add that ability by adding the respective packages.

Add the following packages for a console app:

dotnet add package Microsoft.Extensions.Configuration
dotnet add package Microsoft.Extentions.Configuration.Json
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
Enter fullscreen mode Exit fullscreen mode

and then add the following code

var configBuilder = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json", false, true)
    .AddUserSecrets(Assembly.GetExecutingAssembly(), true); 
var config = configBuilder.Build();   

// then access it as follows
var key = config["googleMapApi:apiKey"];
Enter fullscreen mode Exit fullscreen mode

And then you can access it as you access in ASP.NET

Top comments (6)

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

Question: What happens when the repository is cloned by another developer? The secret folder is certainly not in source control, but the project file is. Therefore, the secret GUID is in source control. Now we have a new developer with the project but no secret folder.

Is there a way, by using the dotnet CLI, to create the secret folder?

Collapse
 
inzagio profile image
Trym

When a developer clones the repo and runs it for the first time, the secrets folder is created by dotnet. The developer which newly clones the repo would of course not have said secret, but let’s say this was a connectionstring for a local db, he would be able to store his own config secretly. The guid in the project file merely states for dotnet that someone has already initialized secrets for this project. So checking this into source control poses no issue or danger

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

I see. So running it creates the folder. So, for a fresh download of a branch:

  1. Compile and run.
  2. Run dotnet user-secrets set "<hierarchical key>" "<value>" for each secret.

It is at this point that the project is configured for debugging/development.

Got it. Thanks!

Collapse
 
jochii12 profile image
GrandJochii

Hello, i have also a question, i've been this in my mind for a long time, when we publish the application and deploy to the cloud, how can we set the secret to cloud ?

Thank you.

Collapse
 
inzagio profile image
Trym

This feature is a developer only feature. For production usage you could perhaps look into something like azure key vault or other cloud based secrets storage services.

Collapse
 
gkarwchan profile image
Ghassan Karwchan

Thanks @inzagio
You are awesome answering the questions.
Much appreciate it