Open DanielHabenicht opened 1 year ago
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.
Cc @blowdart
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:
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.
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
Ahh, I think I misunderstood. You meant defining a appsettings.SecretDevelopment.json (excluding it from git) and referencing it in the launchSettings.json?launchSettings.json
are expected to be checked in, so its definitely not a great place to store credentials.
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.
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 :)
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.
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.
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:
dotnet user-secrets list
, but one has to remember this command instead of visually seeing the.env
file in the repository`).env
files this)Describe the solution you'd like
There are multiple ways to relief some development pain:
Allowing another flag for the current cli: (Apart from the
--configuration
), e.g.--environment
Basically this would be the equivalent to the differentappsettings.json
files. If the application would readappsettings.Development.json
it would also readsecrets.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.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:launchSettings.json
support: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.