An Overview of Users Vs Roles in AWS IAM

Today we’ll finally clarify IAM. Specifically when to use Users vs when to use Roles. This is a confusing topic for many people but with the visuals and examples I’ll share, you’ll realize it’s surprisingly simple.

Hi, I’m Dylan, a Cloud Engineer living in Oregon. So you’re using AWS for the first time, or 50th, and you want your friend to help you write and deploy a Lambda function.

• How do you give them temporary access to your AWS resources?
• How do you make sure no one else accesses your resources and runs up a huge bill?
• Do you make them a user?
• Do they just need a role?
• Maybe both?
• What’s the difference? 

Don’t worry, you’ll know the answer by the end of this video. We’re going to explain the 4 parts of IAM then get into the confusing part of when to use users vs roles.

AWS Resources are Locked By Default 🔐

By default, all resources in AWS are locked. You have to specifically give permissions to the resource to get it to work. The reason for this is security. And follows the widely accepted principle of least privilege.

The Principle of Least Privilege states that “A subject should be given only those privileges needed for it to complete its task. If a subject does not need an access right, the subject should not have that right.”

What is IAM? 🤷🏻‍♂️

IAM is the AWS service that tracks privilege every time an AWS resource gets used. For example, if you want to create an EC2 instance, AWS checks who you are and your privileges to see if you can.

In order to make sure you can create that EC2 instance IAM needs to know at least two things, who you are, and what you’re allowed to do. Wait, Dylan, there are 4 parts to IAM, Users, Groups, Roles, and Policies. How can you only need two?

IAM Has Four Parts 4️⃣

IAM’s four parts can be split up into those two categories. Users, Roles, and Groups tell IAM who or what you are, and Policies define what you can do.

Now to make sense of the confusing part; who has access, and specifically when to use users vs roles. 

There is one caveat I will say in a minute but to start, let me make it really easy.

Users are for people, and roles are for AWS resources.

Let’s go through some examples. A Lambda function needs to access Dynamo DB. The Lambda function needs a Role because it’s an AWS resource. And a policy attached to the role that allows access to Dynamo DB.

A developer in your company needs to spin up an EC2. The developer just needs to have a user account because they are a person. Note, if you are logged into the AWS console, you are currently an IAM User. And a policy attached to allow creating EC2 instances. Side note, users are what you log in as using a name and password when you sign into the AWS console.

Now You Try 👊

An administrator in your company needs access to all AWS resources. Do they need a user or a role? Because they’re a person, that’s right a user. What kind of policy needs to be attached? Yep, an all-access policy.

Those are the basics, and you can get far with them. As I mentioned there is one caveat. Users can assume a temporary role. 

Let’s update how this applies to AWS resources and people.

To clarify, roles can be assumed by both AWS resources and Users. While Users can only be assumed by people. 

AWS made this functionality because sometimes we need to give people temporary permission to certain resources.

 A user assuming a role is like letting a plumber into your house to fix a pipe. They normally can’t just walk into your house, but you give them temporary permission to get a job done. Then when they fix your pipe, they are no longer allowed in your house. 

For example, you want to give a developer who only has access to S3 and Lambda temporary access to EC2 to help out on a project. You would give the user a role with a policy attached that allows access to EC2. The user needs to accept and assume the role. Then once the project is done you can then revoke access to the role and they can no longer use EC2.

Flow Chart 📊

Here’s a flow chart to decide whether you want a user or a role: 

Once you decide whether you need a user or role, you attach the policy to it and you’re set.

Groups

Lastly, Groups are just collections of users. This makes it so you only have to attach a policy to the group once instead of doing it again and again for multiple users that need the same permissions. 

For instance, a developer group for all your developers would have a policy attached for EC2, Lambda, and S3. 

Now that you have it let’s come back to our question in the beginning. You want your friend to help you write and deploy a Lambda function. How do you use IAM to give them temporary access to your AWS resources?

I want you to think about it so I’m not going to answer it. If you think you have it, write your answer in the comments. If you’re not sure, still write your answer in the comments, the best way to learn is to try and fail. 

Conclusion

I hope that now you have a conceptual understanding of IAM and peace of mind knowing your applications are well architected. Please let me know if there are further parts of IAM you want to be addressed in the comments.

If you want to learn more about technology that enables business, start right now by subscribing and clicking the bell, so we can learn together! 

Have a great day, we’ll see you next time!

~ Dylan Albertazzi 🚀