Introduction to AWS Identity and Access Management

What Is the AWS Root User?

When you first create an AWS account, you begin with a single sign-in identity that has complete access
to all AWS services and resources in the account. This identity is called the AWS root user and is accessed
by signing in with the email address and password that you used to create the account.

WHAT IS IAM?

IAM is a web service that enables you to manage access to your AWS account and resources. It also
provides a centralized view of who and what are allowed inside your AWS account (authentication), and
who and what have permissions to use and work with your AWS resources (authorization).With IAM, you
can share access to an AWS account and resources without having to share your set of access keys or
password. You can also provide granular access to those working in your account, so that people and
services only have permissions to the resources they need. For example, to provide a user of your AWS
account with read-only access to a particular AWS service, you can granularly select which actions and
which resources in that service they can access.

GET TO KNOW THE IAM FEATURES

To help control access and manage identities within your AWS account, IAM offers many features to
ensure security.

• IAM is global and not specific to any one Region. This means you can see and use your IAM
configurations from any Region in the AWS Management Console.

• IAM is integrated with many AWS services by default.

• You can establish password policies in IAM to specify complexity requirements and mandatory
rotation periods for users.

• IAM supports MFA.

• IAM supports identity federation, which allows users who already have passwords elsewhere—for
example, in your corporate network or with an internet identity provider—to get temporary access
to your AWS account.

• Any AWS customer can use IAM; the service is offered at no additional charge.
WHAT IS AN IAM USER?

An IAM user represents a person or service that interacts with AWS. You define the user within your AWS
account. And any activity done by that user is billed to your account. Once you create a user, that user can
sign in to gain access to the AWS resources inside your account.You can also add more users to your
account as needed. For example, for your cat photo application, you could create individual users in your
AWS account that correspond to the people who are working on your application. Each person should have
their own login credentials. Providing users with their own login credentials prevents sharing of credentials.

IAM USER CREDENTIALS

An IAM user consists of a name and a set of credentials. When creating a user, you can choose to provide
the user:

• Access to the AWS Management Console

• Programmatic access to the AWS Command Line Interface (AWS CLI) and AWS Application
Programming Interface (AWS API)

To access the AWS Management Console, provide the users with a user name and password. For
programmatic access, AWS generates a set of access keys that can be used with the AWS CLI and AWS
API. IAM user credentials are considered permanent, in that they stay with the user until there’s a forced
rotation by admins.When you create an IAM user, you have the option to grant permissions directly at the
user level.This can seem like a good idea if you have only one or a few users. However, as the number of
users helping you build your solutions on AWS increases, it becomes more complicated to keep up with
permissions. For example, if you have 3,000 users in your AWS account, administering access becomes
challenging, and it’s impossible to get a top-level view of who can perform what actions on which
resources.If only there were a way to group IAM users and attach permissions at the group level instead.
Guess what: There is!

WHAT IS AN IAM GROUP?

An IAM group is a collection of users. All users in the group inherit the permissions assigned to the group.
This makes it easy to give permissions to multiple users at once. It’s a more convenient and scalable way
of managing permissions for users in your AWS account. This is why using IAM groups is a best practice.If
you have a an application that you’re trying to build and have multiple users in one account working on
the application, you might decide to organize these users by job function. You might want IAM groups
organized by developers, security, and admins. You would then place all of your IAM users in the
respective group for their job function.This provides a better view to see who has what permissions within
your organization and an easier way to scale as new people join, leave, and change roles in your
organization.Consider the following examples.

• A new developer joins your AWS account to help with your application. You simply create a new
user and add them to the developer group, without having to think about which permissions they
need.

• A developer changes jobs and becomes a security engineer. Instead of editing the user’s permissions
directly, you can instead remove them from the old group and add them to the new group that
already has the correct level of access.

Keep in mind the following features of groups.

• Groups can have many users.

• Users can belong to many groups.

• Groups cannot belong to groups.

The root user can perform all actions on all resources inside an AWS account by default. This is in contrast
to creating new IAM users, new groups, or new roles. New IAM identities can perform no actions inside
your AWS account by default until you explicitly grant them permission.The way you grant permissions
in IAM is by using IAM policies.

WHAT IS AN IAM POLICY?

To manage access and provide permissions to AWS services and resources, you create IAM policies and
attach them to IAM users, groups, and roles. Whenever a user or role makes a request, AWS evaluates the
policies associated with them. For example, if you have a developer inside the developers group who makes
a request to an AWS service, AWS evaluates any policies attached to the developers group and any policies
attached to the developer user to determine if the request should be allowed or denied.
IAM POLICY EXAMPLES

Most policies are stored in AWS as JSON documents with several policy elements. Take a look at the
following example of what providing admin access through an IAM identity-based policy looks like.

"Version": "2012-10-17",

"Statement": [{ "Effect": "Allow",

"Action": "*",

"Resource": "*"

}]

In this policy, there are four major JSON elements: Version, Effect, Action, and Resource.

• The Version element defines the version of the policy language. It specifies the language syntax
rules that are needed by AWS to process a policy. To use all the available policy features,
include "Version": "2012-10-17" before the "Statement" element in all your policies.

• The Effect element specifies whether the statement will allow or deny access. In this policy, the
Effect is "Allow", which means you’re providing access to a particular resource.

• The Action element describes the type of action that should be allowed or denied. In the above
policy, the action is "*". This is called a wildcard, and it is used to symbolize every action inside
your AWS account.

• The Resource element specifies the object or objects that the policy statement covers. In the policy
example above, the resource is also the wildcard "*". This represents all resources inside your AWS
console.

Putting all this information together, you have a policy that allows you to perform all actions on all
resources inside your AWS account. This is what we refer to as an administrator policy.

Let’s look at another example of a more granular IAM policy.

"Statement": [{

"Effect": "Allow",

"Action": [

"iam: ChangePassword",

"iam: GetUser"

"Resource":

"arn:aws:iam::123456789012:user/${aws:username}"

}]

After looking at the JSON, you can see that this policy allows the IAM user to change their own IAM
password (iam:ChangePassword) and get information about their own user (iam:GetUser). It only
permits them to access their own credentials because the resource restricts access with the variable
substitution ${aws:username}.

UNDERSTAND POLICY STRUCTURE

When creating a policy, it is required to have each of the following elements inside a policy statement.

Element Description Required Example

Effect Specifies whether the statement results in ✔ "Effect": "Deny"

Action Describes the specific actions that will be ✔ "Action":

Resource Specifies the object or objects that the ✔ "Resource": "arn:aws:iam::account-ID-without-

Protect the AWS Root User

What’s the Big Deal About Auth?

When you’re configuring access to any account, two terms come up frequently: authentication and
authorization. Though these terms may seem basic, you need to understand them to properly configure
access management on AWS. It’s important to keep this mind as you progress in this course. Let’s define
both terms.

Understand Authentication

When you create your AWS account, you use a combination of an email address and a password to verify
your identity. If the user types in the correct email and password, the system assumes the user is allowed
to enter and grants them access. This is the process of authentication.Authentication ensures that the user
is who they say they are. Usernames and passwords are the most common types of authentication, but you
may also work with other forms, such as token-based authentication or biometric data like a fingerprint.
Authentication simply answers the question, “Are you who you say you are?”

Understand Authorization

Once you’re inside your AWS account, you might be curious about what actions you can take. This is
where authorization comes in. Authorization is the process of giving users permission to access AWS
resources and services. Authorization determines whether the user can perform an action—whether it be to
read, edit, delete, or create resources. Authorization answers the question, “What actions can you perform?”

What Is the AWS Root User?

When you first create an AWS account, you begin with a single sign-in identity that has complete access
to all AWS services and resources in the account. This identity is called the AWS root user and is accessed
by signing in with the email address and password that you used to create the account.
Understand the AWS Root User Credentials

The AWS root user has two sets of credentials associated with it. One set of credentials is the email address
and password used to create the account. This allows you to access the AWS Management Console. The
second set of credentials is called access keys, which allow you to make programmatic requests from the
AWS Command Line Interface (AWS CLI) or AWS API. Access keys consist of two parts:

• An access key ID, for example, A2lAl5EXAMPLE

• A secret access key, for example, wJalrFE/KbEKxE

Similar to a username and password combination, you need both the access key ID and secret access key
to authenticate your requests via the AWS CLI or AWS API. Access keys should be managed with the
same security as an email address and password.

Follow Best Practices When Working with the AWS Root User

Keep in mind that the root user has complete access to all AWS services and resources in your account, as
well as your billing and personal information. Due to this, securely lock away the credentials associated
with the root user and do not use the root user for everyday tasks. To ensure the safety of the root user:

• Choose a strong password for the root user.

• Never share your root user password or access keys with anyone.

• Disable or delete the access keys associated with the root user.

• Do not use the root user for administrative tasks or everyday tasks.

When is it OK to use the AWS root user? There are some tasks where it makes sense to use the AWS root
user. Check out the links at the end of this section to read about them.

Delete Your Keys to Stay Safe

If you don't already have an access key for your AWS account root user, don't create one unless you
absolutely need to. If you do have an access key for your AWS account root user and want to delete the
keys:

1. Go to the My Security Credentials page in the AWS Management Console and sign in with the root
user’s email address and password.
 2. Open the Access keys section.

3. Under Actions, click Delete.

4. Click Yes.

The Case for Multi-Factor Authentication

When you create an AWS account and first log in to that account, you use single-factor authentication.
Single-factor authentication is the simplest and most common form of authentication. It only requires one
authentication method. In this case, you use a username and password to authenticate as the AWS root
user. Other forms of single-factor authentication include a security pin or a security token.However,
sometimes a user’s password is easy to guess.

For example, your coworker Bob’s password, IloveCats222, might be easy for someone who knows Bob
personally to guess, because it’s a combination of information that is easy to remember and describes
certain things about Bob (1. Bob loves cats, and 2. Bob’s birthday is February 22).

If a bad actor guessed or cracked Bob’s password through social engineering, bots, or scripts, Bob might
lose control of his account. Unfortunately, this is a common scenario that users of any website often face.

This is why using MFA has become so important in preventing unwanted account access. MFA requires
two or more authentication methods to verify an identity, pulling from three different categories of
information.

• Something you know, such as a username and password, or pin number

• Something you have, such as a one-time passcode from a hardware device or mobile app

• Something you are, such as fingerprint or face scanning technology

Using a combination of this information enables systems to provide a layered approach to account access.
Even though the first method of authentication, Bob’s password, was cracked by a malicious user, it’s very
unlikely that a second method of authentication, such as a fingerprint, would also be cracked. This extra
layer of security is needed when protecting your most sacred accounts, which is why it’s important to
enable MFA on your AWS root user.
 Use MFA on AWS

If you enable MFA on your root user, you are required to present a piece of identifying information from
both the something you know category and the something you have category. The first piece of identifying
information the user enters is an email and password combination. The second piece of information is a
temporary numeric code provided by an MFA device.Enabling MFA adds an additional layer of security
because it requires users to use a supported MFA mechanism in addition to their regular sign-in credentials.
It’s best practice to enable MFA on the root user.

Review Supported MFA Devices

AWS supports a variety of MFA mechanisms, such as virtual MFA devices, hardware devices, and
Universal 2nd Factor (U2F) security keys. For instructions on how to set up each method, check out the
Resources section.

Device Description Supported Devices

Virtual A software app that runs on a phone or other device that provides a one- Authy, Duo Mobile, LastPass
MFA time passcode. Keep in mind that these applications can run on unsecured Authenticator, Microsoft
mobile devices, and because of that, may not provide the same level of Authenticator, Google
security as hardware or U2F devices. Authenticator

Hardware A hardware device, generally a key fob or display card device that Key fob, display card
generates a one-time six-digit numeric code

U2F A hardware device that you plug into a USB port on your computer YubiKey