Secrets Management in different Environments

[DanielHabenicht]

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.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[danmoseley]

Cc @blowdart

[baronfel]

Short-term workaround here would be to lean on the launch-profiles mechanism to specify the different values you want for the ASPNETCORE_ENVIRONMENT environment variable. Then you can use environment-specific appsettings.json files to capture these differences.

I do personally really like .env as a convention - it's pretty ubiquitous in other ecosystems :+1:

[blowdart]

env files worry me a lot

When we went with development secrets we specifically did it that way so no-one would ever check secrets into source control. env files seem like a huge step back because guess what's going to happen? People will check them into source control. With folks like github, gitlab and azdo all checking for credentials in checkins env files will create a lot of noise, and for some environments the secrets will get revoked once detected, making the env file useless.

The same applies to a secrets.json file, it would have to be in source control to be useful, and then it's a security problem.

[DanielHabenicht]

Short-term workaround here would be to lean on the launch-profiles mechanism to specify the different values you want for the ASPNETCORE_ENVIRONMENT environment variable. Then you can use environment-specific appsettings.json files to capture these differences.

Although launchSettings.json are expected to be checked in, so its definitely not a great place to store credentials. Ahh, I think I misunderstood. You meant defining a appsettings.SecretDevelopment.json (excluding it from git) and referencing it in the launchSettings.json?

[DanielHabenicht]

env files worry me a lot

When we went with development secrets we specifically did it that way so no-one would ever check secrets into source control. env files seem like a huge step back because guess what's going to happen? People will check them into source control. With folks like github, gitlab and azdo all checking for credentials in checkins env files will create a lot of noise, and for some environments the secrets will get revoked once detected, making the env file useless.

The same applies to a secrets.json file, it would have to be in source control to be useful, and then it's a security problem.

I can relate, but storing it outside of the root folder makes it basically invisible for any developer and harder to change as one has to open the file in an extra editor. At least .env files are understood as not to be checked in virtually everywhere.

In my team I had a hard time enforcing the secrets management (for less important ones, e.g. test environments), because it was way more complicated than just committing them to the (internal) repository. Writing them into a file and git-ignoring it like we do in many other projects definitely lowers the entry barrier for keeping secrets separate. I am really open to any solution here. My main point is just that there is no way to define different secrets for different environments.

[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 :)

[DanielHabenicht]

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.

I've already looked up the default dotnet new gitignore and it's not included so there would be definitely some work to do before.

[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.