この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS SSOのコンソール画面を触ってると、「んん？？どういうこっちゃ??♂️」みたいに混乱することありませんか？画面に沿ってなんとなく設定はできたけど、どういう仕組みになっているかわからないというか… すみません、うまく言語化できていない自覚があるんですが、以下のような点がモヤモヤしています。
- ユーザー&グループ、アカウント、アクセス権限セット各概念の関係性がわからない
- いや、俺はそもそもアクセス権限セットがどういうものなのか理解していないのでは？(モヤモヤ?)
今回はこのモヤモヤを解消するために、SSOの概念を図解していきたいと思います。SSOコンソール上での以下各操作によってどういうリソースが作成され、それぞれがどう動作するのかまとめます。
- 初期状態(SSO有効化前)
- SSOを有効化する
- ユーザーやグループを作成する
- アクセス権限セットを作成する
- アカウントにユーザー・グループを割り当てる
- アカウントにログイン(スイッチロール)する
- アクセス権限セットのポリシーを変更する
注意点
- あくまで現時点での私の理解ですので、間違っているかもしれません。間違ってたらごめんなさい。ぜひご指摘お願いします。
SSOはIAMロールを使っている
本題に移る前にまずは前提知識の共有を。 AWS SSOを使うと、SSOにログインするだけで複数のAWSアカウントにアクセス(ログイン)できるようになるのですが、この仕組み、裏では実はIAMロールを使っています。みなさんが使ったことのある(はず)、スイッチロールの仕組みの応用です。
↑の、「JumpアカウントにいるIAMユーザー」の部分が、「SSOのIDストアにいるSSOユーザー」に代わります。つまり以下のような感じです。
なお、本エントリは弊社チバユキが流布している「IAM ロールとはお面のようなものである」という説に完全に乗っかります。ですのでまずはこちらのエントリをご一読ください。すごくわかりやすいうえに面白いので、おすすめです。ほんとに。
本題: 時系列順に解説
では順を追って説明していきます。
初期状態(SSO有効化前)
まずSSOを有効化する前の状態です。SSOを有効化するにはAWS Organizationsを使っている必要があります。Management Account一つと、そうでないアカウントがいくつかある状態です。
SSOを有効化する
SSOインスタンス
SSOを有効化すると、Management AccountにSSOインスタンスというものができあがります。SSO関連のデータを保存している場所です。コンソールで操作しているときには特に意識する必要はありませんが、CLIやCloudFormationを使う際はインスタンスのARNを指定するケースが多々あります。
ちなみにSSOインスタンスのARNはコンソールでも設定ページで確認できます。
IDストア
また、IDストアも作成されます。ユーザーやグループの格納場所ですね。そしてSSOインスタンスからアクセスできるようになります。
なお、SSOには
- 独自の(=SSOの) IDストアを作って使う
- 既存のActive Directoryを使う
- 既存の外部IDプロバイダーを使う
と3つの方法があります。上記の図はIDストアを作って使う場合です。他の2方法については、私がまだ経験したことがなくちゃんと理解できていませんので、図示は行いません。ご了承ください。
ユーザーやグループを作成する
ユーザーやグループをIDストア内に作成します。ユーザーは複数のグループに所属できますし、全くグループに所属しないこともできます。
アクセス権限セットを作成する
次に、アクセス権限セットを作成します。コンソール上では「AWSアカウント」を左のメニューから選んで表示される「アクセス権限セット」タブ以下です。
英語ではpermission setsと呼びます。CLIとかCloudFormationでもこの名前です。
さて、アクセス権限セットとは何なのかというと、以下のような感じです。
「IAM ロールとはお面のようなものである」という説に乗っかると「アクセス権限セットはそのお面の設計書のようなもの」だと私は考えます。設計書なのでIAM ロールそのものではないです。なんでそうなのかはもうちょっとあとまで説明を読んでいただくとわかると思います。
アクセス権限セットには、IAMポリシーのアイデンティティベースポリシーをアタッチします。2種類のものがアタッチできます。
ひとつはAWS 管理ポリシーです。AWS 管理ポリシーは一般的なユースケースに即するように設計されたポリシーです。かつ、AWSが作成および管理しているポリシーですので、例えば新サービスや新機能が出たときなども元から定義されているユースケースにそって適切な権限が自動で付与されます。一番メジャーなAWS管理ポリシーはAdministratorAccessポリシーでしょうか。AWS管理ポリシーはひとつのアクセス権限セットに最大10個アタッチすることができます。
もうひとつはカスタムアクセス権限ポリシーです。こちらはJSONを書いて自由に権限設定できるのですが、アタッチできるのは一つだけです。
こんな感じで、アクセス権限セットという名の設計書が、SSOインスタンス内に作成されます。
アカウントにユーザー・グループを割り当てる
さて、最後の設定です。アカウントにユーザー・グループを割り当てます。コンソールでいうと「AWSアカウント」ページ「AWS組織」タブからアカウント名をクリックするか、
その横のチェックボックスにチェックを入れてから「ユーザーの割り当て」をクリックするかで進めるフォームです。
後者の方法だと複数アカウントまとめて設定できます。
この「アカウントにユーザー・グループを割り当てる」際に理解しておくとよいのは、「アカウント/ユーザー・グループ/アクセス権限セット」という3つの要素を紐付ける行為である という点です。
例えば山田さんというユーザーがいたとします。山田さんはアカウントAにはAdmin権限でアクセスできるけど、アカウントBにはReadOnly権限でしかアクセスできないし、アカウントCにはアクセスできない、みたいな設定ができます。
また、Adminというグループを作ったとしても、新アカウントを作成するだけでAdminグループのユーザーがそのアカウントにAdmin権限でアクセスできるわけではありません。ちゃんと「新アカウントと、Adminグループと、Admin権限をつけたアクセス権限セット、3つを紐付ける」設定をしてからでないとできないわけです。
はい、左下に「割り当て(Assignments)」というデータができました。
もちろんグループに対しても割り当て可能です。
まだ終わりません。他にも「実体」ともいうべき色々なリソースが作成されます。
ここでは 「AccountA x ちょびひげおじさん x 天狗のお面の設計書」のパターンで見ていきます。
IDプロバイダ
まず、対象のAccountAの中に「IDプロバイダ」というIAMリソースが作成されます。これは1アカウントに一つだけあれば良いので、そのアカウントが初めて前述の割り当ての対象になったときにだけ作成処理が走ります。
で、このIDプロバイダというものは、AccountAからIDストアへと繋がる道の「門」のような感じです。
IAMロール
次にIAMロールです。
IAMロールが、アクセス権限セットで設定したAWS 管理ポリシーがアタッチされた状態で作成されます。カスタムアクセス権限ポリシーはインラインポリシーになります。
また、信頼ポリシー(このIAMロールを引き受けることができる、つまりお面を被れるエンティティを規定するポリシー)で、先程のIDプロバイダが設定されます。つまりIDストアのユーザーやグループしかこのロールを引き受けることができないということです。
認可情報
IDストア側には「ちょびひげおじさんはIDプロバイダAの先の天狗ロールを引き受ける権限がある」という情報が記録されます。
この情報が、実際のログイン(スイッチロール)の際にAccountAに渡されます。これがないと、IAMロールが信頼しているのはIDプロバイダだけなので、その先のどのユーザーが引き受けられる/られないという部分がわからないです。
アカウントにログイン(スイッチロール)する
先程のステップまでで設定は終わりです。実際にSSOユーザーが各アカウントにログイン(スイッチロール)する際には、ユーザーが各アカウントに作成されたIAMロールを、stsの力を借りて、引き受け(assume role)ます。アクセス権限セットや割り当てのデータは直接関与しません。
アクセス権限セットのポリシーを変更する
いずれかのアカウントに割り当て済のアクセス権限に紐付いてるIAMポリシーを変更した場合は、その変更を割当先のアカウントに適用するというステップが発生します。これをしないと、ポリシーの変更はSSOインスタンス内にだけに留まって、効果を及ぼしません。
まとめ
AWS SSOの概念を解説しました。
- IAMのスイッチロールの仕組みが使われている
- アクセス権限セットはIAMロールの設計図
- アカウント/ユーザー・グループ/アクセス権限セットという3つの概念を紐付ける
あたりが理解できるようになると、だいぶSSOの理解が進むと思います。