IAM ロールの切り替え (AWS CLI) - AWS Identity and Access Management

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

IAM ロールの切り替え (AWS CLI)

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

重要

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

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

ロールチェーン – ロールチェーンを使用することもできます。ロールチェーンは、ロールからのアクセス許可を使用して 2 番目のロールにアクセスします。コンソールでロールを切り替えると、ロールチェーンは使用されません。元のユーザーのアクセス許可を使用しています。

デフォルトでは、ロールセッションは 1 時間です。assume-role* CLI オペレーションを使用してこのロールを引き受ける場合は、duration-seconds パラメータの値を指定できます。この値は 900 秒 (15 分) からロールの最大セッション期間設定までの範囲を指定できます。ロールの最大値を確認する方法については、「ロールの最大セッション期間設定の表示」を参照してください。

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

シナリオの例: 本稼働ロールに切り替える

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

注記

セキュリティ上の理由から、管理者は AWS CloudTrail ログを確認して、AWS でアクションを実行したユーザーを調べることができます。管理者が、ロールを引き受ける際にソース ID またはロールセッション名を指定するよう要求する場合があります。詳細については、「sts:SourceIdentity」および「aws:RoleSessionName」を参照してください。

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

  1. AWS CLI をはじめて使用する場合は、まず、デフォルトの CLI プロファイルを設定する必要があります。コマンドプロンプトを開き、IAM ユーザーまたはフェデレーティッドロールからのアクセスキーを使用するように、AWS CLI を設定します。詳細については、AWS Command Line Interface ユーザーガイドの「 AWS Command Line Interface の設定」を参照してください。

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

    aws iam list-users --profile prodaccess

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

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

詳細については、AWS Command Line Interface ユーザーガイドの「ロールの引き受け」を参照してください。

シナリオの例: インスタンスプロファイルロールが他のアカウントのロールに切り替えることを許可する

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

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

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:HeadBucket" ], "Resource": "*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::my-bucket-1/*", "arn:aws:s3:::my-bucket-1" ] }, { "Sid": "AllowIPToAssumeCrossAccountRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/efgh" } ] }

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

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

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:HeadBucket" ], "Resource": "*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::my-bucket-2/*", "arn:aws:s3:::my-bucket-2" ] } ] }

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

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

{ "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 の形式で作成されます。ここでは nnnnnnnnUnix エポック時刻 (1970 年 1 月 1 日午前 0 時 UTC からの秒数) 形式の時刻を表す整数です。詳細については、AWS CloudTrail User Guideの「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
  2. 新しいプロファイルを作成した後、パラメータ --profile instancecrossaccount を指定する すべての AWS CLI コマンドは、アカウント 222222222222efgh ロールにアタッチされたアクセス許可で実行されます。

    aws s3 ls my-bucket-2 --profile instancecrossaccount

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

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

詳細については、AWS Command Line Interface ユーザーガイドの「ロールの引き受け」を参照してください。