Hacker News Reader

Comment by d2xdy2 | Hacker News Reader

> As a senior developer with over 12 years of experience in the financial services industry, I didn't think it was possible that I could be the victim of a data breach.

Ok...

> Better yet, move access keys to a seperate config file, and exclude this from Git deploys with a .gitignore.

No shit?

View on HN

Even that's a terrible solution. AWS specifically changed their tooling to look for access keys in ~/.aws and make it more difficult to load them from inside a project directory. It's really not that hard to setup MFA and require it when using STS to assume whatever role you need to make changes. For automated changes, you can give instances the necessary an IAM role and only run those from inside EC2.

He didn't get a $6.5k bill because of a bug in VisualStudio, he got one because he didn't finish setting up his AWS account. Regardless of the public/private mixup, checking in AWS credentials to any repository is just bad practice and creates a huge risk of the exact situation that happened in this story.

Albeit not on AWS, I typically just set environment vars to reflect configs I would have set in a .env (or .local.env, or .testing.env), or have some sort of config manager daemon type thing running that keeps that sort of stuff locked away.

> He didn't get a $6.5k bill because of a bug in VisualStudio, he got one because he didn't finish setting up his AWS account. Regardless of the public/private mixup, checking in AWS credentials to any repository is just bad practice and creates a huge risk of the exact situation that happened in this story.

I agree

Reply on news.ycombinator.com