- Now let's take some time to understand roles.
Within AWS, a really powerful mechanism
for delegating permissions are roles,
and before we can understand roles,
let's first take a moment
to understand why we want to use them.
Let's talk about anti-patterns, credential anti-patterns.
And so some of the things that we don't want to do,
the things that we would like to avoid would be things
like embedding access keys in our code.
Remember, we talked about how users can create access keys
and then we can use those access keys
to configure our local development environments,
so that we can manage AWS from our local machines.
Those long-term access keys should never be embedded
within code, because by doing so,
there's a number of issues with that.
By embedding them in code,
or even within environment variables,
now we run the risk of those credentials being exposed
and being seen by other people.
I've heard of scenarios,
I've read reports, and even have friends of mine
where this has happened
where credentials have been committed into repos
and into public repos, like on GitHub,
and as a result, people out there,
who knows who, found those credentials.
In fact, there are bots out there
that are designed to scan public repositories looking
for credentials, right,
and so I've read stories
of developers exposing credentials within public repos
and then being surprised by an Amazon bill
at the end of the month that's thousands
of dollars beyond what they normally pay,
because people used those credentials
to create very expensive resources.
And so the other aspect
is that people have used credentials
to delete resources, right?
Another perspective on that
is that it could be that members
of your team find those credentials that are embedded
and end up using them in ways that they weren't intended,
even if it's not malicious.
They're just being used for purposes
that they shouldn't be used for,
right, so we really want to avoid embedding our code
or embedding our credentials within code
or within environment variables.
The other logistical challenge
with embedding credentials within our code
is that now if we want to rotate those credentials,
like we should be doing regularly,
we have to recommit, repush,
remerge, retest, rebuild,
redeploy code just to rotate credentials,
and that's not really a good reason
to go through all of that.
We have a better mechanism.
And so another thing that we don't
want to do is share credentials.
If you have an organization,
and members of your organization need to access Amazon,
then each member should have their own credentials,
right, so we don't want
to share credentials with third parties.
We don't want to have to create dummy users
in order to share credentials.
We certainly don't want to share one set
of credentials with hundreds of enterprise users,
and we don't want to share credentials
with potentially millions of web or application users,
right, so imagine deploying a web or mobile application.
By embedding credentials in that application, you
are essentially sharing those credentials across millions,
potentially millions of users.
We have other mechanisms to handle that.
And so, the best practices for credentials in this regard
to avoid those things would be to use temporary credentials,
and we can delegate permissions to,
for example, an EC2 instance.
So instead of embedding our credentials in our code,
and then deploying code to that instance,
if we instead give the instance a way
to retrieve permission or retrieve credentials,
then we can provide our application away to retrieve,
automatically retrieve credentials
that automatically expire,
and then get automatically renewed.
And so we can delegate permissions to EC2 instances,
to other Amazon services.
We can grant users within our own account the ability
to temporarily elevate their privileges,
or we can grant permissions to a separate account,
and that separate account could be one that you own,
or it could be a third-party.
It's really common for organizations within AWS
to have multiple accounts.
And it could be that you
have an account dedicated for development,
and it could be that you
have an account dedicated for production.
Or different business departments
or business units may have their own accounts
in order to achieve some type of isolation,
secure isolation, between different things, right?
And so using cross-account roles allows us
to log into one account
and then temporarily gain access into another account.
That also works really well
for client/vendor relationships, right?
So take myself for an example.
When I'm not teaching classes or not recording videos,
I'm consulting, and when I work with clients,
I tell them, hey, you don't need to create a user for me,
I already have a user, and
one of the least secure things you can do is create a user
and then email me the username and password.
That's exactly the kind of thing we want to avoid.
Instead, create a role for me and then email me the id
of that role, and then that way,
I can assume that role and gain access into your account.
And we will talk about how
to do those things in upcoming lessons.