

# IAM ロールに切り替える (AWS CLI)
<a name="id_roles_use_switch-role-cli"></a>

*ロール*は、必要な AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。その点では、[AWS Identity and Access Management（IAM）のユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)に似ています。ユーザーとしてサインインすると、特定の一連のアクセス許可が付与されます。ただし、ロールにはサインインされませんが、ユーザーとしてサインインした後でロールを切り替えることができます。こうすると、元のユーザーアクセス権限が一時的に無効になり、そのロールに割り当てられたアクセス権限が代わりに付与されます。ロールは、自身のアカウントのロールでも、他の AWS アカウント のロールでもかまいません。ロールとその利点、およびロールを作成して設定する方法については、「[IAM ロール](id_roles.md)」および「[IAM ロールの作成](id_roles_create.md)」を参照してください。ロールを引き受ける別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。

**重要**  
IAM ユーザーのアクセス許可および引き受けるロールは、累積されません。同時に有効になるアクセス権限のセットは 1 つのみです。ロールを引き受けると、以前のユーザーまたはロールのアクセス許可が一時的に無効になり、切り替え後のロールに割り当てられたアクセス許可が有効になります。そのロールを終了すると、ユーザーアクセス権限が自動的に復元されます。

IAM ユーザーとしてサインインしている場合、ロールを使用して AWS CLI コマンドを実行できます。また、[外部で認証されたユーザー](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) または [OIDC](id_roles_providers_oidc.md)) としてサインインしている場合にも、ロールを使用して AWS CLI コマンドを実行できます。また、インスタンスプロファイルを経由して、ロールにアタッチされた Amazon EC2 インスタンス内部から AWS CLI コマンドを実行するロールを使用できます。AWS アカウントのルートユーザー としてサインインしているときに、ロールを引き受けることはできません。

[**ロールの連鎖**](id_roles.md#iam-term-role-chaining) — ロールの連鎖を使用することもできます。この連鎖は、ロールのアクセス許可を使用して 2 つ目のロールにアクセス許可を使用します。

デフォルトでは、ロールセッションは 1 時間です。`assume-role*` CLI オペレーションを使用してこのロールを引き受ける場合は、`duration-seconds` パラメータの値を指定できます。この値は 900 秒 (15 分) からロールの最大セッション期間設定までの範囲を指定できます。コンソールでロールを変更した場合、セッションの所要時間は最大 1 時間に制限されます。ロールの最大値を確認する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。

ロールの連鎖を使用すると、セッション期間は最長である 1 時間に制限されます。この場合 `duration-seconds` パラメータを使用して 1 時間より大きい値を指定すると、オペレーションは失敗します。

## シナリオ例: 本稼働ロールに切り替える
<a name="switch-role-cli-scenario-prod-env"></a>

開発環境で作業している IAM ユーザーであるとします。このシナリオでは、[AWS CLI](https://aws.amazon.com/cli/) でコマンドラインを使用して実稼働環境を操作する必要が生じることがあります。1 つのアクセスキー認証情報のセットがすでに使用可能です。このセットは、標準の IAM ユーザーに割り当てられたアクセスキーペアである場合があります。または、SAML または OIDC のフェデレーティッドプリンシパルとしてサインインしている場合、ユーザーに最初に割り当てられたロールのアクセスキーペアである場合があります。現在のアクセス許可で特定の IAM ロールを引き受けることができるなら、AWS CLI 設定ファイルの「プロファイル」でそのロールを特定できます。このコマンドは、元のアイデンティティではなく、指定された IAM ロールのアクセス権限を使用して実行されます。このプロファイルを AWS CLI コマンドで指定すると、新しいロールを使用することになります。この場合、開発用アカウントの元のアクセス許可を同時に使用することはできません。同時に有効にできるアクセス許可のセットは 1 つのみであるためです。

**注記**  
セキュリティ上の理由から、管理者は [AWS CloudTrail ログを確認](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)して、AWS でアクションを実行したユーザーを調べることができます。管理者は、ロールを引き受けるときに、ソース ID またはロールセッション名の指定を要求する場合があります。詳細については、「[`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)」および「[`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)」を参照してください。

**本稼働ロールに切り替えるには (AWS CLI)**

1. <a name="step-configure-default"></a>AWS CLI をはじめて使用する場合は、まず、デフォルトの CLI プロファイルを設定する必要があります。コマンドプロンプトを開き、IAM ユーザーまたはフェデレーティッドロールからのアクセスキーを使用するように、AWS CLI を設定します。詳細については、「[AWS Command Line Interface ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration)」の「*AWS Command Line Interface の設定*。」を参照してください。

   以下のように、[aws configure](https://docs.aws.amazon.com/cli/latest/reference/configure/) コマンドを実行します。

   ```
   aws configure
   ```

   プロンプトが表示されたら、次の情報を入力します。

   ```
   AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
   AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   Default region name [None]: us-east-2
   Default output format [None]: json
   ```

1. Unix または Linux の `.aws/config` ファイル、または Windows の `C:\Users\USERNAME\.aws\config` ファイルに、ロールの新しいプロファイルを作成します。次の例では、`123456789012` アカウントの `ProductionAccessRole` ロールへの切り替えをする「`prodaccess`」というプロファイルを作成します。ロール ARN は、ロールを作成したアカウント管理者から入手します。このプロファイルが呼び出されると、AWS CLI は `source_profile` の認証情報を使用してロールのための認証情報をリクエストします。そのため、`source_profile` として参照されるアイデンティティは、`role_arn` で指定されたロールの `sts:AssumeRole` アクセス権限がなければなりません。

   ```
   [profile prodaccess]
       role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
       source_profile = default
   ```

1. 新しいプロファイルを作成した後、AWS CLI パラメータを指定した `--profile prodaccess` コマンドは、デフォルトのユーザーではなく、IAM ロールである `ProductionAccessRole` にアタッチされたアクセス権限により実行されます。

   ```
   aws iam list-users --profile prodaccess
   ```

   このコマンドが機能するのは、`ProductionAccessRole` に割り当てられたアクセス許可の下で現在の AWS アカウントのユーザーを一覧表示できる場合です。

1. 元の認証情報によって付与されるアクセス許可に戻すには、`--profile` パラメータなしでコマンドを実行します。AWS CLI は、「[Step 1](#step-configure-default)」で設定したデフォルトのプロファイルの認証情報の使用に戻ります。

詳細については、*AWS Command Line Interface ユーザーガイド*の「[ロールを引き受ける](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html)」を参照してください。

## シナリオ例: インスタンスプロファイルロールが他のアカウントのロールに切り替えることを許可する
<a name="switch-role-cli-scenario-ec2-instance"></a>

2 つの AWS アカウント を使用していて、Amazon EC2 インスタンスで実行されているアプリケーションが両方のアカウントで [AWS CLI](https://aws.amazon.com/cli/) コマンドを実行できるようにするとします。アカウント `111111111111` に EC2 インスタンスが存在すると仮定します。このインスタンスには、同じ `abcd` アカウント内の Amazon S3 バケットで読み取り専用の `amzn-s3-demo-bucket1` タスクをアプリケーションが実行する `111111111111` インスタンスプロファイルのロールが含まれています。ただし、アプリケーションは、アカウント `222222222222` でタスクを実行するために `efgh` クロスアカウントロールを引き受けることも許可されている必要があります。これを行うには、`abcd` EC2 インスタンスプロファイルのロールは次のアクセス許可ポリシーを持っている必要があります。

***アカウント 111111111111 `abcd` ロールのアクセス許可ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1/*",
                "arn:aws:s3:::amzn-s3-demo-bucket1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}
```

------

`efgh` クロスアカウントのロールが、同じ `amzn-s3-demo-bucket2` アカウント内の `222222222222` バケットで読み取り専用 Amazon S3 タスクを許可すると仮定します。これを行うには、`efgh` クロスアカウントのロールは、以下のアクセス許可ポリシーを持っている必要があります。

***アカウント 222222222222 `efgh` ロールのアクセス許可ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket2/*",
                "arn:aws:s3:::amzn-s3-demo-bucket2"
            ]
        }
    ]
}
```

------

`efgh` ロールは `abcd` インスタンスプロファイルのロールがそれを引き受けることを許可する必要があります。これを行うには、`efgh` ロールは次の信頼ポリシーを持っている必要があります。

***アカウント 222222222222 `efgh` ロールの信頼ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}
```

------

次にアカウント `222222222222` で AWS CLI コマンドを実行するには、CLI 設定ファイルを更新する必要があります。AWS CLI 設定ファイルで、`efgh` ロールを「プロファイル」として、`abcd` EC2 インスタンスプロファイルロールを「認証情報ソース」として識別します。次に、元の `abcd` ロールではなく、`efgh` ロールのアクセス許可で CLI コマンドが実行されます。

**注記**  
セキュリティ上の目的で、AWS CloudTrail を使用して、アカウントのロールの使用を監査することができます。CloudTrail ログで異なるプリンシパルのロールが使用されている場合にロールセッションを区別するには、ロールセッション名を使用できます。このトピックで説明しているように、AWS CLI がユーザーに代わってロールを引き受けると、ロールセッション名が自動的に `AWS-CLI-session-nnnnnnnn` の形式で作成されます。ここでは *nnnnnnnn* は [Unix エポック時刻](http://wikipedia.org/wiki/Unix_time) (1970 年 1 月 1 日午前 0 時 UTC からの秒数) 形式の時刻を表す整数です。詳細については、[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) の「*CloudTrail イベントリファレンス*」を参照してください。

**EC2 インスタンスプロファイルのロールをクロスアカウントのロール (AWS CLI) に切り替えることができるようにするには**

1. デフォルトの CLI プロファイルを設定する必要はありません。代わりに、EC2 インスタンスプロファイルのメタデータから認証情報を読み込むことができます。ロールの新しいプロファイルを `.aws/config` ファイルに作成します。次の例では、`222222222222` アカウントのロール `efgh` に切り替える `instancecrossaccount` プロファイルを作成します。このプロファイルが呼び出されると、AWS CLI は EC2 インスタンスプロファイルのメタデータの認証情報を使用してロールの認証情報をリクエストします。そのため、EC2 インスタンスプロファイルのロールには、`role_arn` で指定されたロールに対する `sts:AssumeRole` アクセス許可が必要です。

   ```
   [profile instancecrossaccount]
   role_arn = arn:aws:iam::222222222222:role/efgh
   credential_source = Ec2InstanceMetadata
   ```

1. 新しいプロファイルを作成した後、パラメータ `--profile instancecrossaccount` を指定する すべての AWS CLI コマンドは、アカウント `222222222222` の `efgh` ロールにアタッチされたアクセス許可で実行されます。

   ```
   aws s3 ls amzn-s3-demo-bucket2 --profile instancecrossaccount
   ```

   このコマンドは、`efgh` ロールに割り当てられたアクセス許可で現在の AWS アカウント のユーザーを一覧表示できる場合に実行されます。

1. アカウント `111111111111` の元の EC2 インスタンスプロファイルのアクセス許可に戻るには、`--profile` パラメータなしで CLI コマンドを実行します。

詳細については、*AWS Command Line Interface ユーザーガイド*の「[ロールを引き受ける](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html)」を参照してください。