I have been a software professional since I was in high school in 1998. I'm enthusiastic about open source, and I really enjoy working in unusual software systems or within strange constraints.
There's plenty wrong with using .env files, especially in production. Permissions could be wrong, it could expose passwords to folks who are authorized to support the application but are not authorized to access the database, it could be slurped, version-controlled, etc.
Just because it is easy to maintain security of a single file in a single filesystem doesn't mean that the .env files sitting on your laptops and production servers (if you're using containerization and clusters than it's one copy per machine).
Add on to that the fact that if you use .env files then you have to go manually change the files whenever you rotate or change tokens/keys/passwords, which frequently leads to people not changing those aforementioned credentials.
Use a security service which encrypts, like a Secret Manager (GCP, Azure, and AWS have these), you could use Hashicorp Vault, there are a bunch of choices.
Don't use .env files, the odds that your program will suffer a security event or will perpetuate bad security hygiene is substantially higher than if you use a vault or managed service for your secrets.
Do use .env files to define environment variables in local dev (which is what it is for). Don't commit .env files to your repo. github.com/motdotla/dotenv#should-... .env was never ever meant to define environment variables in production/hosted environments, its for local env ONLY.
I have been a software professional since I was in high school in 1998. I'm enthusiastic about open source, and I really enjoy working in unusual software systems or within strange constraints.
The passive aggression isn’t helpful. It is possible for us to have a respectful conversation while disagreeing.
IAM is an auditable, traceable mechanism which can be monitored and alerted on. I can see who makes an api call to fetch credentials in CloudTrail. I can see if my policy statements are too permissive with things like AWS Config, Trusted Advisor, or Access Analyzer. I can set and forget those roles, and make access to credentials something that adheres to least privilege.
I’d much rather risk a detectible fault IAM policy documents and roles than try to manage .env files across a bunch of infrastructure, and constantly monitor engineers who will accidentally commit and push credentials to source control.
If we were still in the days of monoliths on bare metal servers running in data centers, I wouldn’t be disagreeing as I am. But we’re not, at least not all of us are. The threat is much bigger than you seem to be giving it credit for. Using .env files for production workloads in contemporary containerized cloud deployments is clearly a security anti-pattern.
Lol I was just messing around. You're right though. There's definitely not a way to audit syscalls about file and attribute operations and send those to a SIEM and alert on them. And even if that existed it's not like it's best practice to monitor those things anyway. So yeah I'm in your camp on this one.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's plenty wrong with using
.envfiles, especially in production. Permissions could be wrong, it could expose passwords to folks who are authorized to support the application but are not authorized to access the database, it could be slurped, version-controlled, etc.Just because it is easy to maintain security of a single file in a single filesystem doesn't mean that the
.envfiles sitting on your laptops and production servers (if you're using containerization and clusters than it's one copy per machine).Add on to that the fact that if you use
.envfiles then you have to go manually change the files whenever you rotate or change tokens/keys/passwords, which frequently leads to people not changing those aforementioned credentials.Use a security service which encrypts, like a Secret Manager (GCP, Azure, and AWS have these), you could use Hashicorp Vault, there are a bunch of choices.
Don't use
.envfiles, the odds that your program will suffer a security event or will perpetuate bad security hygiene is substantially higher than if you use a vault or managed service for your secrets.Do use .env files to define environment variables in local dev (which is what it is for). Don't commit .env files to your repo. github.com/motdotla/dotenv#should-... .env was never ever meant to define environment variables in production/hosted environments, its for local env ONLY.
You make a great point because in AWS permissions can't be wrong. 0600 is really hard to get right, but IAM policy docs are super straightforward.
The passive aggression isn’t helpful. It is possible for us to have a respectful conversation while disagreeing.
IAM is an auditable, traceable mechanism which can be monitored and alerted on. I can see who makes an api call to fetch credentials in CloudTrail. I can see if my policy statements are too permissive with things like AWS Config, Trusted Advisor, or Access Analyzer. I can set and forget those roles, and make access to credentials something that adheres to least privilege.
I’d much rather risk a detectible fault IAM policy documents and roles than try to manage
.envfiles across a bunch of infrastructure, and constantly monitor engineers who will accidentally commit and push credentials to source control.If we were still in the days of monoliths on bare metal servers running in data centers, I wouldn’t be disagreeing as I am. But we’re not, at least not all of us are. The threat is much bigger than you seem to be giving it credit for. Using
.envfiles for production workloads in contemporary containerized cloud deployments is clearly a security anti-pattern.Lol I was just messing around. You're right though. There's definitely not a way to audit syscalls about file and attribute operations and send those to a SIEM and alert on them. And even if that existed it's not like it's best practice to monitor those things anyway. So yeah I'm in your camp on this one.