AWS IAM: The Basics

AWS IAM is how you control who can do what. It’s not exciting, but getting it wrong means someone deletes your production database.

The Four Things

• Users: People or services that need access. Give them access keys for programmatic access, passwords for console access.
• Groups: Collections of users. Put your developers in a Developers group, attach permissions once.
• Roles: Temporary permissions. A Lambda function assumes a role. An EC2 instance assumes a role. No long-term credentials stored anywhere.
• Policies: JSON documents that say what is allowed. Attach them to users, groups, or roles.

Creating a User (CLI)

aws iam create-user --user-name JohnDoe
aws iam create-access-key --user-name JohnDoe

Store the access key ID and secret. You won’t see the secret again.

Creating a Role for Lambda

aws iam create-role \
  --role-name LambdaExecutionRole \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name LambdaExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

The Rules I Follow

1. Least privilege: Start with no permissions, add only what’s needed.
2. No root access keys: The root account is for billing emergencies only.
3. Use roles for apps: Never put access keys in your application code.
4. Rotate keys: If a user leaks a key, rotate it. Better yet, use roles and don’t have long-term keys.
5. Enable MFA on the root account: Do this now if you haven’t.

IAM is tedious until it’s not. The day you catch a leaked key before it’s exploited, you’ll be glad you set this up properly.