6 ms·
Why?
by herpderperator 4y ago
Why?
- jensenbox 4y agoStatic tokens are terrible. They are far too easy to egress and are downright evil.
- alphabettsy 4y agoI presume so that one can use instance roles or automatic credential discovery that is common within AWS and using AWS applications.
- macksd 4y agoSome organizations use this feature to enforce security policy and ensure regular rotation of credentials. You can't get a static access key ID / secret access key pair, but you can get one with a session token, and so you run everything inside that context. If you can't specify the session token to an Amazon client, you just can't use Amazon STS.
- kodah 4y agoCredentials in a config file can be mistakenly checked into a repository. They're easy to exfiltrate from files, say I write a script with well known configuration locations for thousands of applications and just dumbly pull them all from a compromised system. I now have little bits of access to the wider system where I can now jump from system to system. The best way to store ephemeral secrets is in an environment variable or /dev/shm. This locks the secret behind the scope of the parent process (shell instance) and the user.
- osrec 4y agoHow do you automate setting that environment variable?
- toomuchtodo 4y agoInjection into the environment (container config, Docker, k8s, etc) or the execution context. The actual mechanics are highly dependent on where your secrets are and where they’re going for use. On a dev workstation, could just be some bash or Python using the AWS cli, for example.
- dboreham 4y agoFor a specific example of one way how : https://github.com/99designs/aws-vault https://github.com/99designs/aws-vault
- dvt 4y agoI 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 4y 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 4y agoStill a bad idea though.
- kodah 4y 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 4y 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 4y 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 4y agoThis happens literally all the time in large organizations. People make mistakes
- 4y ago
- Aeolun 4y agoOne big reason is it’s insecure. Another big reason is it’s much nicer to deploy on any AWS service and have the SDK use the metadata host, which will automatically provide you with a temporary access token with the permissions of the role you set for it.