今回はAWSにおけるIAMロールとポリシーの違いについて整理していきたい。
AWSのIAMとは「Identity and Access Management」の略で、AWSの操作を行うユーザーや権限を一元管理するためのサービスだ。
IAMには下記4つの重要な要素がある。
- IAMユーザー
- IAMグループ
- IAMポリシー
- IAMロール
上記4要素の内、ユーザーやグループは比較的イメージがつきやすいのだが、IAMロールとIAMポリシーについてはAWSを使い始めた時の私は大混乱していた(笑)。
そのため、今回は備忘録もかねて、IAMロールとIAMポリシーの違いに焦点を当てて私が理解してきたことを整理していく。
Contents
IAMポリシーとは？
IAMポリシーは「AWSのどのリソースに対してどのような操作を許可するか？」という権限を定めたものだ。
「AWSのリソース？？」とまずここで私はつまづいたのだが（笑）、AWSのリソースというのは例えばEC2インスタンスとかS3バケットのことをイメージするとわかりやすくなる。
例えば、下記はデフォルトで用意されている「AmazonS3FullAccess」というポリシーを表示した例だが、これは簡単に説明すると「S3というAWSのリソースに対して全ての操作権限を許可する」というポリシーだ。
各ポリシーの内容は上記のようにJSON形式で記載されている。
今回はIAMロールとIAMポリシーの違いに焦点を当てたいので、設定内容の詳細については踏み込まないが、JSON形式により、「どのAWSサービスに対してどのような権限を付与するか？」「どういう条件の時にこのポリシーを発動させるか」などが書かれている。
IAMポリシーの3つの分類
IAMポリシーは実は下記のように3つのポリシーに分類することができる。
- AWS管理ポリシー
- カスタマー管理ポリシー
- インラインポリシー
AWS管理ポリシーはあらかじめ各AWSサービスを利用するためにAWS側で用意してくれているポリシーだ。
先ほど例に挙げた「AmazonS3FullAccess」もAWS管理ポリシーの1つだ。
AWS管理ポリシーは「AWSサービス名＋FullAccess」とか「AWSサービス名＋ReadOnlyAccess」というようなポリシー名が多い。
AWS管理ポリシーは1000個以上も用意されているが（23年7月時点で）、ユーザー側で編集することはできない。
そのため、より細かく権限を制御したいという場合はユーザー自身で作成・編集が可能なカスタマー管理ポリシーやインラインポリシーを使っていくことになる。
本記事ではこれ以上3つのポリシーの違いについてはこれ以上は触れないが、それぞれの特徴は下記の通りだ。
| No | ポリシー分類 | 作成者 | 概要 |
| 1 | AWS管理ポリシー | AWS | ・AWSによってデフォルトで用意されているIAMポリシー ・複数のIAMユーザーやIAMグループ、IAMロールで使いまわしが可能 ・ユーザーは編集不可 |
| 2 | カスタマー管理ポリシー | ユーザー | ・ユーザーが作成するIAMポリシー ・複数のIAMユーザーやIAMグループ、IAMロールで使いまわしが可能 ・ユーザーによって追加/削除/修正が可能 |
| 3 | インラインポリシー | ユーザー | ・ユーザーが作成するIAMポリシー ・複数のIAMユーザーやIAMグループ、IAMロールでの使いまわし不可 ・ユーザーによって追加/削除/修正が可能 |
IAMポリシーは単体では利用できない
IAMポリシーはそれ単体では利用することが出来ない。
IAMユーザーやIAMロールなどの権限を与える対象に対してIAMポリシーをアタッチ（適用）することで初めて利用することが出来る。
例えば、AWS管理ポリシーの１つである「AmazonS3FullAccess」というポリシーはそれが存在するだけでは何の効果も発揮しない。
このポリシーを「A」というIAMユーザーにアタッチ（適用）することで初めて「AmazonS3FullAccess」というポリシーは効果を発揮できるようになるのだ。
IAMポリシーは上記例のようにIAMユーザーにアタッチすることも出来るし、ユーザーをまとめたIAMグループ、後述するIAMロールにもアタッチして利用することが出来るようになっている。
ただし、AWSリソース（EC2やS3等）に直接アタッチすることはできない。
そのため、対象のAWSリソースから別のAWSリソースに対して何か操作をさせたい場合はこれから紹介するIAMロールが必要になってくる。
IAMロールとは？
IAMロールはあるAWSリソース（EC2とかLambda等）に対して、他のAWSリソース（S3とかAurora等）を操作する権限を認可する仕組みのことだ。
AWSにおいて、AWSリソース（EC2とかS3などを指す）を操作する主体としては大きく下記2つに分類できるのだが、
- IAMユーザーがAWSリソースを操作する場合
- AWSリソースが別のAWSリソースを操作する場合
IAMロールが必要になるのは、2の「AWSリソースが別のAWSリソースを操作する場合」だ。
例えば、「あるEC2インスタンスからS3にアクセスできるようにしたい」という場合を考えてみよう。
これがもし「あるIAMユーザーがS3にアクセスできるようにしたい」という場合であれば、前述したようにそのIAMユーザーにS3のアクセス権限を定めたIAMポリシーを直接アタッチすれば解決する。
しかし、IAMポリシーはAWSリソースに対して直接アタッチすることが出来ない。
※例外はあるのだが、ややこしくなるので本記事では割愛する
では、AWSリソースに対して権限を付与するにはどうすればいいのか？
ここでIAMロールの出番となるわけである。
IAMロールはIAMポリシーと異なり、AWSリソース（EC2とかLambda等）に直接アタッチすることが出来る。
そして、このIAMロールには必要な操作権限を定義したIAMポリシーを複数アタッチすることが出来るのだ。
つまり、「EC2からS3を操作したい！」という場合は、例えば下記のような「EC2forS3FullAccess」という名称のIAMロールを作成し、S3の操作権限を定義したIAMポリシー（今回はAmazonS3FullAccess）をそのIAMロールにアタッチする。
そして、そのIAMロールを対象のEC2にアタッチすれば、該当のEC2からS3にアクセスをすることが出来るようになる。
このようにIAMロールはAWSリソースが別のAWSリソースを操作できるようにするために使われる。
1つのAWSリソースに対してIAMロールは1つのみアタッチできる
1つのAWSリソースにアタッチできるのは1つのIAMロールだけだ。
例えば、あるEC2に「A」というIAMロールがアタッチされていた場合、「B」というIAMロールを同じEC2にアタッチすることはできない。
もし「B」というIAMロールをEC2にアタッチしたい場合は、「A」のIAMロールを外して、「B」のIAMロールをアタッチする必要がある。
「じゃ対象のEC2に追加のアクセス権を付与したい場合はどうすればいいの？？」
という疑問が出てくるかもしれない。
その場合は対象のEC2にアタッチされているIAMロールに対して付与したいアクセス権が定義されたIAMポリシーを追加でアタッチすればOKだ。
IAMポリシーは1つのIAMロールに対して複数アタッチすることが出来るので、既にEC2にアタッチされているIAMロールに必要なアクセス権が定義されたポリシーを追加でアタッチするのだ。
紛らわしいのだが、同じIAMロールを複数のAWSリソースにアタッチする（使いまわす）ことは可能だ。
例えば、AというEC2とBというEC2に同じIAMロールをアタッチすることは出来る、という意味である。
IAMロールとポリシーの違い
最後にこれまで説明してきたIAMロールとポリシーの違いを整理すると下記の通りだ。
| 概要 | アタッチ先 | アタッチ先への適用可能数 | |
| IAMロール | 対象のAWSリソースが他のAWSリソースを 操作する権限を認可する仕組み | AWSリソース （EC2やLambda等） | 1つのAWSリソースに対して1つのみ |
| IAMポリシー | 「AWSのどのリソースに対してどのような操作を 許可するか？」という権限を定めたもの | IAMユーザー/IAMグループ/ IAMロール | 同じIAMロールやIAMユーザーに複数適用可能 |
IAMロールはIAMポリシーをグルーピングして対象のAWSリソース（EC2など）に権限を付与するものだとイメージすると2つの違いが整理しやすくなるだろう。
