-In this lecture, we will take a look at identity and
access management in AWS.
In the previous demo, we saw how to set up an AWS account.
To sign up, we use an email address and a password.
After completing the sign-up process, we can now log into
the AWS management console using the same credentials.
This email address that was used to sign up to the AWS account is
also known as the root account.
It has complete administrative privileges.
You can manage any service within AWS using the root account, but this
is not the recommended approach.
This user account can be compared to the root user in Linux and admin
user in Windows, which have complete administrative privileges to carry
out any task in the operating system.
Just like the root or admin user, you should not rely on the root
account as your daily driver to operate your AWS account.
When your AWS account is just set up, this is the only account you can use
to sign into the management console.
However, using the root account, we can create new users and assign
them appropriate privileges.
That should be the only purpose of using the root account.
Once these users have been created, lock away the root account
credentials securely and do not use it unless it's absolutely necessary.
To start off, let us create a few new users called
Lucy, Max, Abdul, and Lee.
When we create users in AWS, there are two types of access that we can
configure; access to the management console and programmatic access.
To access the management console, a user should have a
valid username and a password.
The programmatic access is used to interact programmatically by
using command-line interfaces such as the terminal on Linux
and Mac or PowerShell in Windows.
To do this, we create an access key ID and a secret access key, which
need to be configured on the CLI before we can start making use of
the terminal to connect to AWS.
The programmatic access keys cannot be used to log
into the management console.
We will see how to use these in a demonstration video
that follows the lecture.
Now let us see how to assign permissions to these users.
As a standard, when a user is just created, AWS assigns least
privilege permission to the user.
What a user can or cannot do in AWS is decided by the permissions that
are defined within an IAM policy.
For example, let us assume that Lucy is the technical lead for
a project that will be deployed in AWS, which is the reason why
the AWS account was created.
She needs to have admin access to all services and resources in AWS.
To do this, we can add an IAM policy called administrator
access to her user account.
This policy, along with several others, are managed
by AWS and are available to use when creating a user.
An IAM policy is defined in adjacent format.
If we inspect the adjacent document of this policy from the AWS console,
we can see that it's a simple adjacent document that defines the
permissions granted by the policy.
Under the policy statement, we can see the resources that are applicable
to the policy, the action that can be carried out on those resources,
and the effect of the policy.
In this example, the resource and action have a value of
star, which means all resources in AWS and all actions.
The effect field has a value of allow, which effectively means
allow all actions on all resources in AWS, which is why this policy is
known as the administrative policy.
Once this policy is attached to Lucy's user account, she
has complete access to all the resources in the AWS account.
As mentioned previously, the administrator access policy
is an AWS managed policy.
There are several of these provided by AWS that are
designed to provide permissions for many common use cases.
Once a use case is assigning by job function, as we just saw Lucy
being the technical lead and the owner of the account has been
granted admin access by attaching the AWS managed administrator
access policy to her user.
Here are some more AWS-managed policies that are designed for
specific job functions such as a billing policy that will allow
users to view billing information, set up, and authorize payments.
The database administrator policy that allows users
to set up, configure, and maintain databases such as
DynamoDB, RDS, et cetera in AWS.
The network administrator policy grants permissions
to the user to set up and maintain AWS network resources.
For the complete list of policies categorized by job functions,
refer the reference document that follows this lecture.
The other users of this team, Max, Abdul, and Lee are developers who
need access to AWS EC2 and the S3 service to develop their application.
To do this, we can attach two managed policies to each user like this.
Better yet, since Max, Abdul, and Lee are part of the same team and
have the same permission, we can add them to a group called developer.
An IAM group is a collection of users.
This allows us to specify permissions to multiple users at once.
This way, we can directly attach the policies to the
group rather than having to assign them to individual users.
If you want additional permission for any user in a group, we can
also adapt specific policies to an individual user in the group.
Once permission has been attached to the group, the users part of
the developer group have complete access EC2 and S3 service in AWS.
The access provided so far has been for humans.
People who either want to carry out tasks using the management
console or programmatically by making use of the access key
ID and the secret access keys.
Until now, we have seen how to create users, groups, and
attach policies to them in AWS.
But what about other services?
Say an EC2 instance wants to read from and write data to an S3 bucket,
would that work out of the box?
The answer is no.
Just like regular users, resources in AWS also do not
have any permission to interact with other services by default.
They need to be granted access specifically.
However, unlike regular users, we cannot attach an IAM
policy to a service directly.
Instead, in order to allow an EC2 instance to be able to interact with
S3 buckets, we have to create a role.
An IAM role allows us to securely grant access to an AWS service to act
on other AWS services in the account.
In this example, we need to create a role.
Let's call it S3 access role to be applied on the EC2 service.
With the role, we can attach the same IAM policy called
Amazon S3 full access that we use for the developer group.
Once this role is attached to an EC2 instance created in the
account, that instance should have complete access to the S3 service.
Note that there are other ways to give services such as EC2
access to other resources.
One example is configuring programmatic access.
This is however insecure, but we will see how this is done in
the coming lecture when we learn how to programmatically access
AWS using secret access keys.
Finally, IAM roles are not restricted to just providing access from one
service to another service in AWS.
Other users of IAM roles include providing access to an IAM user
belonging to another AWS account, providing access to applications
to interact with services in AWS, and providing access to
users managed outside AWS.
For example, access to users of an organization
that uses Active Directory.
Besides AWS managed policies, we can also create a
custom policy of our own.
This can be done from the AWS console like this.
For example, if you want to create an AWS policy that will
grant permissions for a user to create and delete tags on an EC2
instance, we can do it this way.
Here, we have the adjacent document, which is similar to the administrator
access policy, but in the actions, we have specified permissions to create
and delete tags for EC2 instead of a star, which is all actions.
Once created, the policy will be available to use
within the AWS account.