Welcome to 'Back to Basics', I am Gerardo Estaba.
Today we're going to talk about implementing
a strong identity foundation for your internal users.
If we ever build a house,
we don't want it to crumble down after a couple of years
for the lack of a strong foundation.
The same applies to our cloud applications.
We might be starting small, but over time
it is likely we're going to end up with more of those applications.
We're going to grow them, we're going to add features.
So, it's likely we'll end up with a couple of workloads
running across a couple of those accounts.
So, it makes sense to start with a strong foundation.
One of the most important foundations for building in the cloud is identity.
So, today we're going to talk about
four of the most important principles of identity in the cloud.
But I want to make it easy for you,
and we're going to give you a couple of tips
so that you can get started and implement those very easily.
So, let's do it!
Let's say we want to give AWS access to our colleagues.
I can create an AWS IAM user with long term credentials,
but this isn't always great
because creating another set of credentials
adds complexity to that user,
and that in turn makes it harder to secure.
The best thing we can do is getting authentication
to a centralized identity provider.
This is also called federation.
This way, we can manage all of our colleagues identities in one place.
There are many popular identity providers,
such as Okta, Ping, Active Directory,
or even the built-in identity provider that's available at AWS Single Sign-On.
By using a single identity provider
we can manage access to multiple applications and services
from a single place
because we can create, manage, and revoke access
in that one location.
For example, if someone leaves our organization,
we can revoke access to all of our applications and services,
including AWS, from one location.
This also reduces the need for multiple credentials for that particular user,
so users love that.
So, the first step is avoid creating AWS IAM users.
Instead, rely on a centralized identity provider
for federated access to AWS.
Another anti-pattern is using long term static credentials.
This is because, let's face it, people make mistakes.
I have been guilty of publishing access keys to GitHub,
despite telling my customers not to do it.
So, the best way to never lose an access key
is to never have an access key in the first place.
So, the tip here is we should eliminate the reliance on
long term static access credentials.
The good news is that we can enforce this for our colleagues
very easily and seamlessly
with the help of AWS Single Sign-On.
AWS SSO centrally manages access
to business applications in one location.
When federating access into AWS accounts,
AWS SSO acquires temporary credentials,
and then refreshes them on behalf of the users
when they're using the AWS console,
or the latest versions of the AWS CLI.
So, not only is this approach secure,
but it also provides a great experience to our colleagues.
So, now that we have our centralized identity provider,
and we're enforcing the use of temporary credentials
by federating access into AWS,
it is time we secure our root user.
The root user is the default one that we get
when we first create an AWS account from scratch.
This user has complete access to
all AWS services and resources in the account.
Given how much power this root user has,
the best thing we can do is
enable multi-factor authentication for it,
configure strong credentials for it,
and avoid using it altogether, or as much as possible.
While some actions require the use of the root user,
these are the exception,
and we should be using our identities from the identity provider
for all our general activities on AWS.
Finally, we should grant the least privilege access.
For our colleagues, it means giving them
the minimum permissions they need to perform their job.
This prevents unintended access.
So, how do we do this?
In our IAM policies, instead of using the wild cards,
we should be scoping down our policies,
and being as specific as possible.
We can specify the service actions, the resources,
and the conditions that must be true for AWS to allow access.
Managing IAM policies at scale
across multiple accounts can become challenging.
But guess what?
AWS Single Sign-On also makes life simple here.
AWS SSO configures and maintains
all the necessary IAM policies in our accounts automatically.
This way you can focus on assigning user permissions
based on common job functions,
and assign these permissions to users or groups
in the specific account where they are needed.
If you want to learn more
there are a lot of links for diving deep in the description below.
See you next time!