IAM Introduction

Everything in AWS is private by default. That means that if we setup an S3 bucket and put files in it, no one is able to access that bucket or those files, unless they are granted permission.

This also means that services can't access other services in AWS. If we setup an EC2 instance in the same account, it would not be able to access the files in that S3 bucket without being granted permission.

This is the principle of least privilege, and it means that we have to very explicitly grant permission for users or services to be able to access other services.

What is IAM?

IAM stands for Identity and Access Management, it's AWS's security service that allows us to control how different services can be accessed and what or who can access them.

There are four key IAM components that we need to know about: policies, roles, users, and groups. For the most part, we'll just be working with policies and roles, but let's take a look at all four.

Let's say we have an S3 bucket that we're using for file storage, kind of like dropbox. By default, nothing will be able to access the S3 bucket, so how do we change that?

Policies

Policies are JSON documents that define the permissions for a service. So if we want to allow something or someone to get files and add new files to our S3 bucket, we could write an IAM policy that looks like this.

{

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "s3:GetObject",

                "s3:PutObject"

            ],

            "Resource": [

                "arn:aws:s3:::your-bucket-name/*"

            ]

        }

    ]

}

This policy allows GetObject and PutObject on any object(*) in the S3 bucket named your-bucket-name.

Remember the principle of least privilege - only grant the minimum permissions needed to get the job done.

Even though policies are JSON, you don't have to write them by hand every time you make one. There's tools in AWS that do it for you, or just get your favourite LLM to do it for you.

And remember, policies are literally just JSON documents, nothing more. Creating a policy does nothing more than just creating a JSON document. We can't just give the policy to a service like EC2, we instead have to use a Role or a User

Roles

An IAM role is something we can actually assign to a service. So we could create a role and assign it to a service like an EC2 instance. The role would then act as that EC2 instances identity when it tries to access other services.

It's as if the EC2 instance is "logged in" to the AWS account, but instead of it having to use a username and password, it uses temporary security credentials managed by IAM. Assigning a role to an EC2 instance gives that EC2 instance an identity in AWS.

But roles don't have any default permissions, the EC2 instance can't do anything until we associate one or more policies with the role.

So if we create a new role, assign that role to our ec2 instance, and associate the policy from before with that role, the EC2 instance will now be able to GetObject and PutObject on the S3 bucket. This is the secure way to give EC2 instances AWS access.

Users

If a role can be used to give an identity to a service within AWS, a user can be used to give an identity to anything outside AWS.

As the name implies, we can use an IAM user to allow a real person to login to our AWS account with a username and password and access certain services. If we associated our current policy with a user, they would be able to GetObject and PutObject on the S3 bucket.

But this isn't the best way of allowing someone to access services in our accounts. For that we used IAM Identity Center which is a different service and I'll mention it again at the end.

Another use case for IAM users is to allow services outside of AWS to access our accounts. We can create an IAM user that uses access keys instead of a username and password which would allow an application to "log in" to our account and access things.

It's not uncommon for a web app hosted outside of AWS to use an IAM user to access an S3 bucket in this exact way. But there are some security pitfalls to this if the tokens ever get leaked.

Groups

Groups are collections of users that make it easier to manage permissions for multiple people.

Instead of attaching our S3 policy to 5 different developers individually, we could create a "Developers" group, attach the policy to the group, and then add all 5 developers to that group.

Groups are only for organizing users though - you can't add roles to groups or assign groups to EC2 instances. And since IAM Identity Center (the better way to give people access) has its own group system, IAM groups are used less frequently now.

IAM vs IAM Identity Center

IAM Identity Center is what we used to setup our user in the first part of the course. This service manages our permissions and how we login to the web console. We're using IAM Identity Center every time we login to the web dashboard or authenticate with the AWS CLI.

Basically, IAM Identity Center is a service we use to allow real people to login to our AWS account and manage exactly what that user has access to.

IAM on the other hand is what we use to handle access and permissions for everything else (like giving a Lambda function permission to write to CloudWatch, or an EC2 instance access to S3).

However, we can also use IAM to manage users in the same way as IAM Identity Center, but it's much better to use IAM Identity Center for that because it's newer, more secure, and designed specifically for this task.

IAM is Global and Free

One last thing, IAM is a global service and it's free. That means we create a roles and policies globally and assign roles to services in any region without having to re create these things in every region we deploy infrastructure to.

IAM is also free, so we can create as many policies, roles, and users as we like. No extra charge.

Show timestamps
00:00
Every service in AWS is private by default.
00:04
So if we were to set up an S3 bucket in our AWS account,
00:09
and let's say we add some files to this S3 bucket,
00:13
by default, no one is able to access this bucket
00:17
or the files within this bucket
00:19
unless they are granted permission.
00:21
So essentially these files can't be accessed.
00:23
And if we were to set up an EC2 instance in the same account
00:28
the instance would not be able to access
00:31
any of the files in that S3 bucket
00:34
unless we granted permission for that instance
00:37
to be able to access the objects in that bucket.
00:39
And this is the principle of least privilege.
00:41
It means we explicitly have to grant permission
00:44
to users and services to be able to access other services.
00:48
And since I'm already logged into my account
00:50
with the admin user that we set up earlier,
00:53
I am able to access any service,
00:55
but nothing and no one else is able to access
00:58
anything I create.
00:59
So this is where IAM comes in,
01:01
which stands for Identity and Access Management.
01:04
And it is AWS's security service
01:06
that allows us to grant these permissions.
01:08
And there's four key IAM components
01:11
that we're gonna look at,
01:12
which are policies, roles, users, and groups.
01:17
And for the most part,
01:18
we'll just be working with policies and roles,
01:21
but we're gonna take a quick look at all four of these.
01:23
So I'm gonna come back to this S3 bucket example,
01:27
this kind of,
01:28
pretend Dropbox.
01:29
We have an S3 bucket,
01:30
and we wanna be able to add files to it
01:32
and then read those files,
01:33
get those files back later on.
01:35
As we know, nothing can access this S3 bucket,
01:38
but we can create a policy.
01:41
And a policy is a JSON document
01:44
that defines permissions for a service.
01:47
So I could write an IAM policy that looks like this,
01:52
where we are allowing get object and put object
01:56
on any object.
01:57
That's the star here within a bucket named your bucket name.
02:02
So this is just JSON that is defining the rules
02:06
for the access to a specific S3 bucket in this case.
02:09
And we always wanna be working
02:11
with that principle of least privilege.
02:12
So I explicitly wanna specify exactly which actions
02:16
I can take on which objects, which bucket in this case.
02:20
'Cause I could just allow every single action.
02:22
I could allow deleting objects,
02:24
listing all the objects in a bucket.
02:26
I could allow creating and deleting objects.
02:27
And deleting buckets themselves.
02:29
But what I really wanna do is use the principle
02:32
of least privilege and only grant exactly what we need.
02:34
And these are JSON.
02:36
You won't necessarily have to write them by hand
02:38
if you don't want to.
02:39
There are tools in AWS that will write these for you,
02:42
or you could honestly just get an LLM to do this.
02:45
But this is just JSON.
02:47
It's nothing more.
02:48
This doesn't automatically grant access to the S3 bucket.
02:51
We can't just give this policy
02:53
to something like an EC2 instance
02:54
and have that access the bucket now.
02:57
It's not just a JSON document.
02:59
It's just defining exactly what permissions we wanna give.
03:02
But an IAM role is something
03:05
that we can actually assign to a service.
03:07
So I could create a role in my account
03:11
and I could create, let's say an EC2 instance.
03:14
And I would be able to assign this role to my instance.
03:18
And this role will now act as the EC2 instances identity
03:22
when it tries to access other services within AWS.
03:25
The role pretty much allows
03:27
an EC2 instance to kind of log in to my AWS account,
03:31
kind of like a user would with a username and password.
03:34
But the role actually uses temporary security credentials
03:37
to grant access to things for the EC2 instance.
03:40
But by default,
03:41
the role doesn't have permission to do anything.
03:43
It's like allowing a user to log into the AWS account,
03:46
but they have permission
03:47
to do absolutely nothing while they're there.
03:49
So we can give the role to the instance,
03:51
but it still can't do anything.
03:52
It just gives an identity to the EC2 instance.
03:55
But what we can do is,
03:56
we can associate a policy with our role.
04:00
So the EC2 instance is essentially logged in using the role
04:04
and the role has whatever policies we want assigned to it.
04:07
So in this case,
04:08
if I assign this specific policy to this role
04:11
and attach that role to the EC2 instance,
04:13
through this role and policy,
04:15
my instance is now able to get object
04:18
and put object on any object within this bucket.
04:22
And we can create as many policies as we want
04:24
and we can assign those to a role.
04:26
And then a single EC2 instance will get a single role.
04:30
Or we could share this role among many EC2 instances
04:34
and anything with this role will get permission
04:38
to do anything to find in the policies assigned to that role.
04:40
And this is basically what we're gonna be doing
04:42
in this section.
04:43
We're gonna be creating policies and using roles
04:46
so that we can have EC2 access other services within AWS.
04:51
And as long as you're working within AWS,
04:53
having services access other services,
04:55
most of the time,
04:56
you'll just be dealing with policies and roles.
04:58
But there are users too,
05:00
and these are very similar to roles.
05:03
So if a role can be used to give an identity
05:06
to a service within AWS,
05:08
a user can be used to give an identity
05:12
to something outside of AWS.
05:14
So this could be a service that isn't part of AWS.
05:18
It could be an application that exists somewhere else,
05:20
or it could be an actual person
05:22
that wants to log in with a username and password.
05:24
So a user can,
05:26
expose things like access keys.
05:28
And this is great if we have an application,
05:31
it's hosted somewhere else,
05:32
and we want that application to be able to access something
05:34
like our S3 bucket,
05:35
or it can also give us a username and password combination
05:40
to have a user log in.
05:42
And in this case, be able to access the S3 bucket.
05:44
And users can be assigned policies just like roles can.
05:48
So I can create a user that has these exact same permissions,
05:51
but we can use them for things outside of AWS.
05:54
Now, if we're setting up,
05:56
users to access the account,
05:57
we actually want to use IAM Identity Center,
06:00
like we did in the first section of this course,
06:02
because that is newer and it's more secure.
06:05
And I'll talk a little bit more about that later,
06:07
but it's not uncommon to create a user
06:10
to give your web application that's hosted
06:13
with a different service,
06:14
to give that application access to a service in AWS.
06:18
And S3 is a really common one.
06:19
So we could create a user,
06:21
get access keys that we would then need to manage securely.
06:24
It's a little less secure than using roles,
06:25
but then our outside application gets access
06:28
to exactly what we've defined in the policy.
06:31
And finally, there's groups,
06:34
which are just ways of organizing a bunch of users.
06:38
So if I did have a few users
06:40
that needed the exact same permissions,
06:41
instead of having to sign a policy
06:44
to each user individually,
06:46
I could create a group of users
06:47
instead of manage them that way.
06:48
But since this doesn't apply to roles,
06:51
it only applies to users.
06:52
We won't be using groups in this course,
06:54
but there's also groups
06:55
in Identity Center if you did want to manage
06:57
a whole bunch of users using IAM Identity Center
07:01
instead of IAM.
07:02
Because Identity Center,
07:03
that thing that we set up in the first section
07:05
to set up our own user that we use now to log in
07:08
from the web console and from the AWS CLI,
07:11
that's the service that we want to use
07:12
when we're dealing with real people
07:14
that log into these accounts.
07:15
It's a more secure and newer service
07:18
that we should use for this.
07:19
However, IAM has been around for a long time
07:22
and it used to be that we would create users
07:25
through regular IAM
07:27
and then we could manage them through these groups.
07:29
But if you're working with real users,
07:31
use IAM Identity Center instead.
07:33
And we're mainly gonna be focusing on creating roles
07:36
and policies to be able to give permission
07:40
for one service in AWS to access another service within AWS.
07:44
IAM is also global and free.
07:47
So we don't specify a single region
07:49
to create a policy or a role in,
07:51
we just create it globally
07:52
and then we can use it in any region and it's free.
07:55
So we don't have to worry
07:56
about how many roles or policies we create.
07:58
We can create hundreds, thousands of policies if we want,
08:00
we can make them really fine grained
08:02
for exactly what we need.
08:03
And we don't get charged anything extra
08:05
for creating anything in IAM.
08:07
And in the next part,
08:08
we're gonna look at exactly how we can set up IAM roles
08:13
and policies to give an EC2 instance
08:15
access to other services within AWS.