メニュー
AWS Identity and Access Management
ユーザーガイド

チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任

このチュートリアルでは、ロールを使用して、お客様が所有する異なる AWS アカウント (Production および Development) にあるリソースへのアクセスを委任する方法について説明します。特定のアカウントにあるリソースを別のアカウントのユーザーと共有します。このようにクロスアカウントアクセスを設定することで、お客様は、アカウントごとに IAM ユーザーを作成する必要がなくなります。また、ユーザーは、異なる AWS アカウントにあるリソースにアクセスするために、あるアカウントからサインアウトして別のアカウントにサインインする必要がなくなります。ロールを設定したら、AWS マネジメントコンソール、AWS CLI、API からロールを使用する方法を参照してください。

このチュートリアルでは、Production アカウントは既存のアプリケーションを管理しており、開発アカウントは開発者とテスターが自由にアプリケーションをテストできるサンドボックスを想定しています。各アカウントでは、アプリケーション情報が Amazon S3 バケットに格納されています。お客様は開発アカウントの IAM ユーザーを管理しており、開発とテスターの 2 つの IAM グループがあるとします。どちらのグループのユーザーにも、Development アカウントで作業し、そのリソースにアクセスするアクセス許可があります。ときどき、開発者が Production アカウントのライブアプリケーションを更新する必要があります。これらのアプリケーションでは、productionapp と呼ばれる Amazon S3 バケットに保存されます。

このチュートリアルの終了時に、Development アカウント (信頼される側のアカウント) のユーザーに、Production アカウント (信頼する側のアカウント) の productionapp バケットにアクセスを許可するロールを、Production アカウントに作成します。開発者は、AWS マネジメントコンソール でロールを使用して Production アカウントの productionapp バケットにアクセスできます。さらに、ロールにより提供される一時的な認証情報によって認証された API 呼び出しを使用してバケットにアクセスすることもできます。テスターがそのロールを使用して同様の操作を行うことはできません。

このワークフローには 3 つの基本的なステップがあります。

ステップ 1 - ロールの作成

まず、AWS マネジメントコンソール を使用して Production アカウント (ID 番号 999999999999) と Development アカウント (ID 番号 111111111111) との間の信頼を確立します。続いて、UpdateApp という名前の IAM ロールを作成します。ロールの作成時に、Development アカウントを信頼されたエンティティとして定義し、信頼されたユーザーに productionapp バケットを更新する許可を与えるアクセス許可ポリシーを特定します。

ステップ 2 - ロールへのアクセスを許可する

チュートリアルのこのステップでは、IAM グループポリシーを変更して、テスターが UpdateApp ロールへのアクセスを拒否されるようにします。このシナリオではテスターに PowerUser アクセス許可があるため、ロールの使用を明示的に拒否する必要があります。

ステップ 3 - ロールを切り換えてアクセスをテストする

最後に、開発者として、UpdateApp ロールを使用して Production アカウントの productionapp バケットを更新します。AWS コンソール、AWS CLI、API を使用してロールにアクセスする方法について説明します。

前提条件

このチュートリアルでは、以下を実行済みであることを前提としています。

  • 使用できる AWS アカウントを、それぞれ Development アカウントと Production アカウントを表す 2 つのアカウントに分けます。

  • Development アカウントのユーザーとグループは、以下のように作成され設定されます:

    ユーザー グループ アクセス許可
    David 開発者 両方のユーザーが Development アカウントの AWS マネジメントコンソール にサインインして使用できます
    Theresa テスター
  • Production アカウントにはユーザーまたはグループを作成する必要はありません。

  • Production アカウントで作成された Amazon S3 バケット。このチュートリアルでは ProductionApp と呼びますが、S3 バケット名はグローバルに一意である必要があるため、別の名前のバケットを使用する必要があります。

ステップ 1 - ロールの作成

ある AWS アカウントに属しているユーザーが他の AWS アカウントのリソースへアクセスできるようにするには、リソースにアクセスできるユーザーを定義するロールを作成します。また、このロールに切り替えるユーザーに対して付与されるアクセス許可についても定義します。

チュートリアルのこのステップでは、本番稼働用アカウントにロールを作成し、開発アカウントを信頼されたエンティティとして指定します。また、ロールのアクセス許可を productionapp バケットでの読み書き専用に制限します。ロールを使用するアクセス許可が付与されるすべてのユーザーは、productionapp バケットに対する読み取りと書き込みを実行できます。

ロールを作成する前に、開発 AWS アカウントのアカウント ID が必要です。アカウント ID は、各 AWS アカウントに割り当てられる固有の識別子です。

開発 AWS アカウント ID を取得するには

  1. 開発用アカウントの管理者として AWS マネジメントコンソール にサインインし、「https://console.aws.amazon.com/iam/」で IAM コンソールを開きます。

  2. ナビゲーションバーで、[Support]、[Support Center] の順に選択します。アカウント番号は、画面右上([Support] メニューの下)に示されています。アカウント ID は、12 桁の数字です。このシナリオでは、開発アカウント ID を 111111111111 とします。ただし、テスト環境でシナリオを再構築する場合は、有効なアカウント ID を使用してください。

開発アカウントで使用できるロールを本番稼働用アカウントで作成するには

  1. Production アカウントの管理者として AWS マネジメントコンソールにサインインし、IAM コンソールを開きます。

  2. ロールを作成する前に、ロールに必要なアクセス許可を定義する管理ポリシーを準備します。後の手順で、このポリシーをロールにアタッチします。

    productionapp バケットの読み込みおよび書き込みのアクセスを設定します。AWS には Amazon S3 管理ポリシーが用意されていますが、単一の Amazon S3 バケットへの読み取りおよび書き込みアクセス用ではありません。代わりに独自のポリシーを作成できます。

    左側のナビゲーションペインで [Policies] を選択し、続いて [Create policy] を選択します。

  3. [JSON] タブを選択して、次の JSON ポリシードキュメントからテキストをコピーします。JSON テキストボックスにこのテキストを貼り付け、リソース ARN (arn:aws:s3:::productionapp) を、S3 バケットに適した実際の ARN に置き換えます。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] }

    ListBucket アクセス許可は、ユーザーに productionapp バケットにあるオブジェクトの閲覧を許可します。GetObjectPutObjectDeleteObject アクセス許可によって、ユーザーは productionapp バケットの内容を表示、更新、および削除できます。

  4. 完了したら、[Review policy] を選択します。構文エラーがある場合、Policy Validator によって報告されます。

    注記

    いつでも [ビジュアルエディタ] タブと [JSON] タブを切り替えることができます。ただし、[Visual editor] タブで [Review policy] を変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、「ポリシーの再構成」を参照してください。

  5. [Review] ページで、ポリシー名に read-write-app-bucket と入力します。ポリシーの [Summary] で、ポリシーによって割り当てられたアクセス許可を確認し、[Create policy] を選択して作業を保存します。

    新しいポリシーが管理ポリシーの一覧に表示されます。

  6. 左側のナビゲーションペインで [Roles] を選択し、続いて [Create role] を選択します。

  7. [Another AWS account] ロールタイプを選択します。

  8. [Account ID] で、開発アカウント ID を入力します。

    このチュートリアルでは、開発アカウントに対してサンプルのアカウント ID の 111111111111 を使用します。有効なアカウント ID を使用してください。使用しているアカウント ID が無効 (111111111111 など) の場合は、IAM で新しいロールを作成することはできません。

    現時点では、ロールを引き受ける上で、外部 ID や多要素認証 (MFA) は必要ありません。従って、これらのオプションは選択していない状態にしておきます。詳細については、「AWS での多要素認証 (MFA) の使用」を参照してください。

  9. [Next: Permissions] を選択して、そのロールに関連するアクセス権限を設定します。

  10. 以前に作成したポリシーの横にあるチェックボックスを選択します。

    ヒント

    [Filter] で、[Customer managed] を選択してリストをフィルタし、自分で作成したポリシーのみを含めます。これにより、AWS が作成したポリシーが非表示になり、探しているポリシーを見つけるのが簡単になります。

    続いて、[Next: Review] を選択します。

  11. ロール名に「UpdateApp」と入力します。

  12. (オプション) [Role description] に、新しいロールの説明を入力します。

  13. ロールを確認したら、[Create role] を選択します。

    ロールのリストで、UpdateApp ロールが表示されます。

ここで、ロールに固有の識別子である Amazon リソースネーム (ARN) を取得しなければいけません。開発者グループやテスターグループのポリシーを変更するとき、アクセス許可を許可または拒否するためのロールの ARN を指定します。

UpdateApp の ARN を取得するには

  1. IAM コンソールの [Navigation] ペインで [Roles] を選択します。

  2. ロールのリストで、[UpdateApp] ロールを選択します。

  3. 詳細ペインの [Summary] セクションで、[Role ARN] の値をコピーします。

    本番稼働用アカウントのアカウント ID が 999999999999 であるため、ロールの ARN は arn:aws:iam::999999999999:role/UpdateApp となります。"本稼働用" アカウントでは、実際の AWS アカウント ID を指定してください。

これで、開発アカウントを信頼されたプリンシパルとして指定するロールが本番稼働用アカウントに作成され、本番稼働用アカウントと開発アカウントの間に信頼関係が確立されました。また、UpdateApp ロールに切り替えるユーザーが何を実行できるかについても定義しました。

次は、グループのアクセス許可を修正します。

ステップ 2 - ロールへのアクセスを許可する

この時点では、Testers グループと Developers グループのメンバーにはいずれも、Development アカウントで自由にアプリケーションをテストできるアクセス権限があります。ここでは、ロールの切り替えを許可するアクセス権限を追加するために必要なステップを示します。

UpdateApp ロールに切り替えることを許可するように Developers グループを変更するには

  1. Development アカウントの管理者としてサインインし、IAM コンソールを開きます。

  2. [Groups] を選択して、[Developers] を選択します。

  3. [Permissions] タブを選択して、[Inline Policies] セクションを展開し、[Create Group Policy] を選択します。インラインポリシーがまだ存在しない場合、ボタンは表示されません。代わりに、[To create one, click here.] の最後にあるリンクを選択します。

  4. [Custom Policy] を選択し、[Select] ボタンを選択します。

  5. allow-assume-S3-role-in-production」のようにポリシー名を入力します。

  6. 次のポリシーステートメントを追加して、Production アカウントの UpdateApp ロールに対する AssumeRole アクションを許可します。必ず Resource 要素の PRODUCTION-ACCOUNT-ID を、Production アカウントの実際の AWS アカウント ID に変更してください。

    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

    Allow エフェクトは、Developers グループが Production アカウントの UpdateApp ロールにアクセスすることを明示的に許可します。どの開発者がこのロールにアクセスしようとしても成功します。

  7. [Apply Policy] を選択して、Developer グループにポリシーを追加します。

ほとんどの環境では、次の手順は通常必要ありません。ただし、パワーユーザーアクセス権限を使用している場合、グループによってはロールを切り替えることができます。次の手順は、ロールを引き受けることができないように Testers グループに "Deny" アクセス権限を追加する方法を示しています。この手順が環境で必要ない場合は追加しないことをお勧めします。"Deny" アクセス権限を追加すると、アクセス権限の全体的な状況が複雑になり、管理しづらくなります。"Deny" アクセス権限は、他に良いオプションがない場合のみ使用してください。

UpdateApp ロールを引き継ぐためのアクセス権限を拒否するように Testers グループを変更するには

  1. [Groups] を選択して、[Testers] を選択します。

  2. [Permissions] タブを選択して、[Inline Policies] セクションを展開し、[Create Group Policy] を選択します。

  3. [Custom Policy] を選択し、[Select] ボタンを選択します。

  4. deny-assume-S3-role-in-production」のようにポリシー名を入力します。

  5. 次のポリシーステートメントを追加して、UpdateApp ロールに対する AssumeRole アクションを拒否します。必ず Resource 要素の PRODUCTION-ACCOUNT-ID を、Production アカウントの実際の AWS アカウント ID に変更してください。

    { "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

    Deny エフェクトは、Testers グループが Production アカウントの UpdateApp ロールにアクセスすることを明示的に拒否します。そのロールにアクセスしようとするテスターは、アクセス拒否のメッセージを受け取ります。

  6. [Apply Policy] を選択して、テスターグループにポリシーを追加します。

これで、Developers グループは、Production アカウントの UpdateApp ロールを使用するためのアクセス権限を持つようになりました。Testers グループは、UpdateApp ロールを使用できません。

次に、開発者の David が AWS マネジメントコンソール、および AWS CLI コマンド、AssumeRole API 呼び出しを使用して Production アカウントで productionapp バケットにアクセスする方法について説明します。

ステップ 3 - ロールを切り換えてアクセスをテストする

このチュートリアルの最初の 2 つのステップを完了した時点で、Production アカウントのリソースに対するアクセス権限を付与するロールがあります。また、Development アカウントには、そのロールを使用できるユーザーで構成されたグループもあります。このロールが使用可能になったところで、このステップでは、AWS マネジメントコンソール、AWS CLI、AWS API を使用してそのロールに切り替える方法について説明します。

重要

ロールの切り替えは、IAM ユーザーまたはフェデレーションユーザーとしてサインインしている場合にのみ可能です。さらに、Amazon EC2 インスタンスを起動してアプリケーションを実行すると、そのアプリケーションはそのインスタンスプロファイルを通じてロールを引き受けることができます。AWS アカウントのルートユーザー としてサインインしているときに、ロールを切り替えることはできません。

ロールの切り替え (コンソール)

David が AWS マネジメントコンソール で本稼働環境を操作する必要がある場合は、ロールの切り替えを使用することができます。アカウント ID またはエイリアスとロール名を指定すれば、David のアクセス権限は、ロールによって許可されているものに直ちに切り替わります。次に、David はコンソールを使用して productionapp バケットを操作することができますが、本稼働環境の他のリソースは一切操作できません。また、そのロール使用中に、開発用アカウントのパワーユーザーアクセス権限を使用することはできません。これは、同時に有効にできるアクセス権限のセットは 1 つのみであるためです。

重要

AWS マネジメントコンソールを使ったロールの切り替えは、ExternalID を必要としないアカウントでのみ機能します。お客様のアカウントへのアクセスを第三者に許可し、アクセス権限ポリシーで Condition 要素の ExternalID を必要とする場合、第三者は AWS API またはコマンドラインツールを使用することでのみ、お客様のアカウントにアクセスできます。第三者は ExternalID の値を指定できないため、コンソールを使用できません。このシナリオの詳細については、「AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法」および「AWS セキュリティブログAWS マネジメントコンソールへのクロスアカウントアクセスを有効にする方法」を参照してください。

David が [Switch Role] ページに移動するには、2 つの方法があります。

  • David は事前定義されたロールの切り替え設定を指すリンクを管理者から受け取ります。リンクは [Create role] ウィザードの最終ページ、またはクロスアカウントロールの [Role Summary] ページで管理者に提供されます。このリンクを選択すると、[Switch Role] ページに移動します。このページには、[Account ID] と [Role name] フィールドが既に入力されています。David は、[Switch Role] ボタンを選択するだけで作業は完了します。

  • 管理者はメールでリンクを送信しませんが、代わりに [Account ID] 番号および [Role Name] の値を送信します。David は、手動でこれらを入力してロールを切り替える必要があります。これを次の手順に示します。

ロールを割り当てるには

  1. David は、Development グループの通常のユーザーを使用して AWS にサインインします。

  2. 管理者から受け取ったメールのリンクを選択します。これにより、[Switch Role] ページに移動します。このページには、アカウント ID、エイリアス、およびロール名情報が既に入力されています。

    - または -

    ナビゲーションバーのユーザー名 ([Identity] メニュー) を選択し、[Switch Role] を選択します。

    David がこの方法で初めて [Switch Role] ページにアクセスする場合は、初回アクセス用の [Switch Role] ページが表示されます。このページでは、ロールを切り替えて AWS アカウント全体にわたるリソースを管理できるようにする方法についての追加情報が説明されます。David がこの手順の残りを完了するには、このページの [Switch Role] ボタンを選択する必要があります。

  3. 次に、ロールにアクセスするために、David は Production アカウント ID 番号 (999999999999) およびロール名 (UpdateApp) を入力する必要があります。

    また、現在アクティブなロール (および関連するアクセス権限) を継続して把握するため、David は [Display Name] テキストボックスに「PRODUCTION」と入力し、赤のオプションを選択して、[Switch Role] を選択します。

  4. これで David は、Amazon S3 コンソールを使用して Amazon S3 バケットを操作したり、ロールにアクセス権限がある UpdateApp ロールにアクセス権限がある他のリソースを操作できます。

  5. 必要な作業を終了したら、David は元のアクセス権限に戻ることができます。アクセス権限を戻すには、ナビゲーションバーのロール表示名 [PRODUCTION] を選択し、続いて [Back to David @ 111111111111] を選択します。

  6. David が次回にロールに切り替えるために、ナビゲーションバーの [Identity] メニューを選択すると、PRODUCTION エントリが前回からそのままになっています。そのエントリを選択するだけで、アカウント ID とロール名を再入力することなく、すぐにロールに切り替えることができます。

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

David がコマンドラインで本稼働環境を操作する必要がある場合、AWS CLI を使用できます。aws sts assume-role コマンドを実行し、ロールの ARN を渡して、そのロールの一時的なセキュリティ認証情報を取得します。次に、環境変数でそれらの認証情報を設定し、それ以降の AWS CLI コマンドが、ロールのアクセス権限を使用して動作するようにします。David がロールを使用中に、Development アカウントのパワーユーザーの権限を使用することはできません。これは、一度に有効にできるアクセス権限のセットは 1 つのみであるためです。

すべてのアクセスキーとトークンは例にすぎず、実際にはそのように使用できないことに注意してください。ライブ環境の適切な値に置き換えてください。

ロールを割り当てるには

  1. David はコマンドプロンプトウィンドウを開き、次のコマンドを実行して、AWS CLI クライアントが動作していることを確認します。

    aws help

    注記

    David のデフォルト環境では、aws configure コマンドで作成したデフォルトのプロファイルから、David ユーザー認証情報を使用します。詳細については、『AWS Command Line Interface ユーザーガイド』の「AWS Command Line Interface の設定」を参照してください。

  2. David は次のコマンドを実行してロールの切り替えプロセスを開始し、Production アカウントで UpdateApp ロールに切り替えます。ロールを作成した管理者から、ロールの ARN を取得しました。コマンドでは、セッション名も提供する必要もあります。セッション名には任意のテキストを選択できます。

    aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateApp" --role-session-name "David-ProdUpdate"

    出力には次のように表示されます。

    { "Credentials": { "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e NhyDHq6ikBQ==", "Expiration": "2014-12-11T23:08:07Z", "AccessKeyId": "AKIAIOSFODNN7EXAMPLE" } }
  3. 出力の [Credentials] セクションには、3 つの必要な情報が表示されます。

    • AccessKeyId

    • SecretAccessKey

    • SessionToken

    以降の呼び出しでこれらのパラメータを使用するには、AWS CLI 環境を設定する必要があります。認証情報を設定するさまざまな方法の詳細については、「AWS Command Line Interface の設定」を参照してください。セッショントークンの取得をサポートしていないため、aws configure コマンドを使用することはできません。ただし、設定ファイルに手動で情報を入力することができます。これらは有効期限が比較的短い一時的な認証情報なので、現在のコマンドラインセッションの環境に追加するのが最も簡単です。

  4. David は、環境に 3 つの値を追加するため、前のステップの出力を切り取り、次のコマンドに貼り付けます。セッショントークン出力の改行の問題に対応するため、シンプルなテキストエディターで切り取りと貼り付けを行うことをお勧めします。ここではわかりやすくするために改行して表示されていますが、1 行の長い文字列として入力する必要があります。

    注記

    以下の例では「set」が環境変数を作成するためのコマンドとなっている Windows 環境で指定されたコマンドを示しています。Linux または Mac コンピュータでは、代わりに「export」コマンドを使用します。この例における他の部分はすべて、3 つの環境で有効です。

    set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen DHq6ikBQ==

    この時点で、次のコマンドはいずれも、これらの認証情報によって識別されたロールのアクセス権限で実行されます。David の場合は、UpdateApp ロールです。

  5. Production アカウントのリソースにアクセスするコマンドを実行します。この例では、David は次のコマンドを使用して S3 バケットのコンテンツの一覧を示します。

    aws s3 ls s3://productionapp

    Amazon S3 バケット名は共通にユニークであるため、バケットを所有するアカウント ID を指定する必要はありません。その他の AWS サービスのリソースにアクセスするには、そのリソースを参照するために必要なコマンドと構文について記載されている対象サービスの AWS CLI のドキュメントを参照してください。

AssumeRole (AWS API) の使用

David は、コードから Production アカウントを更新する必要がある場合、AssumeRole を呼び出し、UpdateApp ロールを取得します。この呼び出しは、David が Production アカウントにある productionapp バケットにアクセスするために使用できる一時的な認証情報を返します。これらの認証情報を使用して、David は productionapp バケットを更新する API 呼び出しを行うことができます。ただし、開発用アカウントのパワーユーザーアクセス権限を持っていても、本番稼働用アカウントの他のリソースにアクセスする API 呼び出しを行うことはできません。

ロールを割り当てるには

  1. デイビッドは、アプリケーションの一部として AssumeRole を呼び出します。デイビッドは UpdateApp ARN: arn:aws:iam::999999999999:role/UpdateApp を特定しなければいけません。

    AssumeRole 呼び出しの応答には、認証情報がいつ失効し、新しい認証情報をリクエストする必要があるかを示す、SecretAccessKeyAccessKeyId、および Expiration を持つ一時的な認証情報が含まれます。

  2. 一時的な認証情報を使用して、デイビッドは s3:PutObject 呼び出しを行い、productionapp バケットを更新します。David は、AuthParams パラメータとして API 呼び出しに認証情報を渡します。ロールの一時的な認証情報は productionapp バケットでの読み取りおよび書き込み専用のアクセスであるため、本番稼働用アカウントでの他のアクションは拒否されます。

コードの例 (Python を使用) については、「IAM ロールの切り替え(API)」を参照してください。

概要

これでクロスアカウント API アクセスのチュートリアルが終了しました。他のアカウントと信頼を構築するロールを作成し、信頼されたエンティティが実行できるアクションを定義しました。次に、どの IAM ユーザーがロールを取得できるのかを制御するグループポリシーを修正しました。その結果、開発アカウントの開発者は、一時的な認証情報を使用して本番稼働用アカウントにある productionapp バケットを更新することができます。