

# AWS CLI での IAM ロールの使用
<a name="cli-configure-role"></a>

[AWS Identity and Access Management (IAM) ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)は、ユーザーが追加の (または異なる) アクセス許可を取得するか、または異なる AWS アカウントでアクションを実行するアクセス許可を取得するこをできる認可ツールです。

**Topics**
+ [前提条件](#cli-role-prereqs)
+ [IAM ロール使用の概要](#cli-role-overview)
+ [ロールの設定と使用](#cli-role-prepare)
+ [多要素認証を使用する](#cli-configure-role-mfa)
+ [クロスアカウントロールと外部 ID](#cli-configure-role-xaccount)
+ [監査を容易にするためのロールセッション名の指定](#cli-configure-role-session-name)
+ [ウェブ ID を使用したロールの継承](#cli-configure-role-oidc)
+ [キャッシュされた認証情報のクリア](#cli-configure-role-cache)

## 前提条件
<a name="cli-role-prereqs"></a>

これらの `iam` コマンドを使用するには、AWS CLI をインストールして設定する必要があります。これには、ロールが別の認証情報メソッドとペアになっていると仮定して設定されたプロファイルの設定が含まれます。詳細については、[AWS CLI の最新バージョンのインストールまたは更新](getting-started-install.md) を参照してください。

## IAM ロール使用の概要
<a name="cli-role-overview"></a>

IAM ロールを使用するように AWS Command Line Interface (AWS CLI) を設定するには、`~/.aws/config` ファイルでロールのプロファイルを定義します。

次の例は `marketingadmin` という名前のロールプロファイルを示しています。`--profile marketingadmin` を使用して (または [AWS\$1PROFILE 環境変数](cli-configure-envvars.md)でこれを指定して) コマンドを実行する場合、AWS CLI は個別のプロファイル `user1` で定義された認証情報を使用して Amazon リソースネーム (ARN) `arn:aws:iam::123456789012:role/marketingadminrole` のロールを引き受けます。このロールに割り当てられたアクセス権限で許可される任意のオペレーションを実行することができます。

```
[profile marketingadmin]
role_arn = arn:aws:iam::123456789012:role/marketingadminrole
source_profile = user1
```

その後、このロールを使用するアクセス許可があるユーザー認証情報を含む、別の名前付きプロファイルを示す `source_profile` を指定できます。前の例では、`marketingadmin` プロファイルは `user1` プロファイル内の認証情報を使用しています。AWS CLI コマンドがプロファイル `marketingadmin` を使用するように指定すると、AWS CLI はリンクされた `user1` プロファイルの認証情報を自動的に検索し、それらを使用して、指定された IAM ロールの一時的な認証情報をリクエストします。CLI では、バックグラウンドで [sts: AssumeRole ](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) オペレーションを使用してこれを実現します。これらの一時的な認証情報は次に、リクエストされた AWS CLI コマンドを実行するために使用されます。指定されたロールには、リクエストされた AWS CLI コマンドの実行を許可する IAM 許可ポリシーがアタッチされている必要があります。

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたは Amazon Elastic Container Service (Amazon ECS) コンテナ内から AWS CLI コマンドを実行するには、インスタンスプロファイルまたはコンテナにアタッチされた IAM ロールを使用できます。プロファイルを指定しない、または環境変数を設定しない場合、そのロールが直接使用されます。これにより、存続期間の長いアクセスキーをインスタンスで保存することを回避できます。これらのインスタンスまたはコンテナのロールは、別のロールの認証情報を取得するためにのみ使用できます。これを行うには、`credential_source` (`source_profile` の代わりに) を使用して、認証情報を検索する方法を指定します。`credential_source` 属性では、以下の値がサポートされます。
+ `Environment` - 環境変数からソース認証情報の取得。
+ `Ec2InstanceMetadata` - Amazon EC2 インスタンスプロファイルにアタッチされた IAM ロールの使用。
+ `EcsContainer` - Amazon ECS コンテナにアタッチされた IAM ロールの使用。

次の例は、Amazon EC2 インスタンスプロファイルを参照される場合に使われる同じ `marketingadminrole` ロールを示しています。

```
[profile marketingadmin]
role_arn = arn:aws:iam::123456789012:role/marketingadminrole
credential_source = Ec2InstanceMetadata
```

ロールを呼び出すとき、多要素認証や外部 ID (サードパーティー企業がクライアントのリソースにアクセスするために使用する) の使用などを必須とする追加オプションがあります。AWS CloudTrail ログでより簡単に監査できる一意のロールセッション名を指定することもできます。

## ロールの設定と使用
<a name="cli-role-prepare"></a>

IAM ロールを指定するプロファイルを使用してコマンドを実行すると、AWS CLI はソースプロファイルの認証情報を使用して AWS Security Token Service (AWS STS) を呼び出し、指定したロールの一時的な認証情報を要求します。ソースプロファイルのユーザーは、指定されたプロファイルのロール用の `sts:assume-role` を呼び出すアクセス許可を持っている必要があります。ロールには、ソースプロファイルのユーザーがこのロールを使用できる信頼関係が必要です。ロールの一時的な認証情報を取得して使用するプロセスを、一般に*ロールを引き受ける*と呼びます。

「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ユーザーにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」にある手順を実行することによって、ユーザーに引き受けさせたいアクセス許可を持つロールを IAM で作成できます。ロールとソースプロファイルの ユーザーが同じアカウントに存在する場合、ロールの信頼関係を設定するときに、独自のアカウント ID を入力することができます。

ロールを作成した後、 ユーザーが引き受けることを許可するように信頼関係を変更します。

次の例では、ロールにアタッチできる信頼ポリシーを示します。このポリシーは、アカウント「123456789012」の任意のユーザーがロールを引き受けることを許可します (そのアカウントの管理者が明示的にユーザーに「`sts:AssumeRole`」のアクセス許可を付与した**場合**)。

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

信頼ポリシーは、実際にはアクセス許可を付与しません。アカウントの管理者は、適切なアクセス許可を持つポリシーをアタッチすることによって、ロールを引き受けるアクセス許可を個々のユーザーに委任する必要があります。次の例では、ユーザーに付与を行い、ユーザーが `marketingadminrole` ロールのみを引き受けることを許可するポリシーを示しています。ロールを引き受けるためのユーザーアクセスの付与の詳細については、*IAM ユーザーガイド*の「[ロールを切り替えるためのユーザーアクセス許可の付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html)」を参照してください。

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/marketingadminrole"
    }
  ]
}
```

------

ユーザーには、ロールプロファイルを使用して AWS CLI コマンドを実行するための追加のアクセス許可は必要ありません。代わりに、コマンドを実行するためのアクセス権限は、*ロール*にアタッチされたアクセス権限によって提供されます。アクセス許可ポリシーをロールにアタッチして、どの AWS リソースに対してどのアクションを実行できるかを指定します。ロールへのアクセス許可のアタッチ (ユーザーと同じ機能) の詳細については、「IAM ユーザーガイド」の「[IAM ユーザーのアクセス許可の変更](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html)」を参照してください。

ロールプロファイル、ロールのアクセス許可、ロールの信頼関係およびユーザーアクセス許可が正しく設定されたので、コマンドラインで `--profile` オプションを呼び出してロールを使用できます。例えば、以下の例では、このトピックの冒頭で定義された`ls` ロールにアタッチされたアクセス権限を使用して Amazon S3 `marketingadmin` コマンドを呼び出します。

```
$ aws s3 ls --profile marketingadmin
```

いくつかの呼び出しにロールを使用するには、コマンドラインから、現在のセッションに対して `AWS_PROFILE` 環境変数を設定することができます。この環境変数が定義されている場合、各コマンドで `--profile` オプションを指定する必要はありません。

**Linux または macOS**

```
$ export AWS_PROFILE=marketingadmin
```

**Windows**:

```
C:\> setx AWS_PROFILE marketingadmin
```

IAM ユーザー、グループ、ロール、ベストプラクティスの詳細については、「*IAM ユーザーガイド*」の「[IAM ID (ユーザー、グループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」および「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id-roles.html)」を参照してください。

## 多要素認証を使用する
<a name="cli-configure-role-mfa"></a>

セキュリティを高めるには、ロールプロファイルを使用して呼び出しを試みるときに、多要素認証 (MFA) デバイスから生成された一回限りのキー、U2F デバイス、またはモバイルアプリケーションを指定するようにユーザーに要求することができます。

まず、MFA を要求するために IAM ロールの信頼関係を変更することを選択できます。これにより、すべてのユーザーは最初に MFA を使用して認証しなくてはロールを使用できなくなります。例として、次の例の `Condition` 行を参照してください。このポリシーでは、`anika` という名前のユーザーが、MFA を使用して認証した場合にのみ、ポリシーがアタッチされているロールを引き受けることを許可しています。

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:user/anika" },
      "Action": "sts:AssumeRole",
      "Condition": { "Bool": { "aws:multifactorAuthPresent": true } }
    }
  ]
}
```

------

次に、ロールプロファイルに、ユーザーの MFA デバイスの ARN を指定する行を追加します。次のサンプル `config` ファイルエントリでは、2 つのロールプロファイルを示しています。どちらもユーザー `anika` のアクセスキーを使用してロール `cli-role` の一時的な認証情報をリクエストします。ユーザー `anika` には、ロールの信頼ポリシーによって付与されたロールを引き受けるためのアクセス権限があります。

```
[profile role-without-mfa]
region = us-west-2
role_arn= arn:aws:iam::128716708097:role/cli-role
source_profile=cli-user

[profile role-with-mfa]
region = us-west-2
role_arn= arn:aws:iam::128716708097:role/cli-role
source_profile = cli-user
mfa_serial = arn:aws:iam::128716708097:mfa/cli-user

[profile cli-user]
region = us-west-2
output = json
```

この `mfa_serial` 設定では、次に示すような ARN またはハードウェア MFA トークンのシリアル番号を使用できます。

最初のプロファイル `role-without-mfa` では、 MFA は不要です。ただし、前の例でロールにアタッチされた信頼ポリシーが MFA を必要とするため、このプロファイルを使用してコマンドを実行しても失敗します。

```
$ aws iam list-users --profile role-without-mfa

An error occurred (AccessDenied) when calling the AssumeRole operation: Access denied
```

2 番目のプロファイルエントリ `role-with-mfa` は、使用する MFA デバイスを識別します。ユーザーがこのプロファイルを使用した AWS CLI コマンドの実行を試行すると、AWS CLI が MFA デバイスによって提供されるワンタイムパスワード (OTP) の入力を求めるプロンプトをユーザーに表示します。MFA 認証が成功すると、コマンドによってリクエストされたオペレーションが実行されます。OTP は画面に表示されません。

```
$ aws iam list-users --profile role-with-mfa
Enter MFA code for arn:aws:iam::123456789012:mfa/cli-user:
{
    "Users": [
        {
            ...
```

## クロスアカウントロールと外部 ID
<a name="cli-configure-role-xaccount"></a>

クロスアカウントロールとしてロールを設定することにより、 ユーザーが別のアカウントに属しているロールを使用できるようにすることができます。ロールの作成時に、[「IAM ユーザーに権限を委任するロールを作成する」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)の説明に従って、ロールタイプを **[別の AWS アカウント]** に設定します。必要に応じて、[**MFA が必要**] を選択します。「**MFA が必要**」設定では、 [多要素認証を使用する](#cli-configure-role-mfa) の説明に従って、信頼関係の適切な条件を設定します。

[外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) を使用して、複数のアカウント間でロールを使用できるユーザーをさらに制御する場合は、ロールプロファイルにも `external_id` パラメータを追加する必要があります。これは通常、もう一方のアカウントが社外または組織外のユーザーによって制御される場合にのみ使用します。

```
[profile crossaccountrole]
role_arn = arn:aws:iam::234567890123:role/SomeRole
source_profile = default
mfa_serial = arn:aws:iam::123456789012:mfa/saanvi
external_id = 123456
```

## 監査を容易にするためのロールセッション名の指定
<a name="cli-configure-role-session-name"></a>

ロールが多くの個人間で共有されると、監査はより難しくなります。そこで、呼び出された各オペレーションを、アクションを呼び出した個人に関連付けることが必要になります。ただし、個人がロールを使用する場合、個人によるロールの引き受けはオペレーションの呼び出しとは別のアクションであるため、この 2 つを手動で相互に関連付ける必要があります。

ユーザーがロールを引き受けるときに一意のロールセッション名を指定すれば、この手順を簡素化できます。これを行うには、ロールを指定する `role_session_name` ファイルの各名前付きプロファイルに `config` パラメータを追加します。`role_session_name` 値が `AssumeRole` オペレーションに渡され、ロールセッションの ARN の一部になります。また、ログに記録されたすべてのオペレーションの AWS CloudTrail ログにも含まれます。

例えば、次のようにロールベースのプロファイルを作成できます。

```
[profile namedsessionrole]
role_arn = arn:aws:iam::234567890123:role/SomeRole
source_profile = default
role_session_name = Session_Maria_Garcia
```

これにより、ロールセッションに次の ARN が付与されます。

```
arn:aws:iam::234567890123:assumed-role/SomeRole/Session_Maria_Garcia
```

また、すべての AWS CloudTrail ログには、各オペレーションでキャプチャされた情報にロールセッション名が含まれます。

## ウェブ ID を使用したロールの継承
<a name="cli-configure-role-oidc"></a>

プロファイルを設定して、AWS CLI が[ウェブ ID フェデレーションと Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html) を使用してロールを引き受ける必要があることを示すことができます。これをプロファイルで指定すると、AWS CLI は自動的に対応する AWS STS `AssumeRoleWithWebIdentity` 呼び出しを行います。

**注記**  
IAM ロールを使用するプロファイルを指定すると、AWS CLI は適切な呼び出しを行って、一時的な認証情報を取得します。これらの認証情報は `~/.aws/cli/cache` に保存されます。同じプロファイルを指定するそれ以降の AWS CLI コマンドでは、有効期限が切れるまで、キャッシュされた一時的な認証情報が使用されます。有効期限が切れると、AWS CLI は自動的に認証情報を更新します。

ウェブ ID フェデレーションを使用して一時的な認証情報を取得、使用するには、共有プロファイルで以下の設定値を指定します。

[role\$1arn](#cli-configure-role)  
引き受けるロールの ARN を指定します。

web\$1identity\$1token\$1file  
OAuth 2.0 アクセストークンまたは ID プロバイダによって提供される OpenID Connect ID トークンを含むファイルへのパスを指定します。AWS CLI はこのファイルをロードし、その内容を `WebIdentityToken` 引数として `AssumeRoleWithWebIdentity` オペレーションに渡します。

[role\$1session\$1name](#cli-configure-role-session-name)  
このロール継承セッションに適用されるオプションの名前を指定します。

ウェブ ID を使用したロールの継承プロファイルの設定に必要な最小限の設定例を次に示します。

```
# In ~/.aws/config

[profile web-identity]
role_arn=arn:aws:iam:123456789012:role/RoleNameToAssume
web_identity_token_file=/path/to/a/token
```

この設定は、[環境変数](cli-configure-envvars.md)を使用して提供することもできます。

AWS\$1ROLE\$1ARN  
引き受けるロールの ARN。

AWS\$1WEB\$1IDENTITY\$1TOKEN\$1FILE  
ウェブ ID トークンファイルへのパス。

AWS\$1ROLE\$1SESSION\$1NAME  
このロール継承セッションで適用される名前です。

**注記**  
これらの環境変数は、現在、ウェブ ID プロバイダーのロールを継承する場合にのみ適用されます。これらは、AssumeRole プロバイダーの設定には適用されません。

## キャッシュされた認証情報のクリア
<a name="cli-configure-role-cache"></a>

ロールを使用する際、AWS CLI は、有効期限が切れるまで一時的な認証情報をキャッシュします。次回この一時的な認証情報を使用しようとすると、AWS CLI はユーザーに代わってこの情報の更新を試みます。

ロールの一時的な認証情報が[取り消された場合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)、それらは自動的には更新されず、使用しようとすると失敗します。ただし、キャッシュを削除して、AWS CLI で新しい認証情報を取得するように強制することができます。

**Linux または macOS**

```
$ rm -r ~/.aws/cli/cache
```

**Windows**:

```
C:\> del /s /q %UserProfile%\.aws\cli\cache
```