Understand IAM Roles
Learning Objectives
After completing this unit, you will be able to:
- Explain the use and features of IAM roles.
- Describe the difference between IAM roles and IAM users.
In AWS, a user can be a person or a machine such as an AWS service or application. Consider the scenario where you have a cat photo application running on an AWS compute service that needs to access an AWS storage service. Your cat photo application won’t have authentication or authorization to do so by default, so you need to provide the credentials needed to access this storage service.
You learned in the previous unit that you can create an IAM user for your application and hardcode the user’s access keys into your application to provide authentication. However, this creates a few security vulnerabilities.
- These keys can be forgotten and not rotated (good security involves changing passwords occasionally).
- These keys can be detected and exploited by hackers or other malicious actors. If a bad actor exploits your application and takes these access keys, they can access your AWS account and resources.
So if you shouldn’t pass in or hardcode access keys into your application, how can you provide security credentials to your app? To do this, you can use IAM roles to provide temporary security credentials.
What Is an IAM Role?
Unlike IAM users, IAM roles provide temporary credentials and aren’t associated with a specific person or thing. Instead, trusted entities like IAM users, applications, or AWS services assume roles. Assuming a role means obtaining a set of temporary credentials that are associated with the role.
What’s the Difference Between an IAM User and an IAM Role?
IAM users and IAM roles are similar in that they are both IAM identities used to give access to AWS services. However, there are differences. For example:
- Instead of being uniquely associated with one person like a user, a role can be assumed by anyone who needs it.
- A role doesn’t have standard long-term credentials, such as a password or access keys, associated with it. Instead, when you assume a role, it provides you with temporary security credentials (access keys) for a configurable period of time.
- You define when roles expire, between 15 minutes and 36 hours, so that keys are rotated more frequently.
Assume IAM Roles
There are several scenarios where you’d want to use a role over an IAM user. In this unit, we’ve already talked about one of these scenarios, your cat photo application, hosted on an AWS compute service, and assuming a role and receiving temporary security credentials to access an AWS storage service.
Another common scenario is a user assuming a role in the same account to take on different permissions for a task. For example, let’s look at three users working on your cat photo application: a developer, an admin, and a security engineer. Your security engineer goes on vacation for a week and there’s no one to fill in for him. Your developer, John, decides to step up and take on his job for the week. You have a few options to grant him security engineer permissions.
Option 1: You can add Security permissions directly to the developers group.
However, all the developers in that group get these Security permissions.
Option 2: You can add Security permissions directly to the user itself.
However, you’re defeating the purpose of having John in a group and lose organization and scalability.
Option 3: You can create a new user for the developers group that inherits the permissions of the security group.
This becomes an issue because John now has two sets of user names and passwords and potentially two sets of access keys to maintain: his developers user credentials and his new security user credentials.
Option 4: You can create a role. When the developer needs to perform the work of a security engineer, the developer can assume the security role, do the work needed, and then switch back to their developer user when finished.
Option 4 is the correct option to choose. It prevents the developer from having to manage multiple sets of credentials, maintains the scalability and organization of your users, and does not give permissions to others who don’t need them.
A user can assume a role temporarily using the AWS Management Console. The users then give up their original permissions and assume the permissions assigned to the role. When the user exits the role, they only have access to resources defined by their original user permissions.
There are two more use cases for roles.
- Cross-account access: If you own multiple AWS accounts, you may run into the scenario where users in one account need to access a resource in a second AWS account. To grant access to resources in the second AWS account, you should use roles to provide those users access.
- Federation: Your users might already have identities outside of AWS, such as in your corporate directory. If those users need to work with AWS resources (or work with apps that access those resources), those users also need AWS security credentials. Identities that are federated from your corporate directory (or another identity provider) can use an IAM role to access the AWS Management Console.
Wrap Up
IAM roles provide temporary credentials to your applications, IAM users, and AWS services. They enable you to maintain least privilege with access control and ease the burden of key rotation. In the next unit, you learn how to authorize your IAM identities and grant permissions to IAM users, groups, and roles.