I was flipping through the aws news recently and ran into this article by Juan Ramallo – I was billed 14k on AWS!
Scary stuff!
Join 38,000 others and follow Sean Hull on twitter @hullsean.
When you see headlines like this, your first instinct as a CTO is probably, “Am I at risk?” And then “What are the chances of this happening to me?”
Truth can be stranger than fiction. Our efforts as devops should be towards mitigating risk, and reducing potential for these kinds of things to happen.
1. Use aws instance profiles instead
Those credentials that aws provides, are great for enabling the awscli. That’s because you control your desktop tightly. Don’t you?
But passing them around in your application code is prone to trouble. Eventually they’ll end up in a git repo. Not good!
The solution is applying aws IAM permissions at the instance level. That’s right, you can grant an instance permissions to read or write an s3 bucket, describe instances, create & write to dynamodb, or anything else in aws. The entire cloud is api configurable. You create a custom policy for your instance, and attach it to a named instance profile.
When you spinup your EC2 instance, or later modify it, you attach that instance profile, and voila! The instance has those permissions! No messy credentials required!
Related: Is Amazon too big to fail?
2. Enable 2 factor authentication
If you haven’t already, you should force 2 factor authentication on all of your IAM users. It’s an extra step, but well well worth it. Here’s how to set it up
Mobile phones support all sorts of 2FA apps now, from Duo, to Authenticator, and many more.
Related: Is AWS too complex for small dev teams?
3. blah blah
Encourage developers to use tools like Pivotal’s Credentials Scan.
Hey, while you’re at it, why not add a post commit hook to your code repo in git. Have it run the credentials scan each time code is committed. And when it finds trouble, it should email out the whole team.
This will get everybody on board quick!
Related: Are we fast approaching cloud-mageddon?
4. Scan your S3 Buckets
Open S3 buckets can be a real disaster, offering up your private assets & business data to the world. What to do about it?
Scan your S3 buckets regularly.
Also you can tie in this scanning process to a monitoring alert. That way as soon as an errant bucket is found, you’re notified of the problem. Better safe than sorry!
Related: Which tech do startups use most?