IAMロールはヘルメットじゃなくてロールセッションがヘルメットだ
AWS入門時に「IAMロールはヘルメットだ」と理解してしばらく経った人向けの記事です。
IAMロールがヘルメットだと何がまずいのか
IAMロールは、ヘルメットのようにIAMユーザーやAWSサービスが被って使用することができるというように説明されることがあります。
しかし、この例えではロールセッションの概念が省略されているため、ロール自身が直接使用されてアクションの実行主体になるという誤解が生まれます。
アクションの実行主体は、ロールではなく、ロールを引き受けた際に発行されたロールセッションです。
AWSを使い慣れてきたら、早めにロールセッションを理解しておいた方がよいです（自戒）。そうしないと、誰がAWS上のアクションを実行するのかが理解できず、実践的なところでは例えばCloudTrailイベント履歴で「ユーザー名」に何を入力して検索すればいいのかよく分からなくなってしまいます（n敗）。
ヘルメットでないなら何が良いのか
あまり良い例は思いつきませんでしたが、少なくとも直接被って使用するものではないというイメージがあるとよいはずです。
例えば、IAMロールは厳重に保管された「ヘルメットの原本」や「ヘルメットの設計図」 と言った方が、より正確に状況を説明できると思います。
この例を用いてロールの引き受け（AssumeRole）のイメージを説明すると、以下のようになります。
- IAMロール（ヘルメットの原本） は、STS（窓口）が管理していて、持ち出し禁止
- IAMユーザーがSTSに対して、ロールを引き受けたい（
AssumeRoleしたい）と申し出る - STSは、IAMロールの信頼ポリシーなどを確認して、その資格があると確認できたらIAMロールセッション（ヘルメットの複製） をIAMユーザーに渡す
- IAMユーザーはIAMロールセッションを使って、許可されたアクションを実行できる
- IAMロールセッションは一定時間経つと消滅する
まだうまく表現できていないこと
実際にはロール/ロールセッションを被ったり使ったりするのではなく、ロールを元にして力を得た式神（ロールセッション）が生まれ、その式神がアクションの主体となる、というイメージが実態に近そうです。さながら、ロールは紙人形でしょうか。
参考：IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
おまけ：ロールセッション名について
IAMロールを引き受けてからアクションを実行すると、その主体はIAMロールセッションになります。
ロールセッションは arn:aws:sts::123456789012:assumed-role/role-name/role-session-name という形式のARNを持ちます。このうち最後の部分がロールセッション名です。
ロールセッションが実行したアクションが、CloudTrailで記録されると、レコードの userIdentity.arn はロールセッションARNになり、CloudTrailイベント履歴で検索できる「ユーザー名」はロールセッション名になります。
ロールセッション名は、AssumeRole APIを実行する際の必須の引数（RoleSessionName）です。つまり、ロールを引き受けるときにリクエスターが決めています。マネジメントコンソールでスイッチロールしたときは、自動的にユーザー名がロールセッション名になります。Lambdaが関数に設定されたロールを引き受けるときは、関数名がロールセッション名になります。
AWS CLIで、プロファイルを使用してIAMロールを引き受けたときは、自動的に botocore-session-1609426800 のような名前がロールセッション名になります。この値は自分で設定することができるため、設定しておくとCloudTrailログの検索・追跡が楽になります。
参考：AWS CLIがAssumeRoleする際のセッション名を指定する | DevelopersIO
あとがき
IAMロールセッションや AssumeRole という概念を少し理解できて嬉しかったので、その勢いで記事を書きました。どうにも不正確な説明が混ざっている気がしています。もし気が向いた方がいましたらご指摘ください。
Discussion