iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🔐

AWS IAM Notes

に公開
AWS
IAM
tech

AWS IAM Notes

Please also check out the following materials:
https://speakerdeck.com/kevinrobot34/introduction-aws-iam-3a810adc-5172-4460-9721-0041456eb2bf

Authentication and Authorization

In many cases, authentication and authorization are performed at the same time, but they are fundamentally different. Keeping this distinction in mind makes things much clearer.

  • Authentication
    • Verification of identity
    • Specific example
      • The server determines who is accessing it using an ID/Password combination.
  • Authorization
    • Granting of access permissions
    • Specific example
      • Granting a user permission to browse an S3 bucket.

The flow is roughly: authenticate as an IAM user, etc., and then authorize by attaching the appropriate IAM Policy(?)

Reading Docs - How IAM Works is recommended.
DevelopersIO - Easy-to-understand Authentication and Authorization is also very educational.

Terminology

Grouping of IAM Resources

AWS Re-introduction Blog Relay 2022 AWS IAM Edition (Japanese) is a helpful reference.

  • 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

    • 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 user / IAM group / IAM role
  • IAM Entities

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

    • IAM resources used for authentication.
    • IAM user and IAM role.
  • Principals

    • 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.

    • Refers to a person or application that uses IAM resources, such as IAM users and IAM roles, to access various AWS services.

Others

  • Federated User
    • "Federation" refers to user authentication linkage between services.
      • It can also be described as "creating a trust relationship between an external Identity Provider (Amazon/Facebook/Google/GitHub/etc.) and AWS."
      • Any Identity Provider (IdP) compatible with OIDC (OpenID Connect) or SAML 2.0 (Security Assertion Markup Language) is supported.
    • Docs - Identity Providers and Federation
    • Related terms:
      • OpenID Connect (OIDC)
      • SAML 2.0 (Security Assertion Markup Language)

    • A federation is a group of computing or network providers agreeing upon standards of operation in a collective fashion.
      https://en.wikipedia.org/wiki/Federation_(information_technology)
      A federated identity in information technology is the means of linking a person’s electronic identity and attributes, stored across multiple distinct identity management systems.
      https://en.wikipedia.org/wiki/Federated_identity

  • Request
    • When a Principal attempts to use the Management Console, API, or CLI, they send a Request to AWS consisting of the following information:
      • Actions or operations - The action on the Management Console or the CLI/API operation the Principal wants to execute.
      • Resources - The AWS resource objects that are the targets of the action/operation.
      • Principal - Information about the entity used by the person or application sending the request. This includes policy information associated with the entity the principal is using.
      • Environment data - IP address, user agent, SSL status, date and time.
      • Resource data - Data regarding the requested resource.
    • The above information is sent to AWS as a request context and used for authentication and authorization.
  • Authentication
    • To send a request to AWS, a principal must be authenticated using credentials.
    • There are several ways to authenticate:
      • Authenticate as the root user from the console: Email address and password.
      • Authenticate as an IAM User from the console: Account ID (or Alias), username, and password.
      • Authenticate via API or CLI: Access key and secret key.
    • Using MFA (Multi-Factor Authentication) increases security in authentication.
  • Authorization
  • Assume Role
  • Pass Role

ID - Identity

type of identity

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

IAM resources used for authentication. These include:

  • AWS account root user
  • IAM users
  • IAM user groups
  • IAM roles
  • Temporary credentials in IAM
    • Issued via STS
    • For details, refer to the STS section

AWS account root user

When you first create an Amazon Web Services (AWS) account, you begin with one sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user. You can sign in as the root user by using the email address and password that you used to create the account.
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_root-user.html

  • We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user.

  • The ARN is in the format arn:aws:iam::123456789012:root.

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 credentials (console password, access keys).

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

  • Console Password
    • Used when signing in to interactive sessions such as the Management Console.
    • ID / password.
    • This is used for logging into the Management Console.
  • Access Key ID / Secret Access Key ID
    • Used by programs and the command line.

To strengthen authentication, you can also set up MFA (Multi-Factor Authentication).

IAM user groups

IAM roles

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

  • IAM users are generally intended for use by a specific individual, whereas IAM roles can be configured to be used by anyone who needs them.
  • IAM users authenticate using long-term credentials (passwords or access keys), while IAM roles use temporary credentials.

Other key points:

Assume Role

Refer to the STS section.

Pass Role

To use many AWS services, you must pass an IAM role to that service. For example, you need to configure the IAM roles used by services such as EC2 instances, Lambda functions, ECS, and Batch.

  • Policy template for setting up PassRole
    • Describes "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/*"
            ]
        }
    }
}
  • For example, why is iam:PassRole not included in AmazonEC2FullAccess?
    • If a user could freely launch EC2 instances and assign any role using PassRole, they could potentially escalate their privileges by assigning a powerful role to an instance and then using that instance.
    • From this perspective, the permissions to use service-specific functions (like EC2) and the permission to pass a role to that service (iam:PassRole) are kept separate.
  • Specific example
    • Configuration required for IAM user user_a to use an EC2 instance:
      • First, prepare the IAM role EC2-roles-for-XYZ to be used by the EC2 instance.
        • IAM policy to attach:
          {
    "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" ]
    }
}
        • The trust relationship to configure is as follows:
          {
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole",
        "Effect": "Allow",
        "Principal": { "Service": "ec2.amazonaws.com" },
        "Action": "sts:AssumeRole"
    }
}
      • Attach the following policy to IAM user user_a to allow PassRole:
        {
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "iam:GetRole",
            "iam:PassRole"
        ],
        "Resource": "arn:aws:iam::account-id:role/EC2-roles-for-XYZ"
    }]
}
      • Now user_a can use an EC2 instance with EC2-roles-for-XYZ associated.
  • references

instance profile

To grant permissions to applications running on EC2 instances using roles, some additional configuration is required. Applications running on an EC2 instance are abstracted from AWS by the virtualized operating system. Because of this additional isolation, an extra step is needed to assign the AWS role and its associated permissions to the EC2 instance and allow applications to use them. This extra step is the creation of an instance profile that is attached to the instance. An instance profile contains the role and can provide temporary credentials for the role to applications 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 only to those resources specified by the role. Only one role can be assigned to an EC2 instance at a time. All applications on the instance share the same role and permissions.
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

In Terraform, it can be created using aws_iam_instance_profile.

Qiita - Organizing Policies and Roles While Understanding Instance Profiles (Japanese)

IAM user vs IAM role

The contrast between IAM user and IAM role is similar to the contrast between long-term and temporary credentials. See also the section on STS.

Confused Deputy Problem and External ID

In English, it's "The confused deputy problem".

Points:

  • There is a well-known security issue called the "Confused Deputy Problem."
    • For example, when using a third-party service based on AWS, if you set the third-party's AWS account as the Principal in your IAM Role configuration, any user of that third-party service could potentially use your AWS account's IAM Role.
    • It essentially boils down to the need for identifying the user of the third-party service.
    • External ID is crucial as a countermeasure for this problem.
  • An example of a third-party service is Snowflake.
  • AWS does not treat the External ID as confidential information.
    • External IDs are used to identify third-party users, and it's important that the third-party service itself manages them so that they are unique for each user.
    • It's categorized similarly to a username for a third-party service, so it is not considered sensitive information in itself.

STS - Security Token Service

STS Basics

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

STS is a supplementary IAM service that creates and provides Temporary security credentials.

Temporary security credentials function almost identically to the long-term credentials (access keys) used by IAM users, but with the following differences:

  • As the name implies, temporary credentials have a short lifetime, ranging from a few minutes to several hours. Once they expire, AWS will no longer authenticate them.
  • Temporary credentials are not stored with the user; instead, they are dynamically generated and provided in response to a user's request.

Based on these differences, the benefits of using temporary credentials include:

  • You don't need to embed credentials in your application, and since their validity is limited, there is no need to rotate or delete them when they are no longer needed.
    • For example, you won't need to rotate or delete credentials when an employee leaves the company.
  • You can grant access to AWS resources to users without having to prepare an IAM Identity for them.
    • IAM roles and Identity Federation function based on these temporary credentials.

The following blogs are very helpful (in Japanese):

STS Actions

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

AssumeRole

AssumeRoleWithWebIdentity

GetSessionToken

Returns temporary security credentials that represent a successful authentication with an MFA device for an IAM user who has MFA enabled.
Using these temporary credentials appropriately can reduce the number of times you need to authenticate with an MFA device.

Policy

Used to manage authorization for IAM Identities (Users/Groups/Roles).
Expresses various permissions from three perspectives: "Action" (which service), "Resource" (what function or scope), and "Effect" (Allow/Deny).

For more information regarding policies, it is recommended to first read Docs - Policies and permissions in IAM.

type of policy

IAM Policies can be categorized by frequency of use as follows:

  • Identity-based policies
    • Policies attached to IAM users / groups / roles.
    • Used to control and restrict the actions those IAM Identities can perform.
    • There are three types: AWS Managed Policy / Customer Managed Policy / Inline Policy.
  • Resource-based policies
    • Used to grant permission to a specified principal to perform specific actions on the resource to which it is attached, while also defining the conditions under which these permissions apply.
    • Inline policies are attached to the resource.
    • As seen in the following examples, these are often used to allow cross-account access.
    • The two major types are:
  • [Never used] Permissions boundaries
  • Organizations SCPs
    • Short for Service Control Policy (Documents).
    • Typically contains organization-wide "Deny" rules, etc.
  • [Never used] ACL: Access Control Lists
  • [Never used] Session Policies

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_identity-vs-resource.html

Examples

Rules of JSON Policy Documents

For details, see the IAM JSON Policy Elements Reference.

At the top level, you can specify:

  • version
    • Can be 2012-10-17 or 2008-10-17, but generally you should explicitly use the former.
  • statement
    • The main part of the policy.
    • Multiple statements can be written in the format "Statement": [{...},{...},{...}].

Within a statement, you can include:

  • Sid (Statement ID)
  • Effect
    • Allow or Deny
  • Action
  • Resource
    • Specifies the resource that the action applies to using an ARN.
    • Details on ARNs can be found in IAM ARNs.
  • Condition
    • Describes conditions required for the policy to take effect.
    • Examples of conditions:
      • Restricting by IP address
      • Restricting using repository information coming from GitHub Actions
    • As explained in Creating a Condition with Multiple Keys or Values, you can target multiple values using ForAllValues or ForAnyValue.
  • Principal
    • This is required in resource-based policies.
    • A Principal is an IAM entity that can perform actions or access resources in AWS.
    • In an IAM role's trust policy, the Principal element specifies who is allowed to assume the role.
    • In a resource-based policy, the Principal element specifies who is allowed to access that resource.

Identity-Based Policies

Identity-based policies are JSON documents used to control the actions, resources, and conditions that an identity (user/group/role) can perform.
There are three types of identity-based policies:
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html

  • AWS Managed Policy
  • Customer Managed Policy
  • Inline Policy

AWS Managed Policy

  • A standalone policy created and managed by AWS.
    • A standalone policy is a policy that has its own ARN (e.g., arn:aws:iam::aws:policy/IAMReadOnlyAccess) as an AWS resource.
    • You can search for them on the Policies page in the IAM console; they have an AWS logo next to the policy name.
  • You cannot edit the contents of an AWS Managed Policy.
  • e.g., AmazonS3FullAccess

Customer Managed Policy

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies

Inline Policy

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies

  • Policies embedded directly into an IAM identity (user, group, or role).
  • They do not have their own ARN as a standalone policy.
  • While (Customer) Managed Policies have links to a policy page, inline policies are embedded in the IAM role itself, so there are no such links.
  • Notes regarding Terraform:

Managed vs. Inline

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline

Resource-based Policies

Policy Evaluation

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

Resource-based policies become particularly important during cross-account access (where a principal in one account accesses a resource in another account).
Document - Cross-account policy evaluation logic

For example, when IAM user iam_principal_a in Account A accesses a resource (IAM role / S3 Bucket / etc.) in Account B:

  • The principal iam_principal_a must be allowed access to Account B via an identity-based policy.
  • The target resource must allow access from Account A via a resource-based policy.

Settings are required on both sides: the side using the resource and the side being used.
In this way, resource-based policies explicitly define the permissions for the resource being accessed.

Within a single account

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-basics

Cross account

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html

Policy in Terraform

How to describe JSON policy documents

There are several ways to write policy descriptions:

  • Write it externally as a JSON file and load it using something like policy = file("./ddb-allow-policy.json").
    • This seems suitable for use as a template(?)
  • Use policy = jsonencode({...}) to wrap a JSON object directly written with jsonencode.
  • Write JSON directly in the .tf file using a heredoc (e.g., policy = <<EOT...).
  • Create and reference an iam_policy_document data source.
    • Apparently, it makes the plan diff harder to read.

DevelopersIO - 5 ways to write IAM Policies in Terraform (Japanese)

How to attach policies to roles

There are several ways to attach managed policies to an IAM role:

  1. Write the ARNs directly in the managed_policy_arns attribute of aws_iam_role.
  2. Use the aws_iam_policy_attachment resource.
  3. Use the aws_iam_role_policy_attachment resource.

Each method requires caution:

  • If using aws_iam_policy_attachment, all attachments for that policy must be described there.
  • Using aws_iam_policy_attachment and aws_iam_role_policy_attachment simultaneously will cause persistent diffs.
  • Using aws_iam_role's managed_policy_arns and aws_iam_role_policy_attachment simultaneously will cause persistent diffs.
  • Using aws_iam_role's managed_policy_arns and aws_iam_policy_attachment simultaneously will cause persistent diffs.

Organizations SCPs

  • Short for Service Control Policy (Documents)
  • Used to define organization-wide Deny rules, etc.

Access Analyzer

AWS SSO

Tips

Debugging aws-cli

It is helpful to debug while organizing the IAM you are using by employing the following commands.

Check current IAM information

get-caller-identity is a rare command that does not require any permissions and can be used even if an explicit deny is set. It is useful for debugging because you can check information such as the UserId, Account, and ARN as shown below.

$ aws sts get-caller-identity
{
    "UserId": "AIDASAMPLEUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevAdmin"
}

https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html

List of configs

You can list the configs being used as follows.

$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************3YE6      assume-role
secret_key     ****************a7UD      assume-role
    region           ap-northeast-1      config-file    ~/.aws/config

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-files.html

Configuration and Precedence

AWS credentials can be configured in several ways, and the order of precedence is determined as shown on the following page.
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-precedence

  1. command line option
  2. Environment variables
    • For details, see here; typical environment variables are as follows:
      • AWS_PROFILE: Specifies the profile name to use.
      • AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
      • AWS_CONFIG_FILE: The config file used by the CLI; the default is ~/.aws/config.
  3. CLI credentials
    • Default on Mac is ~/.aws/credentials.
  4. CLI configs
    • Default on Mac is ~/.aws/config.
  5. Container credentials
    • IAM roles associated with Amazon ECS task definitions.
  6. Amazon EC2 instance profile credentials

Named Profiles

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-profiles.html

Config file and credentials file

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

  • The aws configure command places sensitive information (aws_access_key_id / aws_secret_access_key / aws_session_token) in the credentials file and other information in the config file.
  • If an IAM role is specified in the config file, the AWS STS AssumeRole operation is called to obtain temporary credentials, which are then saved in ~/.aws/cli/cache. This allows the use of IAM Role permissions. When the credentials expire, the cache is deleted, and the credentials are automatically updated by the CLI.
  • Configuration variables that can be described for each profile in the config file:

Others

Accessing AWS using OIDC in GitHub Actions

https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services

By using OpenID Connect (OIDC), you no longer need to store credentials when accessing AWS resources from GitHub Actions.

Understanding unique ID prefixes

0 An AWS-Access-Key-ID always begins with AKIA for IAM users or ASIA for temporary credentials from Security Token Service, as noted in IAM Identifiers in the AWS Identity and Access Management User Guide.
0 https://stackoverflow.com/questions/58247672/how-to-fix-authorizationheadermalformed-when-calling-the-getobject-operation-e

0 Understanding unique ID prefixes
0 IAM uses the following prefixes to indicate what type of resource each unique ID applies to.
0 https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids

In IAM, the ID prefix for each resource is determined by its type.

Prefix Resource Type
AIDA IAM user
AROA Role
AKIA Access Key
ASIA Temporary access key IDs

Access Key IDs and the UserId obtained when performing get-caller-identity should follow these rules.

Deleting an IAM User

If you try to delete an IAM User haphazardly, you might see:

0 Cannot delete entity, must remove tokens from principal first.

This means you must delete the following items associated with the user before you can delete the IAM User:

  • MFA tokens
  • Management Console access
  • Access Keys

List of IAM ARNs

The ARNs for each resource are in the following format:

arn:aws:iam::account:root  
arn:aws:iam::account:user/user-name-with-path
arn:aws:iam::account:group/group-name-with-path
arn:aws:iam::account:role/role-name-with-path
arn:aws:iam::account:policy/policy-name-with-path
arn:aws:iam::account:instance-profile/instance-profile-name-with-path
arn:aws:sts::account:federated-user/user-name
arn:aws:sts::account:assumed-role/role-name/role-session-name
arn:aws:iam::account:mfa/virtual-device-name-with-path
arn:aws:iam::account:u2f/u2f-token-id
arn:aws:iam::account:server-certificate/certificate-name-with-path
arn:aws:iam::account:saml-provider/provider-name
arn:aws:iam::account:oidc-provider/provider-name

From https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_identifiers.html

Outputting Debug Logs

You can output debug logs as follows:

In [1]: import boto3, botocore
   ...: botocore.session.Session().set_debug_logger()  # This one
   ...: session = boto3.session.Session(profile_name='datahub-dev')
   ...: client = session.client('sts')
   ...: client.get_caller_identity()

...
2022-11-30 19:10:35,539 - botocore.utils - DEBUG - IMDS ENDPOINT: http://169.254.169.254/
2022-11-30 19:10:35,542 - botocore.credentials - DEBUG - Skipping environment variable credential check because profile name was explicitly set.
2022-11-30 19:10:35,542 - botocore.credentials - DEBUG - Looking for credentials via: assume-role
2022-11-30 19:10:35,542 - botocore.credentials - DEBUG - Looking for credentials via: assume-role-with-web-identity
2022-11-30 19:10:35,542 - botocore.credentials - DEBUG - Looking for credentials via: sso
2022-11-30 19:10:35,543 - botocore.credentials - DEBUG - Looking for credentials via: shared-credentials-file
2022-11-30 19:10:35,543 - botocore.credentials - INFO - Found credentials in shared credentials file: ~/.aws/credentials
...

Specifying Credentials and Config

https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html
https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html

References

GitHubで編集を提案

Discussion