AssumeRole、繰り返し学習する度にゲシュタルト崩壊して分からなくなり、ふり出しに戻ります。
「AssumeRoleなんもわからん」から「なんとなくわかった」になるのを目的としているため、正確さにかける表現がある場合があります。正しい情報はAWS公式ドキュメントをご参照ください。
※チバユキさんの伝説のブログに多大な影響を受け、この記事を書いています。
1.「勇者」と「伝説の剣」と「妖精」の物語
ある最果ての地に伝説の剣があった。
伝説の剣には魔力が宿っていた。
選ばれし者だけが、伝説の剣を抜くことができるという。
伝説の剣のもとには、剣の力を選ばれし者へ与える妖精がいるという。妖精は剣の声を聴き、力を与える者を選ぶ。
関係はこう。
剣には宿る能力のリストがあり、別途、剣を抜ける選ばれし者のリストがある。
剣（IAMロール）に宿る力（ポリシー）のリストはユーザーベースのポリシーである。
剣（IAMロール）を抜ける選ばれし者（Principal）のリストは信頼ポリシーである。
選ばれし者（Principal）に剣（IAMロール）の力を与える妖精（STS）がいる。
剣（IAMロール）に宿る力（ポリシー）のリスト（ユーザーベースのポリシー）
- 火
- 水
- 雷
剣（IAMロール）を抜ける選ばれし者（Principal）のリスト（信頼ポリシー）
- Lambda一族
妖精（STS）は信頼ポリシーに示された選ばれしPrincipalにしか妖精の力を貸さない。
妖精（STS）の力を借りることができる選ばれしPrincipal・Lambda一族の者だけが、妖精（STS）の力を借りて剣（IAMロール）を抜き、ユーザーベースのポリシーに示された火・水・雷の力（ポリシー）で戦うことができる。
ただし、妖精の力（STSが発行した一時トークン）は永続的に使えるものではない。
妖精と勇者・Lambdaの冒険は、今始まったばかり…
もういいですね。
AssumeRoleとは「IAMロールを引き受ける動作・アクション」のことです。
2.IAMポリシー3種類
IAMポリシーの種類をおさえる。
2-1.ユーザーベースのポリシー
- 「IAMユーザ」「IAMグループ」「IAMロール」に関連づけることができるポリシー
- 別名「アイデンティティベースのポリシー」
- 操作主体（誰が使うか）は関連付けられた「IAMユーザ」「IAMグループ」「IAMロール」のいずれか。暗黙的に自明
2-2.リソースベースのポリシー
- ユーザーベースのポリシーと似ているが、関連づけ先がユーザーではなく「AWSサービス」である
- よく使われるのはS3のバケットポリシー、Amazon SQS キューポリシーなど
- 操作主体（誰が使うか）を表すPrincipalの明記が必要
2-3.IAMロールの信頼ポリシー
- 別名「信頼関係」「信頼ポリシードキュメント」（揺らぎあり）
- IAMロールの権限移譲先（Principal） を記載。 IAMロールに組み込む もの。
- 信頼ポリシーで書くアクションは「 sts:AssumeRole 」だけ
- 信頼ポリシーを関連づけたIAMロールが保有する権限（やっていい操作）を、Principalに移譲(を許可)する
つまりIAMロールは二種類のポリシーを持つ。
この「 sts:AssumeRole 」が今回焦点をあてて理解したい部分。
「assume」には「（役割・責任を）引き受ける」という意味があり、AssumeRoleとは 「IAMロールを引き受ける」という動作・アクション のことを言う。
3.IAMロールを使うときの流れ
たとえばLambdaにIAMロールを引き受けさせたいときのざっくりイメージ例。
①LambdaがIAMロールを引き受けよう（AssumeRole）と思う
②STSが信頼ポリシーを確認し、IAMロールを引き受けていいか判断する
③STSがPrincipal（今回はLambda）に一時トークンを発行する
④一時トークンを使って、（IAMロールに関連付けられている）ユーザーベースのポリシーで許可された操作を行う
簡略化してもう一回。
参考