Roles vs. Users vs. Groups
If you feel like you have a good understanding of what IAM Roles are and how they’re different from IAM Users and Groups, then feel free to skip this lesson. I added it in as an extra explanation with an analogy in case it didn’t click with the prior lesson.
Let’s look at an analogy…
Think of a corporate building’s badge access control system.
When you become an employee, you are given a badge with your name and some other information. That badge is unique to you, and it gives you access to general parts of the building like the cafeteria and restrooms, and also more specific areas like your office, things like that. Think of this badge as an AWS user.
Let’s also say that you’re part of the IT team, and of course, your company also has a Finance team, an HR team, Marketing team, etc…each of those teams are groups of employees, or in AWS terms, groups of users. So think of those departments as groups.
Employees in the HR group will have very different access and permissions than employees in the IT team, and so groups in AWS help us assign permissions to multiple similar users all at once instead of requiring individual permissions for each and every user which would be a management nightmare.
But now let’s say that you, specifically, are one of only a few employees in the IT team that have access to a certain section of the data center. That section contains classified data related to military personnel, which requires that you have a certain type of clearance, and so most employees (even in the IT team) don’t have access to that section.
For security purposes, instead of granting your badge access to that section, you have to check in at a kiosk using your badge, and you have to make a log entry for the security guard to then hand you a temporary access pin to that restricted section. You need your badge (which in our scenario represents your credentials) in order to log that entry and receive your temporary access pin. Think of that temporary access pin as an IAM Role.
That role, or access pin, only grants you access to the restricted section for up to 1 hour, at which point the security guard would go find you and escort you out. If you need more time, you would have to renew your access and get a different temporary access pin to get another hour in that restricted area. This all leaves a paper trail that can later be audited.
Also, while you are in the restricted area, you are not allowed to bring in your badge, instead it stays with the security guard at the checkpoint, and the computer systems within that area will not let you authenticate into systems that you typically have access to. You temporarily give up the access you had as a user with your badge while you are assuming that role.
As soon as you exit and log out in the entry book, the security guard grants you your badge back, and you regain your prior user permissions, but lose the access you had with the role.
This is an analogy, so there are a couple of flaws with it and it’s not perfect, but the general idea works.
Now let’s reiterate this by switching out of the analogy and talking in technical terms to recap.
IAM Users are created through the IAM service and they are entities that give you an identity in your AWS account.
That user identity will have permissions either assigned directly to it, or through groups that we’ll talk about in a second.
You can give these users long-term credentials like a username and password, and they can use that password to log into the AWS console.
Or, you can give them long-term access keys which can be used to authenticate via the API or CLI.
Groups are used to group users together. This is great for keeping similar users together — so like for example if you have 5 developers on one team, you could create a
Developers group for them, and you could assign them all the same policies by applying one or more IAM policies to that single group. Then if one of the developers leaves the company or changes teams, you simply remove them from that group and they lose permissions.
Roles can be assumed by users or AWS services to get the access they need, when they need it, in order to do their jobs.
When you assume a role, you receive temporary credentials instead of long-term credentials, and you use those temporary credentials to authenticate via the API or CLI. If a threat actor comes across those credentials 5 days later, they won’t be able to use them since they would have already expired.
Roles can also be assumed & used via the AWS console, and we’ll take a look at all of these options in this course.
We’ll be looking at more examples of why roles are beneficial and a fantastic tool to use in AWS for many reasons, but hopefully this helped clear up questions you had about the main differences between roles, users, and groups.
If not, don’t worry, once we get to the hands-on portion of this course, I think it will make more sense.