AWS-IAM Beginner perfect guide

atsushi, sada — Sat, 18 Jan 2025 14:02:42 +0000

Authentication and Authorization

In many cases, authentication and authorization are performed simultaneously, but they are fundamentally different concepts. Keeping this distinction in mind can make them easier to understand.

Authentication
- Verification of identity
- Example
  - A server determines who is accessing it by validating an ID/password combination.
Authorization
- Granting access rights
- Example
  - Granting a user permission to access an S3 bucket.

term

These documents include explanations of basic terms and concepts.

IAM Resources

The user, group, role, policy, and identity provider objects that are stored in IAM. As with other AWS services, you can add, edit, and remove resources from IAM.

IAM Identities
- IAM user / IAM group / IAM role

The IAM resource objects that are used to identify and group. You can attach a policy to an IAM identity. These include users, groups, and roles.

IAM Entities
- IAM resources used for authentication
- IAM user & IAM role

The IAM resource objects that AWS uses for authentication. These include IAM users and roles.

Principals
- The individuals or applications that use AWS services through IAM resources such as IAM users or IAM roles.

A person or application that uses the AWS account root user, an IAM user, or an IAM role to sign in and make requests to AWS. Principals include federated users and assumed roles.

A principal is a person or application that can make a request for an action or operation on an AWS resource. The principal is authenticated as the AWS account root user or an IAM entity to make requests to AWS.As a best practice, do not use your root user credentials for your daily work. Instead, create IAM entities (users and roles). You can also support federated users or programmatic access to allow an application to access your AWS account.

Others

Federated User

- "Federation" refers to user authentication integration between services.

- It can also be described as "establishing a trust relationship between an external ID provider (e.g., Amazon, Facebook, Google, GitHub, etc.) and AWS."

    - Any Identity Provider (IdP) compatible with OIDC (OpenID Connect) or SAML 2.0 (Security Assertion Markup Language) can be used.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html

Request

When a principal attempts to use the Management Console, API, or CLI, a request consisting of the following information is sent to AWS:

Actions or operations: The actions in the Management Console or operations in the CLI/API that the principal wants to perform.
Resources: The AWS resource objects that are the targets of the action/operation.
Principal: Information about the entity (user or application) sending the request. This includes policy information associated with the entity used by the principal.
Environment data: Information such as IP address, user agent, SSL status, and timestamp.
Resource data: Data related to the requested resource.

This information is sent to AWS as the request context and is used for authentication and authorization.

Authentication

To send a request to AWS, the principal must be authenticated using credentials.

There are several ways to authenticate:

Authenticating as the root user via the console: using the email address and password.
Authenticating as an IAM user via the console: using the account ID (or alias), username, and password.
Authenticating via API or CLI: using the access key and secret key.

Using MFA (Multi-Factor Authentication) enhances the security of authentication.

Authorization

Assume Role: Temporarily assuming a role to gain specific permissions.
Pass Role: Allowing an entity to pass a role to another AWS service.

ID - Identity

type of identity

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html

IAM resources used for authentication include the following

AWS account root user
IAM users
IAM user groups
IAM roles
Temporary credentials in IAM
- Issued by STS (Security Token Service)
- See the STS section for details.

AWS account root user

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html

When you create an Amazon Web Services (AWS) account for the first time, you start with a single identity that has full access to all AWS services and resources in the account. This identity is called the root user of the AWS account. You can sign in as the root user using the email address and password you provided when creating the account.

It is strongly recommended not to use the root user for everyday tasks, even for administrative tasks. Instead, follow the best practice of using the root user only to create the initial IAM user.

IAM users

An AWS Identity and Access Management (IAM) user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. A user in AWS consists of a name and credentials.
...
An IAM user is a resource in IAM that has associated credentials and permissions. An IAM user can represent a person or an application that uses its credentials to make AWS requests. This is typically referred to as a service account.
If you choose to use the long-term credentials of an IAM user in your application, do not embed access keys directly into your application code. The AWS SDKs and the AWS Command Line Interface allow you to put access keys in known locations so that you do not have to keep them in code.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html

An entity representing a user or application that uses AWS, consisting of a name and authentication credentials (console password, access keys).

There are several authentication methods for accessing AWS using an IAM user:

Console password Used to sign in to interactive sessions such as the Management Console.
ID/password Used when signing in to the Management Console.
Access key ID / secret access key Used by programs and command-line tools.

To enhance authentication security, you can also configure MFA (multi-factor authentication).

IAM roles

An IAM Identity with specific permissions that can be created in an AWS account. While it is similar to an IAM user in terms of being an AWS resource for authentication, it differs in several ways:

IAM users are generally intended for use by a specific individual, while IAM roles can be configured to be used by any person who requires them.
IAM users authenticate using long-term credentials (passwords and access keys), while IAM roles authenticate using temporary credentials.

Other points:

"Assume role" implies the concept of "taking on a role."

Roles terms and concepts

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts

Trust Policy Defines who or what can assume (take on) a role. In Terraform, this is represented by aws_iam_role.assume_role_policy.

In the console, it can be viewed under the "Trust relationships" tab.

Permission Policy

Policies attached as identity-based policies.

These define what actions are allowed or denied for a particular entity.
Principal

An entity in AWS that can perform actions or access resources.

Examples: AWS account root user, IAM user, IAM role.

Pass Role

To use many AWS services, you need to pass an IAM role to those services. For example, to use services like EC2 instances, Lambda functions, ECS, Batch, etc., you must configure the IAM role that these services will use.

Policy Template for Setting PassRole

The policy specifies "which IAM role" can be "passed to which service/resource."

{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::account-id:role/EC2-roles-for-XYZ",
    "Condition": {
        "StringEquals": {"iam:PassedToService": "ec2.amazonaws.com"},
        "StringLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:ec2:us-east-1:111122223333:instance/*",
                "arn:aws:ec2:us-west-1:111122223333:instance/*"
            ]
        }
    }
}

Why does AmazonEC2FullAccess not include iam:PassRole?

Allowing full access to EC2 instances, along with the ability to assign roles to instances via PassRole, could lead to privilege escalation. By assigning a powerful role to an instance and utilizing that role, users could potentially elevate their permissions.

For this reason, permissions for using services like EC2 and permissions for passing roles to those services (iam:PassRole) are separated.

Example

IAM user user_a needs the following setup to use an EC2 instance:

Create the IAM role EC2-roles-for-XYZ that the EC2 instance will use. Attach the necessary IAM policy to this role:

   {
       "Version": "2012-10-17",
       "Statement": {
           "Effect": "Allow",
           "Action": [ "A list of the permissions the role is allowed to use" ],
           "Resource": [ "A list of the resources the role is allowed to access" ]
       }
   }

Set up the trust relationship for the EC2 service to assume the attached role:

   {
       "Version": "2012-10-17",
       "Statement": {
           "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole",
           "Effect": "Allow",
           "Principal": { "Service": "ec2.amazonaws.com" },
           "Action": "sts:AssumeRole"
       }
   }

Attach the following policy to allow IAM user user_a to pass the role:

   {
       "Version": "2012-10-17",
       "Statement": [{
           "Effect": "Allow",
           "Action": [
               "iam:GetRole",
               "iam:PassRole"
           ],
           "Resource": "arn:aws:iam::account-id:role/EC2-roles-for-XYZ"
       }]
   }

With this configuration, user_a can use the EC2 instance with the EC2-roles-for-XYZ role.

IAM: Pass an IAM role to a specific AWS service - AWS Identity and Access Management

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html

Grant a user permissions to pass a role to an AWS service - AWS Identity and Access Management

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html

instance profile

To grant access permissions to applications running on an EC2 instance using a role, a little additional configuration is required. Applications running on the EC2 instance are abstracted from AWS by the virtualized operating system. Due to this additional separation, a separate step is necessary to assign AWS roles and their associated permissions to the EC2 instance and allow the application to use them. This separate step involves creating an instance profile that is attached to the instance.

An instance profile contains a role and provides temporary credentials for the role to the application running on the instance. These temporary credentials can be used in the application's API calls to grant access to resources or to restrict access to only the resources specified in the role. Only one role can be assigned to an EC2 instance at a time. All applications on the instance will share the same role and permissions.

Use an IAM role to grant permissions to applications running on Amazon EC2 instances - AWS Identity and Access Management

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

aws_iam_instance_profile | Resources | hashicorp/aws | Terraform | Terraform Registry

The confused deputy problem

Point

There is a well-known security issue called the "confused deputy problem." When using third-party services based on AWS, if you configure your IAM Role in your AWS account with the entire AWS account of the third party as the Principal, anyone from the third party’s account could end up being able to use your IAM Role. This problem highlights the need for identifying users of third-party services.

External ID is crucial as a countermeasure to this problem.

An example of a third-party service is Snowflake.

AWS does not treat the external ID as sensitive information.

The external ID is used to identify third-party users and is managed by the third-party service in such a way that it remains unique for each user. Therefore, the external ID is not considered confidential, much like a username for third-party service users.

STS - Security Token Service

STS Basics

STS is an auxiliary service to IAM that creates and provides temporary security credentials (temporary credentials).

While temporary credentials function similarly to the long-term credentials (access keys) that IAM users use, there are key differences:

As the name suggests, temporary credentials have a short lifetime, typically ranging from a few minutes to a few hours. Once the expiration time passes, AWS will no longer authenticate them.
Temporary credentials are not stored with the user but are dynamically generated and provided in response to the user's request.

The advantages of using temporary credentials are as follows:

There is no need to embed credentials in applications, and because their lifetime is limited, there is no need to rotate or delete them when they are no longer needed. For example, there will be no need to rotate or delete credentials when an employee leaves the company.
It enables access to AWS resources without needing to create IAM identities for users.
IAM roles and ID Federation rely on these temporary credentials to function.

The following blogs are very educational

Re-introduction to AWS IAM

GetFederationToken, AssumeRole, GetSessionToken

STS Actions:

STS Actions Documentation

AssumeRole
AssumeRoleWithWebIdentity
GetSessionToken When MFA is enabled for an IAM user, this action returns temporary credentials after successfully authenticating with an MFA device. By properly using these temporary credentials, you can reduce the number of times the MFA device needs to be authenticated.

Policy

A policy is used to manage authorizations for IAM identities (User/Group/Role). It expresses various permissions from three perspectives: "Action (which services)", "Resource (what functionality or scope)", and "Effect (Allow/Block)".

For more details on policies, it is recommended to first read the IAM Policies and Permissions documentation.

Types of Policy

Here are the types of IAM policies, classified in order of usage frequency:

Identity-based policies

These are policies that are attached to IAM users, groups, or roles. They control and restrict what actions the associated IAM identity can perform.

There are three types of identity-based policies:
- AWS Managed Policies
- Customer Managed Policies
- Inline Policies
Resource-based policies

These policies grant permission to specific principals to perform actions on the attached resources and define the conditions under which these permissions apply.

Resource-based policies are often used for cross-account access.

Two major examples are:
- S3 Bucket Policy This can be configured using resources like aws_s3_bucket_policy in Terraform.
- IAM Role Trust Policy (Trust policy, assume_role_policy) This can be configured using resources like aws_iam_role in Terraform.

Rules of JSON Policy Document

For detailed information, refer to the IAM JSON Policy Elements Reference.

The top-level elements that can be specified in a policy document are:

Version

You can specify either 2012-10-17 or 2008-10-17, but the former is typically used.
Statement

This is the body of the policy. Multiple statements can be written in the form "Statement": [{...},{...},{...}].

Within each statement, you can include the following components:

Sid (Statement ID)

An optional identifier for the statement.
Effect

Specifies whether the action is allowed or denied. It can be Allow or Deny.
Action

Specifies the AWS service operation (API) that is allowed or denied, such as "Action": "s3:GetObject".

You can refer to various API references to see available actions.

Example: S3 API Reference.
Resource

Specifies the ARN of the resources that the action applies to.

You can check the details of ARNs at IAM ARN Reference.
Condition

Describes the conditions that must be met for the policy to execute.

Examples include IP address restrictions, or using repository information from GitHub actions.

You can use conditions like ForAllValues or ForAnyValue to apply conditions to multiple keys or values.
Principal

This is required for resource-based policies.

The Principal is the IAM entity (such as IAM user or role) that can perform actions or access resources.

In IAM role trust policies, the Principal element specifies who can assume the role.

In resource-based policies, the Principal element specifies who can access the resource.

ID-based Policy

An ID-based policy is a JSON document used to control the actions, resources, and conditions that an identity (such as a user, group, or role) can perform.

There are three types of ID-based policies:

AWS Managed Policy
Customer Managed Policy
Inline Policy

You can find more details about these types of policies in the AWS documentation: Managed vs Inline Policies.

AWS Managed Policy

These are policies created and managed by AWS.
A Standalone policy is a policy that exists as an independent AWS resource with an ARN (for example: arn:aws:iam::aws:policy/IAMReadOnlyAccess).
AWS Managed Policies can be searched for in the IAM Policies section, and they are usually accompanied by an icon next to the policy name to denote that they are managed by AWS.

Customer Managed Policy
A Customer Managed Policy is a standalone policy that can be created and managed within an account. Like AWS Managed Policies, it has an ARN and can be searched for in the IAM Policies section.

For Terraform, the following resources are used:

Resource: aws_iam_policy - This is used to create Managed Policies.
Resource: aws_iam_role_policy_attachment - This is used to attach a Managed Policy to an IAM role.
Resource: aws_iam_policy_attachment - This is used to attach a Managed Policy to an IAM role, user, or group.

Inline Policy
An Inline Policy is a policy embedded within an IAM identity (such as a user, group, or role). Unlike Managed Policies, it does not have an ARN. While a Customer Managed Policy is linked to a policy page, an Inline Policy is embedded directly within the IAM identity, so there is no link to a separate policy page.

For more information on this, see the AWS documentation on Customer Managed Policies and Inline Policies.

Managed vs. Inline
When choosing between Managed and Inline policies, the decision largely depends on whether you want to reuse a policy or have a policy specific to a single identity.

Managed Policies: These are standalone policies that can be created and managed independently of the IAM identity to which they are attached. They can be used across multiple IAM identities and are reusable.
Inline Policies: These are embedded directly within a specific IAM identity (user, group, or role). They are used for more specific or fine-grained permissions that are not shared across multiple identities.

For more details, refer to the AWS Documentation.

Resource-Based Policies

Resource-based policies are critical when granting access to resources, especially in cross-account scenarios. For example, when setting up access to an S3 bucket or IAM role, you may need to define who can access those resources using resource-based policies.

When implementing cross-account access:

The IAM identity in Account A (the "principal") needs an identity-based policy that grants access to resources in Account B.
The resource in Account B (such as an S3 bucket or IAM role) needs a resource-based policy that allows access from Account A.

In this case, the resource-based policy explicitly defines the permissions for accessing the resource.

For more information on how to evaluate policies, visit the following documentation:

For more on specific use cases such as restricting access to only certain IAM roles or enforcing session names, refer to the articles on DevelopersIO: