【PART11 IAMロール】ぜんぜんわからなかったIAMについてまとめてみました
こんにちはこぐまです。
ぜんぜんわからなかったIAMシリーズ、しばらくお休みしておりました。
またぼちぼちつづけていきたいと思います。
前回までで、IAMユーザ、IAMグループ、IAMポリシーを説明してきました。
特にIAMポリシーの部分に関してはかなり細かくお話してきました。
今回からはIAMの最後の要素、「IAMロール」についてお話しします。
IAMロールって実はそんなに難しくもない
自分もそうでしたが、IAMロールってとにかくとっつきにくいイメージがあります。IAMユーザー、IAMグループ、またIAMポリシーというのは、なんとなく名前からイメージがつきやすいですね。
・・ロールという言葉がとっつきにくいのでしょうか？
ロールとは「役割」のこと。
昔、AWSの営業さんとお話ししているとき、「こぐまさんのロールはなんですか？」と質問を頂くことがありました。
結局のところ「あなたの（会社での）役割はなんですか？」ってことなんですが、（今では慣れましたが）このロールという言葉は当時の自分にはかなり新鮮に響きました。
上記の通り、ロールとは役目・役割のことです。
そして、「IAMロール」とは「誰かに役割を与えるため」に使います。
AWSでのIAMロールの考え方
AWSでは、IAMロールのイメージアイコンとして、「ヘルメット」が採用されています。これも役割という意味合いを込めてなのかなと思います。
そしてこの「ヘルメット」ですが、普通のヘルメットじゃないんです。
実はこのヘルメットには魔法がかかっているのです。それは・・
「このヘルメットをかぶると、かぶった人はヘルメットに秘められた力を手にすることができる。ただし・・・もともと持っていた能力を奪われる・・」
うーん、恐ろしいですね・・。
でも、この「奪われる」というのが、IAMロールの真髄であり最高のメリットなんだと思います。
IAMロールについて、一番わかりやすくて面白いのは以下の記事かなと思います。IAMロールをお面として表現していてイメージしやすいです(笑) 私もかなり参考にさせていただきました。
では、IAMロールをもう少し細かく見てみます。
「IAMロール」には、「許可ポリシー」、「信頼ポリシー」、「境界ポリシー」がアタッチできる。
以前作成した絵を見てみます。
このなかで、IAMロールにかかる水色の矢印を見てみると、
「③手紙を渡すときの呼び方」として、すべてのパターンがつながっていることがわかります。許可ポリシー、信頼ポリシー、境界ポリシーです。
このうち、「許可ポリシー」はその名の通り、実際に許可したいアクションを記載するためにあり、「境界ポリシー」は（必要に応じて）その範囲を制限するためにあるので、まあなんとなくイメージがわきます。
・・私がどうしてもわからなかったのは、「信頼ポリシー」です。
IAMロールの「信頼ポリシー」ってなんだ？
「信頼ポリシー」という呼び方は、（私の説明の中では）「③手紙をアタッチするときの呼び方」に存在している名前です。
そして、さらにその水色の矢印を前にたどっていくと、「①手紙の使用用途」での呼び方として、「リソースベースのポリシー」にたどり着きます。
つまり「信頼ポリシー」というのは「リソースベースのポリシー」なんです。
ところで、「リソースベースのポリシー」ってなんでしたっけ？
「アイデンティティベースのポリシー」と何が違うんでしたっけ・・？
「リソースベースのポリシー」とは「AWSリソースと紐付くポリシー」
以前お話しした通り、「アイデンティティベースのポリシー」というのは、IAMエンティティ（IAMユーザ、IAMグループ、IAMロール）に紐付きます。上記の絵の通りです。
「リソースベースのポリシー」というのは、IAMエンティティではなく、AWSリソースに紐付きます。（S3とかECRとかです。これは、上記の絵には記載していません。）
・・だけど唯一の例外がある。
ところが、（私が思うに）唯一の例外があって、
IAMエンティティのうち、IAMロールに対してだけは、リソースベースのポリシーをアタッチできます。その時、特に「信頼ポリシー」と呼ぶのです。
繰り返しになりますが、「リソースベースのポリシー」は本来「IAMエンティティ」ではなく、「AWSリソース」に紐付くためのポリシーです。
だから通常IAMエンティティには、リソースベースのポリシーをアタッチすることはできません。しかし、IAMエンティティのなかで唯一IAMロールだけが、リソースベースのポリシーをアタッチできるのです。そしてそのアタッチしたポリシーを「信頼ポリシー」と呼ぶのです。
私はこの事実（・・事実なのかわからないけど(笑)）に気づくまでにとても時間がかかりました。
つまり「IAMユーザ、IAMグループ」と「IAMロール」の最大の違いは、「リソースベースのポリシーをアタッチできるのかできないのか？」
だと思っています。
じゃあ、そのリソースベースのポリシー（信頼ポリシー）は何のために使う？
IAMロールとIAMユーザの違いが理解できたところで、
じゃあ、IAMロールだけにアタッチできるリソースベースのポリシー（信頼ポリシー）は何のために使うのでしょうか？
それは一言でいうと、
「ヘルメットをかぶることができる相手を指定するためだけに使う」
・・これだけです。なんとなく「信頼ポリシー」という言葉の意味も
ジワジワ効いてくる気がしますよね。
ヘルメットには特別な秘められた力が込められています。
そのヘルメットをかぶれば、（元の力を失う代わりに）そのヘルメットに備わっている特別な秘められた力が発揮できます。誰にでも渡していいものではないですね。だから信頼に足る存在だけにそのヘルメットを渡すのです。
その相手を「信頼ポリシー」として記載します。
信頼ポリシーを見てみよう
ではなんでもいいので、IAMロールにアタッチされている信頼ポリシーを見てみましょう。以下は、RDS作成時にモニタリングを有効にする場合、自動で作られるIAMロール（rds-monitoring-role）です。
信頼ポリシーは、IAMロールの「信頼関係」というタブの部分で確認できます。（これが意外にわかりにくいんですよね・・「信頼ポリシー」ってタブにして欲しい・・）
IAMロールにアタッチされた「信頼ポリシー」である。
大事なのは、「Principal」と「Action」である。
さて、この信頼ポリシーにはいろいろ書かれていますが、大事なのは2点です。「Principal」と「Action」です。
まず「Principal」について説明します。以前IAMポリシーのところで説明したとおり、「リソースベースのポリシー」には、「手紙を受け取る相手（プリンシパル）」が必要でした。信頼ポリシーもリソースベースのポリシーなので、Principal要素は必須です。そしてそれがそのまま、ヘルメットを安心して渡す「信頼する相手」となります。
例えばここでは、「monitoring.rds.amazonaws.com」というAWSサービスが「信頼する相手」ということです。
続いて、「Action」です。
これはなんでしょう？これが相手に許す「秘められた力」なんでしょうか？
他のIAMロールの信頼ポリシーを見てみればわかりますが、どれもほぼ同じく「sts:AssumeRole」と書かれています。
・・どうやら実際に渡したい力ではなさそうです。
ヘルメットをかぶる行為そのものを「AssumeRole」という。
先ほど書いたように、IAMロールの「信頼ポリシー」に記載のある「Action」要素ですが、どれも同じように記載されています。
「"Action" : "sts:AssumeRole"」
これは信頼する相手（Principal）にどのような行動（Action）を許しているのでしょう？
じつは、これは「ヘルメットをかぶる行為そのもの」を許しています。
「sts:AssumeRole」というのは、「ヘルメットをかぶる」行為です。
さきほど、信頼ポリシーは何のために使うかということを一言で、
「ヘルメットをかぶることができる相手を指定するためだけに使う」
とお話ししましたが、正確には、以下の表現が正しいかと思います。
信頼ポリシーは「信頼する相手を指定（Principal）し、その相手にヘルメットをかぶる行為そのものを許可する（sts:AssumeRole）」ということだけを記載しています。（※）
（※）実際ヘルメットは永久的にかぶりつづけられるわけではありません。これもIAMユーザとIAMロールの顕著な違いです。
「sts:AssumeRole」アクションは、このヘルメットの秘められた力を利用するための一時的にしか利用できない認証セットを準備します。これはまた機会があればまとめてお話ししようと思います。
では、ヘルメットをかぶった相手が使える「秘められた力」はどこに書く？
IAMロールの「信頼ポリシー」は「リソースベースのポリシー」であり、
そこには、このヘルメットを信頼して渡す相手と、そのヘルメットをかぶる行為を許す旨が書かれています。
「信頼ポリシー」の中の「Action」は、ヘルメットをかぶることそのものだけを許す記載があり、ヘルメットをかぶったものが発動できる秘められた力については書きません。では、その秘められた力はどこに書くのでしょう？
これは、IAMロールの「許可」のタブの部分（許可ポリシー）に記載します。これがヘルメットをかぶって実際に発揮できる秘められた力です。
発揮できるポリシー（ポリシーの中に書かれているアクションが実行できる）
つまり、IAMユーザの時と同じですね。言い方が違うだけです。
IAMユーザの時はこのタブは「権限ポリシー（Permissions Policies）」と呼んでいました。そこにアタッチされたポリシーが、実際の権限（使える力）でした。
アクセス権限というタブの「権限ポリシー（Permissions Policies）」というのが、
IAMロールでの「許可ポリシー」に相当する。
なぜこの名前が違うのかは謎・・。
IAMロールでは同様にそれが「許可」タブの下の「許可ポリシー」になっているというだけです。
IAMユーザーでも、IAMロールでも、秘められた力を使うための書き方は（タブの名前が違うだけで）変わらないということですね。
結局IAMユーザーでもいいじゃん。IAMユーザーとIAMロールって何が違うの？
マニュアルにも、IAMロールは、権限を与えるという意味では、IAMユーザーと同じ・・というニュアンスで書かれてあります。
IAMロールがIAMユーザと違う部分はなんでしょうか？そして、それはどんなメリットがあるのでしょうか？
IAMユーザがIAMロールと異なる点について見てみます。
実際に「自分自身」がIAMユーザ、IAMロールを利用するシチュエーションを考えてみます。
【自分自身がIAMユーザ、IAMロールを利用するシチュエーション】
１．自分がIAMユーザを利用する場合
→ これは自分用のIAMユーザーをつくり、適切な権限を「権限ポリシー」に記載します。または必要に応じてIAMグループに所属したりします。
２．自分がIAMロールを利用する場合
→ まず別のIAMユーザでログインし、IAMロールを利用するために「ロールの切り替え」を行います。ロールの切り替えは、アカウントの右上プルダウンから選択できます。
色も選べる。（もう少し多いといいですね！）
つまり、結構大事なことだと（自分は）思うんですけど、
自分自身が利用する場合は、いきなりIAMロールを利用することはできないんです。IAMユーザの場合は、AWSマネジメントコンソールにログインし、
そのIAMユーザの権限ポリシーにアタッチされているポリシーに書かれている許可されているアクションがそのまま利用できます。
しかし、自分自身がIAMロールを利用する場合は、まず別のIAMユーザでログインし、ロールの切り替え（スイッチロール）をしない限り、IAMロールの力（ヘルメットの秘められた力）を利用することはできないのです。
なので、自分自身が利用する場合、わざわざひと手間かけてまでIAMロールを利用するメリットはあまりないように思えます。
じゃあ、IAMロールって何のためにあるの？
自分自身が利用する場合のメリットがあまりないのであれば、自分自身じゃない別の存在が利用するメリットがあるということですね。
むしろそれがなければ存在価値がありません・・。
実例をみれば結構その通りで、IAMロールはそのほとんどが「AWSサービス」に対して利用されています。「自分自身」ではなく「AWSサービス」です。実際、IAMロールの「信頼ポリシー」の「Principal」要素には、ほとんどがAWSサービス名のARNが記載されています。先ほどのRDSのモニタリングロール（rds-monitoring-role）もそうでしたね。
それでは、別のAWSサービスがIAMロールを利用するメリットはどこにあるのでしょう？大きく分けると以下2点です。
【別のAWSサービスがIAMロールを利用するメリット】
１．アタッチが簡単
何かしらのAWSサービス作成時のウィザード画面で自動で作成され、そのままサービスにアタッチできるようなつくりになっていることが多い。
２．明示的なスイッチロールが不要
ロールを付与されたAWSサービスが、ロールに秘められた力を利用したい場合、そのロールへ切り替えるみたいな明示的なユーザ操作が不要
利用するという観点では、単純に自分自身で使うよりも簡単に使いやすいという面でAWSサービスに利用されています。
とはいえ、自分自身で使うにしてもメリットはある。
自分自身でIAMロールを使うメリットは、あまりないと先ほど話しましたが、ことセキュリティ面では大きなメリットはあります。
そのメリットとは・・
【自分自身がIAMロールを利用する際のセキュリティ的なメリット】
１．IAMロールを利用することで許可する行動を制限することができる。
→ IAMロールにスイッチすればその許可ポリシーに書かれたこと（秘められた力）しか発揮できない。もともと持っていた力は発揮できない。
つまり、最初にログインするIAMユーザーには必要最小限の権限しか持たせず、スイッチロールすることで、必要に応じた権限（EC2を見る、IAMを管理する、DBを構築するなど）の範囲での行動を許可する・・ということができます。
２．マルチアカウントを持っていて、メインアカウント以外はすべてスイッチロールした後に操作するという運用を実現できる。
→ こうすることで、たくさん存在するAWSアカウントごとに、自分自身がログインするために必要なIAMユーザーを準備する必要がなくなります。
特に２は一般的かと思います。私も業務でAWSアカウントを複数持っていますが、最初にログインするアカウントは一つだけで、他のAWSアカウントのマネジメントコンソールはすべてスイッチロール経由で操作します。詳しい実装方法についてはいくつかサイトもあります。私も後日紹介しようかなと思っています。
1に関しては同一アカウント内でも実装可能です。自分自身がIAMロールを利用するというシチュエーションをいろいろ検証してみると、IAMロールはやはり「アイデンティティベースのポリシー」と「リソースベースのポリシー」の両方を持っていることがよくわかります。
これについては次回紹介したいと思います。
本日はここまで！
読んで下さってありがとうございました！