IAM ロールに切り替える (AWS CLI) - AWS Identity and Access Management
シナリオ例: 本稼働ロールに切り替えるシナリオ例: インスタンスプロファイルロールが他のアカウントのロールに切り替えることを許可する

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

ロールは、必要な AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。その点では、AWS Identity and Access Management（IAM）のユーザーに似ています。ユーザーとしてサインインすると、特定の一連のアクセス許可が付与されます。ただし、ロールにはサインインされませんが、ユーザーとしてサインインした後でロールを切り替えることができます。こうすると、元のユーザーアクセス権限が一時的に無効になり、そのロールに割り当てられたアクセス権限が代わりに付与されます。ロールは、自身のアカウントのロールでも、他の AWS アカウント のロールでもかまいません。ロールとその利点、およびロールを作成して設定する方法については、「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 時間に制限されます。ロールの最大値を確認する方法については、「ロールの最大セッション期間を更新する」を参照してください。

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

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

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

注記

セキュリティ上の理由から、管理者は AWS CloudTrail ログを確認して、AWS でアクションを実行したユーザーを調べることができます。管理者は、ロールを引き受けるときに、ソース ID またはロールセッション名の指定を要求する場合があります。詳細については、sts:SourceIdentityおよびsts: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. 新しいプロファイルを作成した後、AWS CLI パラメータを指定した --profile prodaccess コマンドは、デフォルトのユーザーではなく、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 インスタンスが存在すると仮定します。このインスタンスには、同じ abcd アカウント内の Amazon S3 バケットで読み取り専用の amzn-s3-demo-bucket1 タスクをアプリケーションが実行する 111111111111 インスタンスプロファイルのロールが含まれています。ただし、アプリケーションは、アカウント 222222222222 でタスクを実行するために efgh クロスアカウントロールを引き受けることも許可されている必要があります。これを行うには、abcd EC2 インスタンスプロファイルのロールは次のアクセス許可ポリシーを持っている必要があります。

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

{
    "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 ロールのアクセス許可ポリシー

{
    "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 ロールの信頼ポリシー

{
    "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 エポック時刻 (1970 年 1 月 1 日午前 0 時 UTC からの秒数) 形式の時刻を表す整数です。詳細については、AWS CloudTrail ユーザーガイド の「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 コマンドは、アカウント 222222222222 の efgh ロールにアタッチされたアクセス許可で実行されます。

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

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

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

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