Author Edit: This approach is wildly outdated now, you should use IAM Identity Center instead.
Understanding IAM security models is one of the most important aspects of effectively and safely managing AWS environments. Throughout my work consulting with various companies, I have noticed a trend that many organizations are managing the cloud in similar fashion to how they managed on-premise environments. The purpose of this post is to review some strategies to manage identities for people in AWS and the target audience for this post are users that might be newer to AWS IAM security principles.
AWS IAM Basics
When we talk about IAM, it's important to note the differences between Users, Roles, Policies and Groups
Users: Users allow you to create identities for users. Users can can be added to groups with policies attached to the group, or have policies attached to them to add permissions. Users can have two types of credentials, Console credentials to access the web console, and Access Keys which are used for programmatic access using the AWS CLI or SDK.
Groups: Groups allow you to assign policies to the group, and then add users to the group to simplify credential management. Only 10 managed policies can be added to an individual group, but you may also add inline policies that are defined within the group.
Roles: Roles are used for a few things within AWS, but this boils down primarily to allowing users to assume role into your account, including users from other AWS accounts, as well as allowing AWS services to access resources within your account.
Policies: Policies are JSON documents that define the permissions that the attached identity (user, group) has access to. You can use conditionals, variables and wildcards in these policies documents to control access based on a variety of factors, such as MFA being used to log in or the AWS Region being used. Managed AWS policies exist for baseline access, but you can also add your own policies for more granular control.
Note that there are other aspects of IAM, such as Identity Providers, where you can connect to SAML or OpenID to set up single sign-on, and the IAM Access Analyzer, but those will be covered in a future post.
Securing IAM Access for Users
To set up a secure access to AWS, there are a few key things to consider:
All users should only have one IAM user.
Permissions should be assigned with the least privilege needed for the user.
Permissions should be assigned by groups, and not individually to users.
MFA should be enabled for all users
Access Keys and Passwords should be rotated on a regular basis.
Using temporary permissions by assuming roles is preferred.
Putting It All Together
To put this all together, let's take a practical example of setting up read access for a user.
First, we will create an administrative role for our user to assume in the console.
One thing to note when creating this role, is we have selected "Another AWS Account" but you can specify the account your user is in as well! One advantage of this approach is you can default to having your users have very little permissions, perhaps only access to IAM to complete basic tasks like setting up MFA, and the ability to assume roles. This is helpful, because if an account is compromised, the attacker will not be able to simply query the API to list your resources or make destructive changes. They would first need to know the role name to assume to have the appropriate level of access. This, admittedly, is a bit of "security through obscurity" but this can still be effective when utilized with other best practices.
Next, we give the role permissions. For this example, I'm giving the AWS managed policy "ReadOnlyAccess"
I'm not adding any tags for this example, but tags are a great way to identify ownership of resources.
Last, but not least, give the role a name, and note the role because you will need it to assume the role.
Now we need a policy document that allows us to assume the role in our (or another!) account.
Let's create a policy to allow access to assume role. Create a policy in the AWS console. If you use the visual editor, choose the STS service and select "AssumeRole" under "Write". Under resources, enter the account number and role name that you want your user to be able to assume. Remember, this can be the current account or another AWS account. You can also wildcard here, so if you use the same role name across all your accounts you can simply wildcard the account number to allow your user to assume that role across all your accounts.
You can also simply enter the JSON as follows. Make sure you change the account number to your account number!
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/ReadOnlyAccess"
}
]
}
Once you create the policy, attach it to a group, and make sure the users who need access are added to the group.
Assuming the Role
Last, to test this out, click on your IAM username in the header of the IAM console and click on "Switch Roles" - Enter the account number holding the role you will assume, and then the role name that you created earlier.
Once you click on Switch Role, if everything is working correctly your username at the top will show the role you are currently using.
To demonstrate the access as well, I'm logging in to the S3 console. Note that I can see my CloudFormation template bucket:
But I cannot create a new bucket, because I am assuming a role that only has read-only access:
### Wrapping Up So, now that we have a centralized method to manage identity in AWS for our users, important next step is to think about how to audit and manage ongoing usage. In a future post, I'll cover how to use Security Hub, AWS Config and the IAM Access Analyzer to create a strong program around managing identity for users.
Now that you're assuming roles to access permissions in your account(s) I also recommend the AWS Extend Switch Roles plugin for Chrome/Firefox. This helps store your role switch configuration, rather than relying on the Role History within the AWS Console by default.
Lastly, here is a JSON policy document to require logins with MFA for your IAM users to be able to access nearly all AWS resources:
https://gist.github.com/PatrickJD/7aca25836048bf871ea72253c8531854
