security developer

Sharing "developer" secrets

Committing secrets to source control is a real problem for developers and I like many others have done it at least once.

Shaun Wilde
a group of children whispering to each other

Committing secrets to source control is a real problem for developers and I, like many others, have done it at least once. When it happens, the team then has to go through the awful process of updating the affected secrets and, if required, removing those secrets from source control as well (assuming they got pushed to a central location.)

Sometime ago, I came across a feature in .net core that allows you to store secrets in a json file that is part of you user profile and can be loaded by your application. By default it uses a new location for every application but with a little tinkering you can use the same location for several applications. The magic works due to the ability to "layer" configuration from multiple sources when using ConfigurationBuilder

var builder = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddUserSecrets<Program>()
.AddEnvironmentVariables();

and then applying the UserSecretsIdAttribute that you can either set as an assembly attribute

[assembly:UserSecretsId("8d49e500-1a72-4596-bdfa-e56080b10b5f")]

or you can set it directly in the project file, which is more common for .net core projects.

  <PropertyGroup>
<UserSecretsId>8d49e500-1a72-4596-bdfa-e56080b10b5f</UserSecretsId>
  </PropertyGroup>

Once this is set in the project you can then access the secrets.json file from the location in the user profile and start overriding your configuration and not worry about the secrets being committed to source control.

e.g. if in your config you wanted to override a specific field

{
  "object": {
"key": ""
  }
}

then you can override this in the secrets.json like so, take note of the flattening of the json object that happens

{
  "object:key": "secret-data-here"
}

The by using the same identifier, usually a GUID, across multiple "application" projects will allow you to have a shared set of secrets for those applications. Of course you may prefer to use environment variables or even pull the secrets from a secure location e.g. Azure KeyVault, but it is nice to have options.

Like most of my posts these entries are more notes for my future self but from which others may benefit. Your feedback is appreciated.