- Now let's take a look at a demo
of creating roles.
From the AWS Management Console dashboard,
again, in order to create roles,
those are found under the IAM service.
So, since we've been there recently
we can go here, just follow that link.
And you can see that we already have
a number of roles.
It shows us that I have 25 different roles
in this particular account.
These are things that I've done in the past.
So, if we click on that,
there's a number of different roles that,
some of these were created for me
by Amazon Services,
some of these I created myself.
And so, we're going to create
a couple of different roles here.
Again, you can see I am logged in
as my admin user.
So, whatever user is
in the console trying to do this
would of course need the permissions
to create roles and permissions
to assign policies to those roles.
So, let's first create a role for EC2.
So, there are several different types of roles.
You can see that we have roles
for AWS services that allows
the service to do things on your behalf,
such as EC2, Lambda and so on.
We have another AWS account,
either belonging to you or a third party.
And then of course we have web identity.
We're gonna talk a lot about that kind of thing
much more later on
and throughout the course we'll talk
more about different ways
we can use web identity
so that our users can log in
with things like Facebook, Google,
Twitter, and so on.
And then of course we could create a role
that's specifically meant for federation.
So, in this particular case
let's just create a role for EC2.
Let's say that we have,
we've chosen EC2, and let's say that we have
an application that will be deployed
directly to an EC2 instance,
and that application needs to communicate
to S3 or DynamoDB, or whatever.
Then the better way of going
about giving that application permissions
is to give the instance permission,
or attach a role to the instance.
Then the application can retrieve
temporary credentials based on that role.
All right, so now it's saying Attach permissions.
So let's do a search for S3 and see.
We could say S3 full access
or read only access.
Let's just do that one for now.
Right, whatever permissions you apply,
the really important thing here is
that whatever permissions you apply
to this role are then
available from that instance.
For example, if we were to give
S3 full access, then S3 full access
would allow this role to create buckets,
create objects and delete objects
and delete buckets.
So, the important thing to realize
is that whomever, anyone,
any person or any application
that has access to that instance
would then have access to the temporary credentials
and they could then use those temporary credentials
to perform the actions that are allowed
by these policies, right.
So, if I grant this role S3 full access
and someone is able to somehow compromise
that instance and gain remote access to it,
they could find those temporary credentials
and then on that instance use them
to potentially delete S3 resources, right.
So we want to be very careful
about the permissions that we give
to these kinds of roles.
We should be following the principle of least privilege
and giving our applications
the permissions that they need and no more.
So, just for example, if we wanted
an application to be able to read
everything from S3, but not delete,
not create new things, then we could,
just as a quick example,
say S3 read only access.
Or we could create a policy
specifically for that application,
which is the ideal thing to do.
But we're gonna keep it simple for now.
Ideally, I would normally,
in a production scenario,
I would create a policy specifically
for the way in which those credentials
would be used, specifically
for that application on that instance.
But for now, let's just keep it simple for now
and attach this existing read only policy.
We can go next to tags and again,
tags can help us organize our environment.
We could say what environment this is for,
maybe it's for dev.
We can say what application,
and maybe we call this
our fundamentals application.
You know we could add any kind
of key value pair that helps us make sense
and helps us organize the resources
in our environment.
Right, so let's go and review that.
We're gonna call this one
fundamentalsApplication.
And then it says, here we're going to say
"Allows fundamentals application,"
our imaginary fundamentals application,
"to read everything from S3."
And again, you know, just going back
to a point I made earlier,
I want to reiterate it,
because it's so important.
That I've given this instance,
you know, read access across all of S3.
And so, if I have sensitive data stored
in a bucket somewhere,
be it personally identifiable information,
protected health information,
any kind of credential stores
or classified information
if you're working in gov cloud,
then by applying this policy
to this role,
we are essentially granting
that instance access to that data.
Again, we want to be really careful
about the permissions that we are giving
to our applications
and to our EC2 instances.
And especially in the case of EC2 instances
when we are granting permissions to them
via roles like this,
we want to take extra precaution
to really prevent unwarranted
or unauthorized remote access.
So, let's go ahead and create that role
and if we scroll down here,
here's our fundamentals role, right.
You can see here that it has
a specific role ARN
and it also has an instance profile.
The instance profile is what is actually
applied directly to the instances.
The role is applied to the profile.
The profile is applied to the instances.
And so, it's through that mechanism
that the instance can retrieve
temporary credentials and then
use those credentials to access
whatever resources were granted access to,
in this case S3.
All right?
That's creating roles for EC2.
Let's take a look at creating a role
for another account.
This is a very common pattern
and a very powerful pattern, right.
And so, we need to find our account ID,
so we need the identifier of the account,
and it could be an account that you own
or an account belonging to a third party.
Okay, so we're going to do here,
I'm going to paste the account number
of another account that I have.
For you, if you have multiple accounts
then you could use one of your other accounts.
So I'm gonna paste that account number.
Okay, so we've pasted our account ID
and then we have a couple of options.
If it's our own account,
then we don't necessarily have to do
either of these other two things.
But if we are sharing,
if we're creating this role
that was meant to be assumed
by someone in a third party,
like a vendor or a client,
then we might require an external ID.
That's just an extra level of validation.
So, if I do that, it says here
"You can increase the security of your role
"by requiring an optional external identifier,
"which prevents confused deputy attacks."
We could apply that external ID
for that other resource,
for that third party.
In this case, since it's an account I own
I don't need to worry about it.
I could also require MFA
or multifactor authentication.
And so, I generally like that one.
It just makes me feel better
that if they are assuming this account
or assuming this role,
then they are going to gain access
to resources in this account.
And so this could be a production account.
That's a common practice where users
are in, let's say, like an admin account,
but then we give them cross-account access
by way of a cross-account role
and into the production account
or some other account.
Again, by allowing them to assume
this cross-account role
we give them access to all
of the resources in that account,
or at least what they are permitted
to access based on this role.
And so, let's go ahead and say Next Permissions.
Again, we need to find,
attach a policy that grants
some type of permission.
And again, we could create a policy
specifically for what this role
will be used for.
In this case again, let's just,
as a quick example, do S3 read only.
We could also do EC2 read only access,
for example, and say Next Tags.
And again, we could apply tags
to this role if we needed to,
we'll go ahead and skip that for now
and review that, and we'll call this one
prodAccountReadAccess.
So this will say "Allows users
"who assume this role
"to read S3 and EC2
"in production account."
Okay, so now that we've got
all of that in place
we can say Create Role,
and if we search for prod, here it is.
Here's our prod account role.
And so now, in order for a user
within the current account to assume that one,
or for a user to assume that,
we would give them this ARN.
So we could,
and this value is safe to email
because it's not really secret
and just having this information
doesn't really allow you to do anything with it.
Anyone trying to use this
would have to be allowed to use it.
And the only person allowed to use it
is the person in this account, right?
Someone who has been explicitly,
an IAM user who has explicitly been granted
the ability to assume this particular role.
So that's how we can create roles
for both EC2 and cross-account.