コーヒーが好きな木谷映見です。
今日はスイッチロールの概念と設定方法についてまとめていきます。
具体的な設定方法を知りたい方は「スイッチロールの手順」をご参照ください。
スイッチロールとは?
ざっくりとしたイメージ
「人んちの帽子をかぶったら人んちで遊べるようになるんだ!」
家族以外の人がBさんの家でゲームをするには、Bさんの家の帽子をかぶってBさんの家にお邪魔する必要があります。AさんはBさんの家の帽子を借りて、Bさんの家に行ってゲームで遊びます。
「帽子を借りて、Bさんの家でゲームする」の動作を、スイッチロールのイメージとお考え下さい。
真面目なイメージ
スイッチ(切り替え)ロール(役割)
AWS のドキュメントを英語で見ますと 「Switching to a role (console) 」と書かれています。画面右上で言語を切り替えると「ロールの切り替え(コンソール)」と和訳されます。
スイッチロールとは、IAM ロールを切り替えることを指します。
と言ってもピンとこないと思いますので、スイッチロールのイメージ図を見てみましょう。
スイッチロールのイメージ
まず、スイッチ元アカウントAのユーザが、スイッチ先アカウントBのEC2コンソールを閲覧したいなあと思っています。しかし、このままではアカウントをまたいでのアクセスはできません。
スイッチ先アカウントBのEC2コンソールを閲覧するために、以下の準備をします。
- スイッチ先アカウントBに、IAM ロールを作成する
- 作成した IAM ロールに、以下 2種のIAM ポリシーを付与する
- スイッチ先アカウントBの EC2 コンソールを閲覧するポリシー
- スイッチ元アカウントAの IAMユーザを信頼するポリシー
- スイッチ元アカウントAのユーザに、以下のIAM ポリシーを付与する
- スイッチ先アカウントBの IAM ロールを引き受けることを許可するポリシー
スイッチ元アカウントAのユーザが、スイッチ先アカウントBの IAM ロールを引き受けます。 スイッチ元アカウントAのユーザは、スイッチ先アカウントBのEC2コンソールを閲覧することができるようになります。
「帽子をかぶって力を得る」
IAM ロールのアイコンは帽子の形をしています。この帽子のイメージの通り、スイッチ元アカウントAのユーザが IAM ロールという帽子をかぶるイメージをしていただくと分かりやすいかと思います。
スイッチ先アカウントBの IAM ロールという帽子をかぶることで、帽子に宿ったスイッチ先アカウントBの操作権限を得ます。
IAM ポリシーの種類
スイッチロールについて理解するために、以下の IAM ポリシーについてご説明していきます。
IAM ポリシーとは、AWS サービスにアクセスするための権限です。実行できるアクション、リソース、および条件を制御します。
IAM ポリシーにはいくつかの種類があります。ここでは以下の3つを取り上げます。
- アイデンティティベースのポリシー
- リソースベースのポリシー
- IAM ロールの信頼ポリシー
アイデンティティベースのポリシー
アイデンティティベースのポリシーには、以下の特徴があります。
- IAM ユーザ、IAM ユーザーグループ、 IAM ロールにアタッチする
- 操作主体(誰が使うか)は関連付けられた「IAMユーザ」「IAMグループ」「IAMロール」のいずれか
- JSON で記述される
- 「IDベースのポリシー」「ユーザーベースのポリシー」と呼ばれることもある
AWS 公式ドキュメントを見ますと、IAM ユーザ、IAM ユーザーグループ、 IAM ロールの3つをまとめて「アイデンティティ」と呼んでいます。それゆえ「アイデンティティベースのポリシー」と呼ぶようです。
リソースベースのポリシー
リソースベースのポリシーには、以下の特徴があります。
- Amazon S3 バケットなど、特定の AWS リソースにアタッチする
- 代表的なものは、Amazon S3 バケットポリシー、 Amazon SQS キューポリシーなど
- 操作主体(誰が使うか)を表す
Principal
の明記が必要 - JSON で記述される
すべての AWS サービスがリソースベースのポリシーをサポートしているわけではありません。リソースベースのポリシーをサポートする AWS サービスの一覧は、 IAM と連携するサービス をご参照ください。
IAM ロールの信頼ポリシー
IAM ロールの信頼ポリシーは、リソースベースのポリシーの一種で、以下の特徴があります。
- IAM ロールに付与する
- IAMロールの権限移譲先(誰が使うか)を表す
Principal
の明記が必要 - 信頼ポリシーで書くアクションは「
sts:AssumeRole
」だけ - 「信頼関係」「信頼ポリシードキュメント」と呼ばれることもある(揺らぎあり)
sts:AssumeRole
とは
英単語の「assume」には「引き受ける」という意味があります。
「IAM ロールを引き受けるアクション」のことを、概ね sts:AssumeRole
と言います。
帽子の形のアイコンにちなんで何度か「IAM ロールという帽子をかぶる」と表現をしていますが、この「かぶる」というアクションをイメージしてください。
sts
とは AWS Security Token Service という一時的認証情報をつかさどるサービスです。実は sts:AssumeRole
というアクションの裏側では AWS STS が一時的な認証トークンを発行してうんたらかんたら…という活躍をしているのですが、今回は触れません。ざっくり「IAM ロールを引き受ける≒ AssumeRole なんだな!」ぐらいの認識で、スイッチロールの概念は理解できるはずです。
IAM ロールに付与されるポリシー
上記の通り、IAM ロールには「アイデンティティベースのポリシー」と「IAM ロールの信頼ポリシー」の二種類のポリシーが付与されます。
- アイデンティティベースのポリシーは「何ができるか」
- IAM ロールの信頼ポリシーは「誰が IAM ロールを引き受けるか(誰が IAM ロールという帽子をかぶるか)」
を制御しています。
スイッチロールをする際の権限まとめ
「スイッチロールのイメージ」で記載した各種ポリシーをもう一度まとめますと、以下の図のようになります。
スイッチロールの手順
スイッチロールの仕組みと各種ポリシーについておさえたところで、実際にスイッチロールの設定をしていきましょう。今回はマネジメントコンソールでスイッチロールします。
スイッチ元アカウントAとスイッチ先アカウントBを行き来しますので、別々のブラウザでログインするなど工夫して、どちらの AWS アカウントにいるのか間違えないようにしましょう。
スイッチ元アカウントA での準備①
スイッチ元アカウントA で、スイッチロールに使う IAM ユーザの ARN コピーしておきます。 IAM コンソールの画面左メニューで[ユーザ]を選択し、スイッチロールに使う IAM ユーザをクリックします。ユーザーの ARN が表示されているので、コピーします。 ついでに、スイッチ元アカウントAの AWS アカウント ID もコピーしましょう。
スイッチ先アカウントB での準備
スイッチ先アカウントBで IAM ロールの準備をします。
IAM ロールを作ります。AWS マネジメントコンソールで IAM の画面に遷移し、[ロール]-[ロールの作成]をクリックします。
まずはIAM ロールの信頼ポリシーを設定します。
- 信頼されたエンティティタイプ:AWS アカウント
- AWS アカウント:他の AWS アカウント
- スイッチ元アカウントAの AWS アカウント ID を入力する
「次へ」をクリックします。
アイデンティティベースのポリシーを設定します。今回は EC2 コンソールにアクセスしたいので、AmazonEC2ReadOnlyAccess
にチェックを入れ「次へ」をクリックします。
IAM ロールの名前を入力します。
「ロールの作成」をクリックします。
IAM ロールができました。
作成した IAM ロールを選択し、ポリシーを確認していきます。[許可]タブをクリックすると、アイデンティティベースのポリシーが表示されます。今回はAmazonEC2ReadOnlyAccess
を付与していますので、以下のようなJSONポリシードキュメントが記載されています。
[信頼関係]タブをクリックすると、IAM ロールの信頼ポリシーが表示されます。現在の信頼ポリシードキュメントは以下のようになっていて、スイッチ元アカウントA のユーザすべてが"principal"
に設定されています。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<スイッチ元アカウントのAWSアカウントID>:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
スイッチ元アカウントA のユーザすべてを許可した状態のままでもアクセスは可能ですが、今回は特定のユーザだけがアクセスするように IAM ロールの信頼ポリシーを修正します。「信頼ポリシーを編集」をクリックし、編集画面に遷移します。
"principal"
に、スイッチ元アカウントユーザのARNを記入して保存します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "<スイッチ元アカウントユーザのARN>" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
スイッチ元アカウントAの特定のユーザしかロールを引き受けないように、IAM ロールの信頼ポリシーを編集しました。 複数のユーザを IAM ロールの信頼ポリシーで許可したい場合は、以下のようにカンマ(,)区切りでスイッチ元アカウントAのユーザのARNを並べて入力すればよいです。
"Principal": { "AWS": [ "arn:aws:iam::AWS-account-ID:user/user-name-1", "arn:aws:iam::AWS-account-ID:user/user-name-2" ] }
最後に、作成した IAM ロールの ARN をコピーしておいてください。
スイッチ元アカウントA での準備②
続いて、スイッチ元アカウントAで IAM ユーザの準備をします。
スイッチ元アカウントAで、ユーザに付与するアイデンティティベースのポリシーを作成します。AWS マネジメントコンソールで IAM の画面に遷移し、[ポリシー]-[ポリシーの作成]をクリックします。
[JSON]タブをクリックすると、最初は以下のようにJSONポリシーの枠だけが存在します。
{ "Version": "2012-10-17", "Statement": [] }
以下のJSONポリシーを貼り付けます。
"Resource"
には、スイッチ先アカウントBで作成した IAM ロールの ARN を入れてください。これは、スイッチ先アカウントBの IAM ロールを引き受けるためのポリシーです。
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "<スイッチ先アカウントの IAM ロールのARN>" } }
「次のステップ:タグ」をクリックし、必要であればタグ付けします。今回はそのまま「次へ」をクリックします。
確認画面でポリシーに名前をつけ、「ポリシーの作成」をクリックします。
IAM ユーザに付与するアイデンティティベースのポリシーができました。
IAM ユーザに、作成したポリシーを割り当てます。画面左メニューで[ユーザ]を選択し、スイッチロールするユーザをクリックします。[アクセス権限]タブで「アクセス権限の追加」をクリックします。
作成したポリシーを選択し「次のステップ:確認」をクリックします。
確認画面が表示されます。「アクセス権限の追加」をクリックします。
IAM ユーザに、ポリシーを追加できました。
スイッチ元アカウントAからスイッチ先アカウントへスイッチロールする
スイッチロールします。
スイッチ元アカウントAのユーザで、右上のユーザ名をクリックして「ロールの切り替え」をクリックします。
以下内容を入力します。
- アカウント:スイッチ先 AWS アカウントID
- ロール:スイッチ先アカウントの IAM ロール名(ARNではない)
- 表示名(オプション):スイッチ後の表示名
- 好きな色を選択
最後に「ロールの切り替え」をクリックします。
スイッチロールし、スイッチ先アカウントに切り替わりました。前の画面で指定した色と表示名で、現在のロールが右上で確認できています。Amazon EC2 コンソールを開くと、EC2 インスタンスの一覧が見えています。これは、IAM ロールに AmazonEC2ReadOnlyAccess
ポリシーが付与されているからです。
そのままスイッチ先アカウントで、 AWS IAM コンソールを開くと、権限不足で閲覧できないことが分かります。
スイッチ元アカウントAに戻る(スイッチバックする)際は、右上のロール 名をクリックして「スイッチバック」をクリックします。
スイッチロールのユースケース
複数、または多くの AWS アカウントを使用してシステムを構成する際、一つ一つのアカウントに IAM ユーザを一人ずつ作成する作業は大変で、ポリシー管理も煩雑になります。
そこで、一つのアカウントを IAM ユーザ管理用アカウントとし、他のアカウントには必要な権限だけを付与した IAM ロールを用意しておきます。作業の際はスイッチロールする運用にすることで、ID 管理がすっきりします。
もちろん、一時的に他の人のアカウントの設定を閲覧したい場合なども、スイッチロールは有効です。
参考
emi kitani(執筆記事の一覧)
AS部LX課。2022/2入社、コーヒーとサウナが好きです。執筆活動に興味があります。AWS認定12冠。