Chris Farris

When AWS announced Lambda at the 2014 re:Invent, my immediate thought was “Cool, you can now program the cloud itself”. Since then, everyone has jumped on the “serverless” bandwagon for building apps. After this year’s re:Invent I’m inspired to get back to using Lambda to program the cloud.

One of the sessions I attended was on Security Automation. I’ll have more to say on that later. However, it gave me the idea for a setup that would require users to have MFA enabled, or otherwise be blocked from doing anything with their IAM User in the AWS account.

AWS API Keys are powerful things that you don’t want to leave lying around. Amazon’s suggestion is to keep them in ~/.aws/config. I’m not a fan of that. OSX has KeyChain, which is a secure repository for credentials and what most OSX Apps use for caching your login to various websites. This might not be the ideal solution, but it’s better than an unencrypted file in your home directory.

I’ve built a set of three scripts that will use OSX Keychain to store your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, and retrieve them into environment variables when needed to use the AWS API or any script that honors those environment variables.

We’re getting ready to deploy our first production workload in AWS, and our AWS account team recommended we enable a bunch of auditing on our accounts in each region. That is a lot of clicking for 9 regions across three accounts. This script will configure AWS CloudTrail and AWS Config Service in all regions, configure the logging bucket, and establish a reasonable password policy. Amazon is about to release 3 (or four) more regions in Ohio, England, Korea and India.