5 ms·
I don't get this logic, that's what .gitignore is for. I've been using .env files for years and never mistakenly checked one into a repo.
by dvt 5y ago
I don't get this logic, that's what .gitignore is for. I've been using .env files for years and never mistakenly checked one into a repo.
- kristjansson 5y agoIt’s not just to protect secrets, it’s better architecture. Rely on an ACCESS_ID/SECRET_KEY pair and it’s easy to bind too tightly to that authentication mechanism. Then providing credentials in production is a pain. Use the standard credential provider chain and the transition to production settings is trivial.
- dboreham 5y agoStill a bad idea though.
- kodah 5y agoidk what to tell you. I work on a security team, one of the tools the team built finds and identifies secrets already checked into VCS or ones at the pre-commit stage. It's certainly not a seldomly used tool.
- mdaniel 5y agoI believe GP's comment is at the intersection of "the chain is only as strong as its weakest link" and "defenders have to be correct every time, attackers just once"
- fwip 5y agoDefense in depth. It only takes one person on your team accidentally committing one file for one service before your .gitignore safeguard is no longer guarding anything.
- mountainriver 5y agoThis happens literally all the time in large organizations. People make mistakes
- bottled_poe 5y agoAnd should be easily caught in code reviews and CI jobs?
- viraptor 5y agoSure, and it will be caught by CI (if you set it up (properly)) and code review (if it happens (and nobody misses it (and no commits are pushed as a cleanup after (...)))). So basically if everything works perfectly, you won't have that problem. We know processes don't work perfectly, so it's better to avoid that issue in the first place by never leaving the literal tokens in the config. Also, even if your CI catches the problem, it's too late - your credentials are now in the repo and in the CI system and likely in your log collector attached to the CI. You'll need to roll them. Same with reviews.
- d4mi3n 5y agoEver try cleaning Git commit history? How about having GitHub clear a repository cache containing a secret? You’re not wrong, but this is a whole class of issue that can be avoided for trivial levels of effort.
- dotancohen 5y agoWhich occur after the code is in git and pushed.
- bottled_poe 5y agoSo change the secrets and/or find professional developers? Sorry, not sorry, it’s an amateur mistake, not acceptable in a professional environment. Why would an amateur possess the secrets in the first place?
- dotancohen 5y agoI prefer a security model slightly more robust than "None of the professionals working on this project will ever make a mistake".
- belthesar 5y agoTell that to Solarwinds.
- sverhagen 5y agoEven if you want your credentials in SOME file, you don't want them in THAT file. Because that configuration file contains enough valuable configuration that SHOULD be in Git, in which case the credentials would be in the way.