で IAMロールを使用する AWS CLI - AWS Command Line Interface
前提条件IAM ロールの使用の概要ロールの設定と使用の使用 MFAクロスアカウントロールと外部 ID監査を容易にするためのロールセッション名の指定ウェブ ID を使用したロールの継承キャッシュされた認証情報のクリア

このドキュメントは、 のバージョン 1 AWS CLI のみを対象としています。のバージョン 2 に関連するドキュメントについては AWS CLI、「 バージョン 2 ユーザーガイド」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

で IAMロールを使用する AWS CLI

AWS Identity and Access Management （IAM) ロールは、ユーザーが追加の (または別の) アクセス許可を取得したり、別の AWS アカウントでアクションを実行するアクセス許可を取得したりできるようにする認証ツールです。

前提条件

これらの iam コマンドを使用するには、 AWS CLIをインストールして設定する必要があります。詳細については、「AWS CLI のインストール、更新、アンインストール」を参照してください。

IAM ロールの使用の概要

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

次の例は marketingadmin という名前のロールプロファイルを示しています。コマンドを で実行する --profile marketingadmin (または AWS_PROFILE 環境変数 で指定する) 場合、 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、 は自動的にリンクされたuser1プロファイルの認証情報 AWS CLI を検索し、それらを使用して指定されたIAMロールの一時的な認証情報をリクエストします。CLI は、バックグラウンドで sts:AssumeRole オペレーションを使用してこれを実現します。これらの一時的な認証情報は次に、リクエストされた 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 ログでより簡単に監査できる一意のロールセッション名を指定することもできます。

ロールの設定と使用

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

AWS Identity and Access Management ユーザーガイドの「アクセス許可をユーザーに委任するロールの作成」の手順に従って、ユーザーに引き受けさせたいアクセス許可IAMを持つロールを に作成できます。 IAM ロールとソースプロファイルの ユーザーが同じアカウントに存在する場合、ロールの信頼関係を設定するときに、独自のアカウント ID を入力することができます。

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

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

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

信頼ポリシーは、実際にはアクセス許可を付与しません。アカウントの管理者は、適切なアクセス許可を持つポリシーをアタッチすることによって、ロールを引き受けるアクセス許可を個々のユーザーに委任する必要があります。次の例では、ユーザーに付与を行い、ユーザーが marketingadminrole ロールのみを引き受けることを許可するポリシーを示しています。ロールを引き受けるアクセス許可をユーザーに付与する方法の詳細については、「 IAMユーザーガイド」の「ロールを切り替えるアクセス許可をユーザーに付与する」を参照してください。

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

ユーザーは、ロールプロファイルを使用して AWS CLI コマンドを実行するための追加のアクセス許可を持っている必要はありません。代わりに、コマンドを実行するためのアクセス権限は、ロールにアタッチされたアクセス権限によって提供されます。アクセス許可ポリシーをロールにアタッチして、どの AWS リソースに対してどのアクションを実行できるかを指定します。アクセス許可をロールにアタッチする方法 (ユーザーと同じように動作します) の詳細については、 IAM ユーザーガイドのIAM「ユーザーのアクセス許可の変更」を参照してください。

ロールプロファイル、ロールのアクセス許可、ロールの信頼関係およびユーザーアクセス許可が正しく設定されたので、コマンドラインで --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ロール」を参照してください。

多要素認証を使用する

セキュリティを強化するために、ユーザーがロールプロファイルを使用して通話を行おうとするときに、多要素認証 (MFA) デバイス、U2F デバイス、またはモバイルアプリから生成されたワンタイムキーを提供するように要求できます。

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

{
  "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 コマンドを実行しようとすると、 はMFAデバイスが提供するワンタイムパスワード (OTP) を入力するようにユーザーに AWS CLI 求めます。MFA 認証が成功すると、コマンドはリクエストされたオペレーションを実行します。OTP は画面に表示されません。

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

クロスアカウントロールと外部 ID

クロスアカウントロールとしてロールを設定することにより、 ユーザーが別のアカウントに属しているロールを使用できるようにすることができます。ロールの作成時に、「アクセス許可をIAMユーザー に委任するロールの作成」の説明に従って、ロールタイプを別の AWS アカウント に設定します。オプションで、 が必要 MFAを選択します。「」で説明されているように、信頼関係に適切な条件MFAを設定する必要があります多要素認証を使用する。

外部 ID を使用して、複数のアカウント間でロールを使用できるユーザーをさらに制御する場合は、ロールプロファイルにも 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

監査を容易にするためのロールセッション名の指定

ロールが多くの個人間で共有されると、監査はより難しくなります。そこで、呼び出された各オペレーションを、アクションを呼び出した個人に関連付けることが必要になります。ただし、個人がロールを使用する場合、個人によるロールの引き受けはオペレーションの呼び出しとは別のアクションであるため、この 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 を使用したロールの継承

プロファイルを設定して、 がウェブ ID フェデレーションと Open ID Connect (OIDC） を使用してロールを引き受け AWS CLI るべきことを示すことができます。プロファイルでこれを指定すると、 AWS CLI は自動的に対応する AWS STS AssumeRoleWithWebIdentity呼び出しを行います。

注記

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

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

role_arn

引き受けるロールARNの を指定します。

web_identity_token_file

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

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

この設定は、環境変数を使用して提供することもできます。

AWS_ROLE_ARN

引き受けるロールARNの 。

AWS_WEB_IDENTITY_TOKEN_FILE

ウェブ ID トークンファイルへのパス。

AWS_ROLE_SESSION_NAME

このロール継承セッションで適用される名前です。

注記

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

キャッシュされた認証情報のクリア

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

ロールの一時的な認証情報が取り消された場合、それらは自動的には更新されず、使用しようとすると失敗します。ただし、キャッシュを削除して、 が新しい認証情報を強制 AWS CLI 的に取得するようにすることができます。

Linux または macOS

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

Windows

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