What are IAM Roles?

A quick note about IAM Users…

In my experience, most people tend to have an easy time grasping what an IAM User is. It’s an identity in AWS that represents you or other people who need to manage resources in an AWS account. Users can have a username and password with a login link to the AWS console, and/or they can have access keys to issue commands via their terminal or via scripts.

Passwords and access keys are known as “long-term credentials” because they never expire unless you either manually change them, or force changes with password and access key rotation policies. Even then, they typically live for at least a few days to weeks, months, or even years.

I mention that because this is a key problem with users and a key difference between users and roles.

IAM Roles are completely different

IAM Roles are similar to users in the sense that you can give permissions to roles by assigning them policies, but that’s pretty much where the similarity ends.

Difference #1

Users can have long-term credentials (passwords and access keys) but roles cannot have usernames and passwords, and while they technically use access keys, they use access keys with session tokens that expire after a set amount of time. This is referred to as “temporary credentials” in AWS, and I’ll also use the term “short-term credentials” to mean the same thing.

To recap:

• An IAM User can make API requests to an AWS service using a pair of just an aws_access_key_id and an aws_secret_access_key
• With IAM Roles, instead, we need to issue API requests using aws_access_key_id, an aws_secret_access_key, and an aws_session_token

The default session token duration is 12 hours, but you can configure them to last anywhere from 15 minutes to 36 hours.

That way, even if an attacker somehow snatches those credentials, they will eventually expire instead of remaining permanently available.

Difference #2

Another key difference is that roles can be assumed by users or by other services to do their jobs. For example, if you are part of the incident response team and there’s an incident in one of your AWS accounts, you could assume the SecurityAnalystRole to perform analysis, and that role would only have access to services like Amazon CloudTrail and Amazon Athena.

Whenever you assume that analyst role, you renounce whatever permissions your prior user has while you’re assuming that role, but you can switch back to your prior permissions at any time or whenever your temporary credentials expire (unless you renew them).

Or as another non-user example, if you’ve got an EC2 instance with a web application on it that needs to access data in Amazon S3, you would give that instance a role with permissions to access S3 and it would use that role to get access whenever it needs it through temporary credentials — all automatically.

Roles are hats you can wear for different jobs

You can think of roles as hats that you can wear to give yourself (a user) or AWS resources different permissions whenever they are needed…assuming that the user or service has permissions to assume the role in the first place.

This gives you multiple benefits:

• Using roles designed for specific tasks makes it significantly easier to achieve least privilege
• Least privilege is important for multiple security reasons including:
  • Preventing accidental deletions/modifications
  • Making it much harder for attackers who somehow gain access to do damage since they will need to figure out how to escalate privileges
• Roles also provide a clear audit trail, and I’ll expand on that below
• Roles can be used for cross-account access, which means that if your organization is running multiple AWS accounts (a common practice even for smaller businesses), users can assume roles for day-to-day tasks (again following least privilege) and this is known as delegation

Going back to this for a minute: “roles also provide a clear audit trail.”

We mentioned using a SecurityAnalystRole to analyze an incident. By having one of your employees (a user) assume that role to perform the analysis; even if they then switch to a SecurityBreakGlassRole to perform containment and eradication measures, we can have a much easier time tracing back what actions were taken when and by who since the actions will be logged separately for both roles. We can more easily trace every step taken while assuming the analyst role, and then every step taken while assuming the break glass role.

Conclusion

Hopefully this shed some light on what IAM Roles are and what their purpose is, and also how they differ from IAM Users. If it didn’t, though, check out the next lesson where I provide an analogy.