こんにちは。プロダクト開発部でクラウドインフラエンジニアとして業務を行っている高澤です。
AWS構築・運用にてIAMロールを使用する機会は多くありますが、細かい設定・状況による違いがあり、混乱している方も多いのではないでしょうか。
実は「日常でよく使うIAMロール利用パターン」は限られており、すべての設定・詳細を熟知しなくても問題ありません。
それら「日常でよく使うIAMロール利用パターン」を紹介するにあたり、IAMロールは単体の機能ではなく、関連サービスや前提を抑えたのちに理解するのがスムーズであるため、前編・後編に記事をわけました。
まず前編である本記事では、主に「IAMロールとは何か」についての概要を説明し、後編では「IAMロールの利用パターン」について具体的な例を紹介する予定です。
この記事がみなさまのIAMロール理解の一助となれば幸いです。
目次
- この記事の目的
- IAMロールとは何か
- AWS Identity and Access Managementについて
- ポリシーとは何か
- ポリシーを設定できる対象について
- IAMロールの位置付け
- IAMロールとIAMユーザー（またはAWSリソース）の違いは何か
- IAMロールを設定できる対象について
- ロールを利用する、とはどういうことか
- IAMロールの利点とは
- 前半のまとめと次回予定
- 参考URL
この記事の目的
IAMロールについて、主要な利用パターンを把握し、利用シーン・利用方法が容易に理解できる、ということが目的です。
前編はその前提となる「IAMロールとは何か」の解説となります。
詳細な網羅・例外の説明は対象外とします。
IAMロールとは何か
まず、そもそもIAMロールとは何か、について説明します。
IAMロールは「AWS Identity and Access Management」（略称IAM）の機能の一部です。
IAMがどのようなサービスなのか、から話を進めていきます。
AWS Identity and Access Managementについて
AWS Identity and Access Managementについて、AWS Identity and Access Management のドキュメントから抜粋します。
AWS のサービスへのアクセスをセキュアに制御するためのウェブサービスです。IAM を使用すると、ユーザー、セキュリティ認証情報 (アクセスキーなど)、およびユーザーとアプリケーションがアクセスできる AWS リソースを制御するアクセス許可を集中管理できます。
となっています。
ざっくりまとめます。
「AWSサービスの利用権限を管理するサービス」
です。
そして、利用権限の定義は「ポリシー」というもので行います。
ポリシーとは何か
ポリシーを日本語に訳すと「規定」であり、IAMでは「アクセス許可の設定」のことを指します。
権限の設定内容、と捉えると良いのではないでしょうか。
具体的にはポリシーは 「JSONで書かれたドキュメント設定」 として作成・管理されます。
では、このポリシー（つまりアクセス許可の設定）は何に対して設定できるのでしょうか。
ポリシーを設定できる対象について
ポリシーを設定することを「ポリシーをアタッチする」と言います。
ポリシーは「権限の設定内容」です。
そのため、ポリシーを使う対象にアタッチし、対象がどのようなアクセス許可（許可・拒否）を持っているのか、を規定できます。
つまり、権限の設定をしたい対象のみにアタッチできるということですね。
（権限が関係ないものにアタッチはできない。では権限が関係するものは何なのか、ということです）
さて、そのポリシーをアタッチできる対象です。
「アイデンティティ（ユーザー、ユーザーのグループ、ロール）やリソース（AWSリソース）」 となっています。
「アイデンティティ」の対象である「ユーザー、ユーザーのグループ」についてはイメージしやすいですが、 「ロール・リソース」がちょっとわかりにくいですね。
ロールについては後ほど説明しますが、AWSリソースの具体例はどういったものがあるか記載します。
AWSリソース で、よくアタッチするリソースの例としては以下です。
- S3
- APIGateway
- CloudWatch Logs
AWSコンソールなどで、S3のポリシーを作成する、ということをよく実施するのではないでしょうか。
注意点としては AWSリソース はAWSに存在するすべてのリソースではなく、特定のリソースです。
こちらに一覧があります（リソースベースのポリシー で はい となっているものです）
IAMロールの位置付け
上記で説明したポリシーについて、の説明「アイデンティティ（ユーザー、ユーザーのグループ、ロール）に付与（アタッチ）できます」というところで「ロール」がでてきました。
このロールはもちろんIAMロールのことですが、ロールとはなにか、というと、日本語に訳した通り「役割」となります。
役割自体には操作する主体が存在しないので、その役割を担う主体がユーザーか、ユーザーのグループか、と考えるのが分かりやすいです。
何らかの操作・作業がしたい場合に、その権限を付与したロール（役割）を定義します。
そして、そのロール（役割）を「操作をする主体」に付与すると、操作をする主体が「その役割を担うことができる」ということです。
IAMロールとIAMユーザー（または AWS リソース）の違いは何か
IAMロールとIAMユーザー（またはAWSリソース）の違いを簡単に書きます。
- IAMロールは「役割」の定義であるため、IAMロール自体は操作をしない
- IAMユーザー（またはAWSリソース）は操作をする主体
です。
つまり、IAMロールはユーザー または AWSリソース に付与された場合効果を発揮する、ということになります。
IAMロールを設定できる対象について
では、このロールは何に付与（アタッチ）できるのでしょうか。
「ロールをそのまま利用できる形」でアタッチできるのは「リソース（AWSリソース）」だけです。（そう振る舞う、ということで、内部の仕組みは省きます）
ここで「ユーザーやグループなどにもできるのではないか」という疑問が湧きます。
ユーザーやグループなど には、 「ロールをそのまま利用できる形」ではなく、 「ロールを利用できる（ロールを引き受けることができる）」という指定ができます。
ここはわかりにくいところなのでしっかり説明します。
上で説明した通り、ロールの「基本的な使い方」は、「リソース（AWSリソース）にアタッチし、リソースがそのロールの権限でAWSサービスを利用できるようにする」というものです。
アイデンティティ（ユーザー、ユーザーのグループ、ロール）には、「ロールを利用できる（ロールを引き受けることができる）」という権限をつけられます。
この場合は、リソース（AWSリソース）とは違い、ロールの権限は、「自動的に使える状態」にはなりません。
では、どう利用するかというと、利用するタイミングでロールを引き受けたい、というアクションを実行し承認されると一時的にそのロールの権限でAWSサービスを利用できるようになります。
「ロールを引き受けたい、というアクションを実行」の詳細です。
Security Token Service の AssumeRole という操作にて、このロールを引き受けたい、というアクションを行うということになります。
AssumeRoleについては次のセクションで説明します。
ロールを利用する、とはどういうことか
ここまで、ロールを利用する、といってきましたが、具体的にどう利用をするのかを説明します。
リソースがロールを利用する場合
リソースにロールをアタッチ（付与）すると、リソースからロールに付与されているポリシーで許可された操作が可能になります。
リソースがロールで利用を許可された別のロールを利用する場合
ロールに別のロールの利用許可がついている場合（sts:AssumeRole で、別のロールの利用許可がついている場合）は、そのままでは別のロールについている利用許可は使えません。
なぜなら、別のロールになれる、という権限がついているだけであるためです。
別のロールに許可されている操作をする場合には、 sts:AssumeRoleを行い、そのロールを引き受ける操作を実施する必要があります。 別のロールを引き受けることにより、一時的にその別のロールの権限で操作ができます。
注意としてその場合に主体ができる権限は 操作の主体がなにか、によって挙動が変わります。
たとえばユーザーがスイッチロールで別アカウントへ遷移する場合は、 スイッチロール先のアカウントでは、元のアカウントで許可されていた操作はすべてできず、 引き受けたロールの操作のみが可能となります。
プログラムなどでそのような動作になるとしたらこまりますね。
その場合、引き受けたロールで一時的なクレデンシャルを発行し、そのクレデンシャルを使用して操作をしたいクライアントを作成して何らかの操作をすることになります。
元の操作をできるクライアントも生きているが、ロールを引き受けて別のロールの権限での操作が可能なクライアントもいる、 というイメージです。
IAMロールの利点とは
ここまでIAMロールを説明してきましたが、 そもそも、IAMロールにはどのような利点があるのでしょうか。
利点の大きい順に書いていきます。
1.リソース(AWS リソース)につけられる
一番の利点であり、IAMロールの主要な利用方法です。 AWSリソースには直接権限を付与できませんが、ロールを付与することで、AWSリソースが主体として振る舞う際に、ロールの権限を利用できます。
具体例:EC2,FargateやRDSなどのリソースにアタッチでき、リソースによる操作にロールの権限が利用されます。
2.一時的に使える許可を取得できる(AssumeRoleの場合)
ロールではなく、ポリシーを付与した場合には、常時許可された状態になります。
ですが、ロールを利用することにより、常時ではなく、使う時のみ一時的に権限を取得して利用ができます。
そのため、高い権限を利用するアプリケーションなどの場合、利用シーンを限定することによって安全性を高めることができます。
3.アカウント間で使える(AssumeRoleの場合)
アカウント間での権限許可をロール以外で行う場合、以下の2つが可能です。
- ユーザーを作成してそれぞれログインする
- 特定のユーザーの操作を双方のアカウントで許可する
これらは個別に設定する必要があるため、管理が煩雑になります。
ロールであれば、許可したい側のアカウントで権限を指定し、管理ができます。
許可された側のアカウントでも、ロールの使用を許可するグループ、ポリシーによって、使えるユーザー・リソースを柔軟に管理できます。
4.役割であるため、ロールの利用を許可しておけば、都度切り替えて利用できる
あるアカウントのアプリケーションが別のアカウントA・Bのロールを利用する場合、ロールであれば、特定の操作をする際にロールを引き受けて利用できます。
途中で利用するリソースが変わった場合も、ロールであるならば付け替えやロールの利用を複数許可できます。
もしも操作対象としてアカウントCが増えた場合も、使えるロールを増やすだけで操作が可能となります。
前半のまとめと次回予定
以上、まずはIAMロールの説明、および利用できる対象とその特徴について説明してきました。
今回この記事を作成するにあたり、知っているようでよく考えるとなんだろう、ということも多かったため、知ったあとはその内容を他の人に説明できるとより内容理解の助けになると思われます。
説明した内容の理解確認として、以下を簡単に説明できると良いです。
- IAMサービスとはどういうものか
- IAMポリシーとは何か
- IAMロールとは何か
- IAMロールとIAMユーザー（またはAWSリソース）の違いは何か
- IAMロールを設定できる対象は何か
- AssumeRoleについて日本語で説明すると
後編では以下について、よくある例を交えて具体的にイメージできるような記事を書く予定です。
- IAMロールの利用パターン一覧
- IAMロールの利用パターンの具体的な例、および設定・利用方法
乞うご期待ください。
参考URL
以下、参考にした記事です。
スイッチロールなしで別アカウントの S3 バケットにマネジメントコンソールからアクセスしてみた
AWS初心者にIAM Policy/User/Roleについてざっくり説明する
Principal 要素で IAM ロールを指定するのと IAM ロールを引き受けたセッションを指定するのは何が違うのか？ 72 個のパターンで考えてみた
AssumeRole（スイッチロール）を理解して、AWSへのデプロイを少しでも安全に実施しよう #devio2021
