Make change to README file about dotnet-env HOT 7 CLOSED

So, I hear you on your callout. However, seeing as the purpose of this library is to use env vars, and I do not specifically call out secrets, I don't personally know what should be changed about this line. Do you have an alternative in mind?

from dotnet-env.

I would change that line for this one:

When the application is deployed in production, you should not store sensitive data such as passwords, API Key, JWT Secret, etc. in a static .env file, because that data is in plain text. Instead, you should use a secrets manager such as those provided by cloud services like AWS or any other.

from dotnet-env.

I would rather change it to simply add an extra blurb:

When the application is deployed into production, actual env vars should be used, not a static .env file! Also remember that secrets might be best accessed from a secrets manager or config service rather than env vars, to avoid exposing those secrets to other processes on the machine.

How would that work for you? @MrDave1999

from dotnet-env.

When the application is deployed into production, actual env vars should be used use not a static .env file! Also Remember that secrets might be best accessed from a secrets manager or config service rather than env vars, to avoid exposing those secrets to other processes on the machine.

I think it is no longer necessary to recommend the use of actual env vars.

What do you think? @rogusdev

from dotnet-env.

Plenty of apps can, do, and should use env vars in prod. This is still a well recommended best practice, such as:
https://12factor.net/config

I'm not inclined to make the changes you are suggesting. I would be willing to add the secrets sentence I suggested if that would suffice for you

from dotnet-env.

Using actual env vars is not bad, the problem is that env vars should not be used to store secret data, are we aware of that? I think so. That's why I tell you that using actual env vars is not a recommended practice for storing secrets.

The third principle of the 12-factor methodology does not mention at any time that env vars should be used to store secret data. In order not to complicate things and make this issue longer, just make the change you propose from the beginning.

After this paragraph:

When the application is deployed into production, actual env vars should be used, not a static .env file!

Add this:

For added security, use a secrets manager to keep sensitive data safe.

Done, all happy and prosperous Christmas :)

from dotnet-env.

I've thought about it, and I am not inclined to say anything about secrets. This is a library for .env files. What people put in env vars is outside the scope of this library. I just wanted to emphasize that a .env file and env vars should be kept separate between dev and prod, and I feel that is covered.

from dotnet-env.