AWSの役割を正確に「想定する」とは何ですか？
質問
AWSでロールを正確に「想定する」とは何を意味し、最終的な定義はどこで提供されますか？
バックグラウンド
ロールを想定して頻繁に使用され、定義とそれが実際に意味するものを理解しようとしています。
プリンシパル（IAMユーザー、AWSリソースにアクセスするアクションを呼び出すEC2インスタンスで実行されているアプリケーションなど）がAWSリソースにアクセスするアクションを呼び出す必要がある場合、
AWS（API？またはAWSの認証ランタイム？）は、プリンシパルに付与できるロールを識別します。
例えば。 EC2ユーザーが、assume-role APIコールを実行し、IAMプロファイルがアタッチされているEC2インスタンスのAWSリソースにアクセスするアプリケーションを実行するように指定されている場合、次のようになります。- EC2 IAMプロファイルのすべてのIAMロール
- IAMの役割とポリシーは、引き継ぎの役割呼び出しでリクエスト
- EC2ユーザーに付与されるIAMロール
AWSは、原則がリソースに対してアクションを実行できるようにするポリシー（アクション、リソース）を持つロールからロールを見つけます。
- AWSは、原則の役割を特定された役割に切り替えます。
ステップ3が発生すると、「プリンシパルが役割を引き受けた」と言われます。これは正しいです？
研究
IAMユーザー、アプリケーション、またはサービスが作成したロールを使用する前に、ロールに切り替えるアクセス許可を付与する必要があります。 IAMユーザーのグループの1つまたはユーザー自体にアタッチされたポリシーを使用して、必要なアクセス許可を付与できます。
役割を引き受けるとは、セキュリティトークンサービス（STS）に、引き受けたい役割に固有の一時的な資格情報（役割資格情報）のセットを提供するように依頼することを意味します。 （具体的には、その役割を持つ新しい「セッション」。）
オプションでこのリクエストにポリシーを含めることができます。これにより、一時的な認証情報の権限を、ロールのポリシーで許可されているもののサブセットのみに制限できます。
次に、これらの資格情報を使用して、さらに要求を行います。これらの認証情報は、アクセスキーIDとシークレットを使用したIAMユーザー認証情報に似ていますが、アクセスキーはASIAではなくAKIAで始まり、セキュリティトークンと呼ばれる3番目の要素があります。一時的な認証情報で署名されたリクエストに含める必要があります。
これらの一時的な認証情報でリクエストを行うと、新しいIDを引き継いでいるので、ロールに関連付けられた権限があり、自分の権限（所有している場合）ではありません。 CloudTrailを使用して、役割を引き受けたユーザーまで役割の資格情報をトレースできますが、それ以外の場合、サービスは資格情報を使用しているユーザーを認識しません。
tl; dr：役割を引き受けるとは、役割を引き受けたエンティティではなく、役割に関連付けられた一時的な資格情報のセットを取得することを意味します。
AWS（API？またはAWSの認証ランタイム？）は、プリンシパルに付与できるロールを識別します。
いいえ。引き受ける役割を指定します。
「あなた」がEC2インスタンスで実行されているコードで、インスタンスにインスタンスロールがある場合、EC2インフラストラクチャは実際にインスタンスに代わって想定ロールを呼び出し、 インスタンスメタデータサービスから一時的な認証情報を取得できます 。これらの資格情報は、インスタンス内からのみアクセスできますが、インスタンスには保存されません。
Lambda関数を実行すると、LambdaインフラストラクチャはSTSに接続し、一時的な認証情報を 環境変数 に配置します。繰り返しますが、これらの資格情報は、関数内に保存されることなく、関数からアクセス可能です。
どちらの場合でも、これらの資格情報で想定ロールを呼び出して別のロールを想定することができますが、ほとんどの環境では必要ありません。
例えばEC2ユーザーが、assume-role APIコールを実行し、IAMプロファイルがアタッチされているEC2インスタンスのAWSリソースにアクセスするアプリケーションを実行するように指定されている場合、次のようになります。
AWSはEC2ユーザーを認識していません。インスタンスロールは、インスタンスで実行されているすべてのものにアクセスできます。
EC2 IAMプロファイルのすべてのIAMロール
インスタンスプロファイルには1つのロールのみを含めることができます 。
IAMの役割とポリシーは、引き継ぎの役割呼び出しでリクエスト
正確に1つの役割を引き受けることを要求します。ポリシーを要求する必要はありません-一時的な資格情報に、ロール資格情報が許可するよりもfewer特権が必要な場合にのみ、ポリシーを指定します。これは、信頼できない場所で実行されるコード（ブラウザーやアプリのコードなど）が資格情報で要求に署名できるようにする必要がある場合に行うことです。
AWSは、原則がリソースに対してアクションを実行できるようにするポリシー（アクション、リソース）を持つロールからロールを見つけます。
いいえ。上記のように、assume-roleを呼び出すときに特定のロールを要求します。
AWSは、原則の役割を特定された役割に切り替えます。
いいえあなたは、提供された一時的な資格情報を使用して切り替えます。
AWSでの役割を正確に想定するものを理解するために、次の図を作成しました。うまくいけば、あなたもそれが役立つと思うでしょう。
図では、次の3つの手順で説明しています。
- 役割を準備する（ExecutionRoleおよびAssumedRole）
- アカウントAでLambda関数を作成します（あなたの場合はEC2です）
- LambdaFunctionを実行します。
ステップ3が発生すると、「プリンシパルが役割を引き継いだ」と言われます。これは正しいです？
役割を引き受ける際に言及した手順は、正しいです。
ここで重要な点は、IAMユーザー、アプリケーション、またはサービスのそれぞれにロールを引き受けることを許可する、IAMロールの信頼関係設定です。ここで、特定の役割を引き受ける権限を付与します。
これは多くの面で重要です。ロールを引き受けることができる人を制御し、ロールへの最小限のアクセスを提供するだけでなく、ロールを引き受けることができるエンティティの最小量を許可することも重要です。