

Amazon AWS vs GitHub – “Suspected Unauthorized Activity” - arijitraja
http://pivotedreality.wordpress.com/2014/04/11/amazon-aws-vs-github-suspected-unauthorized-activity/

======
codegeek
"When we moved our Github repository from private to public (as the co-founder
was leaving and I had to share it with some other prospective co-founders),
the AWS keys were all in the open for everyone under the sky to play with.
Doing some online search, I figured out we were not the only ones. It’s
apparently quite a common mistake developers do."

Yes, Yes and Yes. I have made a similar mistake once on Github for a personal
project, I realized my mistake and immediately updated the file and did a new
commit. Guess what ? Even after committing a new version of the file, you can
always check the "History" of the file which will show you the version with
the credentials. My only option was to delete that config file completely.

Having said this, it can be scary if you leave your credentials on sites like
Github. I work a lot with Python Flask framework and oen of the commonly used
extension is Flask-Mail to send emails. Guess what ? A lot of developers are
leaving their email credentials in the open and being a flask dev, I know that
most of the time, it is MAIL_PASSWORD variable usually in a config file.
Knowing this, I can just do a code search on github with keyword
MAIL_PASSWORD. You figure out the rest.

~~~
vertex-four
Even after deleting the file, you can still find it in git's history, it's
just very slightly less easily accessible through github's web interface. The
whole point of git is that nothing ever actually gets deleted.

You need to do a reset of any credentials that end up in public, ever.

------
res0nat0r
Another reason to always always always setup AWS billing alerts:
[https://aws.amazon.com/about-aws/whats-
new/2012/05/10/announ...](https://aws.amazon.com/about-aws/whats-
new/2012/05/10/announcing-aws-billing-alerts/)

This can POST to a URL, SMS you, email you etc. Set a $ threshold you are
comfortable with and enable this right away.

~~~
arijitraja
Absolutely, spot on. This is the best way to avoid this situation. Thanks, I
will put this in the blog somewhere.

------
tedchs
The best practice with AWS API keys is to ONLY EVER use IAM (Identity and
Access Management). There is nowadays zero reason to even generate account-
level API keys. With IAM, you can create separate keys with separate
abilities, down to the API call, even locked down to certain IP addresses.
Even on my personal account I have separate IAM "users", e.g. one for each S3
bucket that I use for backups, locked down to the minimum access needed for
the backup software to work.

------
mathattack
I've heard the billing alerts elsewhere.

Seems like AWS did a great job of making things right in the end.

