Terminology#

Let's start by looking at some key AWS terminology.

Users#

Users in IAM represent an identity. They're also considered a Principle in IAM, which is important to remember, as I said earlier.

There are two types of users in a (standard) AWS account: the root user and IAM users. We've seen the root user already, because we used it to create a new IAM user and a billing alarm. Generally speaking, you secure the root account and then (likely) never use it again.

An IAM User can be used by a human or a computer. When we created our IAM User earlier on, we disabled API access because we wanted a normal (human) user that was able to login to the console and perform tasks. We didn't want a computer - running software - to be able to access our account and perform actions.

We create users with programmatic access, or API keys, when we want software to access our account for us and perform operations. This is very common, we'll explore this option later on.

Groups#

IAM Groups contain IAM Users. Groups are ideal for when you have organisational "boundaries" inside of your company. That is, you have networking engineers, database administrators, etc. and you want to group their AWS access to match their technical responsibilities.

When you create an IAM Group, you add permissions to it in the form of policies (inline or pre-extsing), and then every IAM User in the Group has those permissions applied to them.

Users can be placed into multiple groups.

Policies#

IAM Policies are sets of permissions that control access to AWS resources and the operations you can perform against them. You write policies as and when you need to give users, groups, or roles, access to perform certain workloads. You're going to be writing a lot of policies as they're, essentially, the backbone of all access control inside of IAM and AWS.

An IAM Policy can almost control anything, from who can access something, to when, and under what conditions (their IP address, having MFA enabled, a certain time of day.) They're extremely powerful.

IAM Policies are written in JSON (but there are other abstractions). We'll see this when we look at a few examples shortly.

AWS also provides a lot of managed policies. These save us time in some situations as they're fully managed and just plug and play. They're not appropriate in all situations, however. We'll review a few of AWS' managed policies in due course.

Roles#

After we've defined our IAM Users, we can group them into IAM Groups. When we define IAM Policies, we can "group" them into IAM Roles. Therefore, an IAM Role is a container of one or more IAM Policy (among other things, like permissons boundaries.)

IAM Roles are act as temporary credentials. So when a user uses or "assumes" an IAM Role, they're actually getting a temporary set of credentials (behind the scenes) and those credentials have all the permissions attached to the role. Don't worry - we'll explore this more too.

IAM Roles are another thing you'll see a lot of. We'll create several and get them well and truly covered.