Secrets Management in different Environments

Is your feature request related to a problem? Please describe.

Secrets management in Development environments is unfulfilling. The Basic configuration is helpful, but is not user friendly when handling multiple environments and bigger teams, as it lacks:

• Quickly switching between different secrets for different environments
• finding currently configured secrets (of course there is dotnet user-secrets list, but one has to remember this command instead of visually seeing the .env file in the repository`)
• misalignment with “industry standards” (if you could call .env files this)
• Easy sharing of secrets between developers (where was the file again to quickly share with my coworker?)

Describe the solution you’d like

There are multiple ways to relief some development pain:

1. Allowing another flag for the current cli: (Apart from the --configuration), e.g. --environment Basically this would be the equivalent to the different appsettings.json files. If the application would read appsettings.Development.json it would also read secrets.Development.json and the CLI options would write to the respective file. This would allow to easily switch between “Staging” and “Development” Secrets (basically allowing each launch Profile to potentially have different Secrets). Please note that the current --configuration implementation does not allow this, as I might want to Debug with the secrets from the Staging Environment or test the Release build with the local Development Secrets.

2. Make the dotnet eco system understand .env files. Instead of writing extra documentation about how to handle secrets with the dotnet project or searching the internet for this guide .env files could be used as they are a defacto standard known to many development tools. Some ideas on how to add them:

   • Add launchSettings.json support:

   {
    "profiles": {
      "EnvironmentsSample": {
        "commandName": "Project",
        "dotnetRunMessages": true,
        "launchBrowser": true,
        "applicationUrl": "https://localhost:7152;http://localhost:5105",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
        },
       // Add another Option for reading .env Files
       "environmentFiles": [".env", "development.env"]
      },
   }
   

   • Add dotnet cli support: For --configuration=Development the .env file could be loaded automatically. For manually adding it with other configurations adding the option --env-file .env would be great.

Additional context

As a workaround one could use a nuget package such as DotNetEnv but this would add unneeded complexity and packages to the build + functionality which would only be called during Development or anytime adding side effects to Release Builds.

[baronfel]

Made a quick update to the gitignore template as a PR to at least give us some coverage if we do decide to do things with dotenv in the future. Several other ecosystems’ gitignore files in the github/gitignore repo already have this, so we’re playing catchup from a safety perspective here.

[blowdart]

At least .env files are understood as not to be checked in virtually everywhere.

For those people that know and understand them 😃

It’s worth evaluating for 8 though, but we’d have to make sure VS’s default gitignore does indeed ignore .env, and also look at what github and azdo do, just in case it does get checked in with secrets.

But I leave that to feature PMs, I’ve gone my spoilsport security rant now 😃