Principals:

1. The first IAM concept to understand is principals.

2. A principal is an IAM entity that is allowed to interact with AWS resources.
A principal can be permanent or temporary, and it can represent a human
or an application.
3. There are three types of principals: root users, IAM users, and
roles/temporary security tokens.
Root User:

1. When you first create an AWS account, you begin with only a single sign-
in principle that has complete access to all AWS Cloud services and
resources in the account.
2. This principal is called the root user. As long as you have an open
account with AWS, the root user for that relationship will persist.
3. The root user can be used for both console and programmatic access to
AWS resources.

The root user is similar in concept to the UNIX root or

Windows Administrator account:

1. It has full privileges to do anything in the account, including closing

the account.
2. It is strongly recommended that you do not use the root user for your
everyday tasks, even the administrative ones.
3. Instead, adhere to the best practice of using the root user only to
create your first IAM user and then securely locking away the root
user credentials.

IAM Users:
 1. Users are persistent identities set up through the IAM service to
represent individual people or applications.
2. You may create separate IAM users for each member of your operations
team so they can interact with the console and use the CLI.
3. You might also create dev, test, and production users for applications
that need to access AWS Cloud services (although you will see later in
this chapter that IAM roles may be a better solution for that use case).
4. IAM users can be created by principals with IAM administrative
privileges at any time through the AWS Management Console, CLI, or
SDKs.
5. Users are persistent in that there is no expiration period; they are
permanent entities that exist until an IAM administrator takes an action
to delete them.

What is IAM?
1. AWS Identity and Access Management (IAM) is a web service that helps you
securely control access to AWS resources.

2. IAM, you can centrally manage permissions that control which AWS
resources users can access.

3. You use IAM to control who is authenticated (signed in) and authorized (has
permissions) to use resources.

4. When you create an AWS account, you begin with one sign-in identity that
has complete access to all AWS services and resources in the account.

5. This identity is called the AWS account root user and is accessed by signing
in with the email address and password that you used to create the
account.

6. We strongly recommend that you don't use the root user for your everyday
tasks.
7. Safeguard your root user credentials and use them to perform the tasks
that only the root user can perform.

IAM features:
IAM gives you the following features:

1. Shared access to your AWS account:

You can grant other people permission to administer and use resources in
your AWS account without having to share your password or access key.

2. Granular permissions:

1. You can grant different permissions to different people for different

resources.

2. For example, you might allow some users complete access to Amazon
Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service
(Amazon S3), Amazon DynamoDB, Amazon Redshift, and other AWS
services.

3. For other users, you can allow read-only access to just some S3 buckets,
or permission to administer just some EC2 instances, or to access your
billing information but nothing else.

3. Secure access to AWS resources for applications that run on Amazon

EC2:

1. You can use IAM features to securely provide credentials for applications
that run on EC2 instances.
 2. These credentials provide permissions for your application to access
other AWS resources. Examples include S3 buckets and DynamoDB
tables.

4 Multi-factor authentication (MFA):

1. You can add two-factor authentication to your account and to individual

users for extra security.
2. MFA you or your users must provide not only a password or access key
to work with your account, but also a code from a specially configured
device.
3. If you already use a FIDO security key with other services, and it has an
AWS supported configuration, you can use WebAuthn for MFA security.

5 Identity federation

1. You can allow 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.

6. Identity information for assurance:

1. If you receive log records that include information about those who made
requests for resources in your account.
2. That information is based on IAM identities.

7. PCI DSS Compliance:

IAM supports the processing, storage, and transmission of credit card data
by a merchant or service provider, and has been validated as being
compliant with Payment Card Industry (PCI) Data Security Standard (DSS).
 For more information about PCI DSS, including how to request a copy of the
AWS PCI Compliance Package.
8. Eventually Consistent:

1. IAM achieves high availability by replicating data across multiple servers

within Amazon's data centers around the world.

2. If a request to change some data is successful, the change is committed

and safely stored.

3. However, the change must be replicated across IAM, which can take
some time.

4. Such changes include creating or updating users, groups, roles, or

policies.

5. We recommend that you do not include such IAM changes in the critical,
high-availability code paths of your application.

6. Instead, make IAM changes in a separate initialization or setup routine

that you run less frequently.
9. Free to use:

1. Service (AWS STS) are features of your AWS account offered at no

additional charge.
2. You are charged only when you access other AWS services using your
IAM users or AWS STS temporary security credentials.

Accessing IAM:

1. Through the AWS Management Console—Like other services, the

AWS Management Console is the easiest way to start learning about
and manipulating a service.
 2. With the CLI—As you learn the system, you can start scripting
repeated tasks using the CLI.
3. Via the AWS SDKs—Eventually you may start writing your own tools
and complex processes by manipulating IAM directly through the
REST API via one of several SDKs.

When you are performing different job functions:

AWS Identity and Access Management is a core infrastructure service that provides the
foundation for access control based on identities within AWS. You use IAM every time you
access your AWS account.

How you use IAM differs, depending on the work that you do in AWS.

 Service user
If you use an AWS service to do your job, then your administrator provides you with the
credentials and permissions that you need. As you use more advanced features to do your
work, you might need additional permissions. Understanding how access is managed can
help you request the right permissions from your administrator.
 Service administrator
if an AWS resource at your company, you probably have full access to IAM.
It's your job to determine which IAM features and resources your service users should
access. You must then submit requests to your IAM administrator to change the
permissions of your service users. Review the information on this page to understand the
basic concepts of IAM.

 IAM administrator
If you're an IAM administrator, you manage IAM identities and write
policies to manage access to IAM.

Roles/Temporary Security Tokens

1. Roles and temporary security tokens are very important for
advanced IAM usage, but many AWS users find them confusing.

2. Roles are used to grant specific privileges to specific actors for a set
duration of time.

3. These actors can be authenticated by AWS or some trusted external

system.

4. When one of these actors assumes a role, AWS provides the actor
with a temporary security token from the AWS Security Token
Service (STS) that the actor can use to access AWS Cloud services.

5. Requesting a temporary security token requires specifying how long

the token will exist before it expires. The range of a temporary
security token lifetime is 15 minutes to 36 hours.

6. Roles and temporary security tokens enable a number of use cases:

 Amazon EC2 Roles—Granting permissions to applications

running on an Amazon EC2 instance.

 Cross-Account Access—Granting permissions to users from

other AWS accounts, whether you control those accounts or
not.

 Federation—Granting permissions to users authenticated by a

trusted external system

Authentication:
There are three ways that IAM authenticates a principal:
 User Name/Password—
 When a principal represents a human interacting with the
console, the human will provide a user name/password pair to
verify their identity. IAM allows you to create a password policy
enforcing password complexity and expiration.

 Access Key—An access key is a combination of an access key ID

(20 characters) and an access secret key (40 characters). When
a program is manipulating the AWS infrastructure via the API, it
will use these values to sign the underlying REST calls to the
services. The AWS SDKs and tools handle all the intricacies of
signing the REST calls, so using an access key will almost always
be a matter of providing the values to the SDK or tool.

 Access Key/Session Token—When a process operates under an

assumed role, the temporary security token provides an access
key for authentication. In addition to the access key (remember
that it consists of two parts), the token also includes a session
token. Calls to AWS must include both the two-part access key
and the session token to authenticate. It is important to note
that when an IAM user is created, it has neither an access key
nor a password, and the IAM administrator can set up either or
both. This adds an extra layer of security in that console users
cannot use their credentials to run a program that accesses
your AWS infrastructure.

Authorization

After IAM has authenticated a principal, it must then manage

the access of that principal to protect your AWS infrastructure.
The process of specifying exactly what actions a principal can
and cannot perform is called authorization. Authorization is
handled in IAM by defining specific privileges in policies and
associating those policies with principals.
Policies:
Understanding how access management works under IAM
begins with understanding policies. A policy is a JSON
document that fully defines a set of permissions to access and
manipulate AWS resources. Policy documents contain one or
more permissions, with each permission defining:
Effect—A single word: Allow or Deny.

Service—For what service does this permission apply? Most

AWS Cloud services support granting access through IAM,
including IAM itself.

Resource—The resource value specifies the specific AWS

infrastructure for which this permission applies. This is
specified as an Amazon Resource Name (ARN). The format for
an ARN varies slightly between services, but the basic format
is: "arn:aws:service:region:account-id:[resourcetype:]resource"

Action—The action value specifies the subset of actions within

a service that the permission allows or denies. For instance, a
permission may grant access to any readbased action for
Amazon S3. A set of actions can be specified with an
enumerated list or by using wildcards (Read*).

Condition—The condition value optionally defines one or

more additional restrictions that limit the actions allowed by
the permission. For instance, the permission might contain a
condition that limits the ability to access a resource to calls
that come from a specific IP address range. Another condition
could restrict the permission only to apply during a specific
time interval.
Associating Policies with Principals
There are several ways to associate a policy with an IAM user;
this section will only cover the most common.

A policy can be associated directly with an IAM user in one of

two ways:
User Policy—These policies exist only in the context of the user
to which they are attached. In the console, a user policy is
entered into the user interface on the IAM user page.

Managed Policies—These policies are created in the Policies

tab on the IAM page (or through the CLI, and so forth) and
exist independently of any individual user. In this way, the
same policy can be associated with many users or groups of
users. There are a large number of predefined managed
policies that you can review on the Policies tab of the IAM page
in the AWS Management Console much simpler management
process than having to review what policies a new IAM user for
the operations team should receive and manually adding those
policies to the user.

There are two ways a policy can be associated with

an IAM group:

Group Policy—These policies exist only in the context of the

group to which they are attached. In the AWS Management
Console, a group policy is entered into the user interface on
the IAM Group.

Managed Policies—In the same way that managed policies

(discussed in the “Authorization” section) can be associated
with IAM users, they can also be associated with IAM groups.