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