The email started with “Your AWS account is compromised”. That’s the kind of thing that makes you stop whatever you’re doing and sit bolt upright.
Amazon Web Services emailed me because one of my secret account keys had been posted to a publicly accessible web page – in this case, it was a github repository under my account. It seems that I had accidentally committed my AWS access keys to a git repository hosted on github.com.
Okay, admittedly it was my github repository … for this website.
The best part about this email is that the email from AWS contained a set of instructions that I should follow to resolve the situation. The first thing I needed to do, they said, was to make sure that I knew that these keys had been posted and to protect my account from being compromised.
Every option was carefully spelled out for me. My next steps were to change a password, check for unauthorized usage (new EC2 instances, new accounts, etc), and finally rotate out the key.
First off, I rotated out the keys. This was easy enough to do – just hit up the AWS console, disable the key, then delete the key, and finally generate a new key. With all of that done, I was ready to contemplate my next move.
I immediately made the repository private. I’d hoped to keep the code public, but I’m far too lazy to rebuild my
s3_website custom configuration in order to keep it safely under version control. This completed my damage control.
A better approach, though, would be to find ways to isolate my keys from configuration files and keep them as environment variables. My full
.profile is already under private version control, so I could easily add the environment variables in there. I could go one step further and remove security credentials from my
.profile and push them into a secure profile folder that’s used during environment initialization.
Needless to say, there are a lot of options available and I need to figure out the easiest way to accomplish these tasks before I start shell scripting my way out of these problems.