こんにちは。エンジニアリング＆デザインマネジメント室 SREチームの山口です。
今回はAWS IAM Identity Center(旧名: AWS SSO:Single Sign-On)を導入したお話をしたいと思います。
AWS IAM Identity Centerとは
AWS IAM Identity Center(以下から、単にIAM Identity Center)は、複数AWSアカウントへのログインをシングルサインオン（SSO：Single Sign On）経由で提供するサービスです。SSOとは、1度のユーザー認証によって複数のシステム（業務アプリケーションやクラウドサービスなど）の利用が可能になる仕組みを指します。
ユーザー情報の保存や管理をするIdプロバイダー(以下から、IdP)として、AWS自体とSAML認証に対応しているAuth0, Azure Active Directory, Google Workspace,
Microsoft Active Directory フェデレーションサービス, Oktaなどの数多くメジャーな3rd PartyのIdPが利用できます。
導入に至った経緯
弊社ではAWSアカウントをプロジェクト別、環境別に利用しているため必然的にAWSアカウント数が増える傾向にあります。仮に1プロジェクトのAWSアカウントだとしても、環境別に複数のAWSアカウントを切り替えて利用するため、AWSアカウント切り替えは避けて通ることが出来ません。
IAM Identity Centerを導入する以前は、IAMユーザーでユーザーを管理していました。環境別に同じユーザーのIAMユーザーを作るとIAMユーザーが多くなり管理しづらいため特定の1環境のAWSアカウントに集中してIAMユーザーを作って、そこから他環境へAssumeRole(スイッチロール)させて他のAWSアカウントへログインするという方法を取っていました。
AssumeRoleは1プロジェクトの環境別AWSアカウント間でIAMロールの切り替えを適切に行っていればセキュリティーを担保することが出来ましたが、ユーザー管理という観点から見ると、同じユーザーにロール別で複数のIAMユーザーを発行することがあり、決してスマートに管理できているとは言い難い状況でした。
また、AWS使用者の中には1プロジェクトだけでなく複数プロジェクトに関わっている人も存在していて、これをAssumeRoleでやろうとするとユーザーはプロジェクト数分のパスワードやMFA認証設定が存在、管理者側はプロジェクト数分のIAMユーザー、環境別のIAMロールやポリシーが存在するという双方にとって煩雑な状況になっていました。
これを一手に解決する方法がIAM Identity Centerの導入です。IAMユーザーをSSOユーザーに置き換え、ロールも権限セットに置き換えることで統合され、IAMユーザーと権限の重複管理が一切なくなりとてもスマートな状況になります。
なぜSSO導入したか
弊社ではIAM Identity Center導入以前に、組織全体として3rd PartyのIdPとしてOktaを利用していました。そして、導入時にこのIdPがIAM Identity CenterのIdPとしてデフォルトで利用できることを知り、とてもスムーズに導入できることが分かりました。
ちなみに、IAM Identity Center導入を検討していて現在外部IdPを利用していないのであれば、デフォルトでIdentityCenterディレクトリがあるのでこれを利用することが出来ます。
今回のSSO構成
AWS上でIAM Identity Centerを利用するためには事前にAWS Organizations(以下、単にOrganizations)でAWSアカウント(管理アカウントからメンバーアカウント)が管理されている必要があります。
(この先、Organizationsでこの構成が取れている前提で話が進んでいきますので、ご了承下さい。)
今回のOktaを利用してユーザーがAWSへSSOするフローを下図に示しました。
- OktaユーザーはSSOの入り口となるOktaへログイン
- ユーザー認証が通りSSOサービスの中からAWSを選択しAWSユーザーポータル画面へログイン
- ログイン後実際に利用するAWSアカウントと権限セットを選択
- SAML認証を伴った一時クレデンシャルを取得して、指定したAWSアカウントにログイン
というフローになっています。
上記の概略図では説明しきれていないIdPとAWS間との認証を詳しく説明する図は次のようになります。
- OktaユーザーはSSO入り口となるOktaへログイン
- Oktaにログインしてきたユーザー情報が存在しているかどうかアイデンティティストアに問い合わせて結果を返す
- Oktaユーザー情報が存在していたらOktaへのログイン完了
- Oktaのログイン情報をIAM Identity Centerのエンドポイントへ渡し、AWSにそのAWSユーザーが存在しているか確認
- AWSユーザーが存在していたら実際に利用するAWSアカウントの権限セットを渡し、AWS STSから一時クレデンシャル情報を貰う
- 実際のユーザーへその一時クレデンシャル情報を渡す
- 一時クレデンシャル情報を使って、実際に利用するAWSアカウントへマネージメントコンソールやCLIでログイン
というフローになります。
そして、実際に登録されたOktaユーザーはどうやって利用していくかというと、
- Oktaへログインする
- Oktaのマイアプリ一覧画面に「AWS Single-Sign-On」があるので、そこからAWSへログイン
- AWSのユーザーポータルへ遷移
- AWSアカウントと権限セット一覧画面からログイン方法をマネージメントコンソールかCLIを選択してログイン
という手順で利用します。
とても簡単にAWSが利用できます。
実際の導入手順
実際に前述の構成になるように設定する方法をこれから説明していきます。操作はOktaとAWSを何回か行ったり来たりします。
なお、権限としてOktaではアプリ関連が操作できる権限、AWSではIAM Identity Centerが操作できる権限が必要になります。
[Okta-1 Step1]
まずはOkta側の設定から始めます。
Oktaの初期状態では、アプリとしてAWSが登録されていないため、AWSを登録します。
Okta管理コンソール画面からApplication > Applicationsに進みます。
Applications画面から「Browse App Catalog」ボタンを押下し、検索窓から「AWS Single-Sign-On」で探します。
探すと候補として「AWS Single-Sign-ON」が出てくるので選択し、「Add」ボタンを押下して追加します。出てくる設定項目は一旦設定不要で、「General Settings」を「Done」を押下し完了します。
SSOアプリのSign OnタブからIdentity Provider metadataのリンクを右クリックして、metadataファイルをxmlで保存します。
[AWS-1 Step2]
SSOはOrganizationsの管理アカウントどこか1リージョンで固定されそれ以外のリージョンでは利用できないため、設定の段階で利用したいリージョンを予め決定しておきましょう。
リージョンの決定は普段最も利用しているリージョンで固定することをお勧めしますが、利用リージョンによっての機能的差異はありません。
AWS側の設定に移ります。AWSのIAM Identity Centerのコンソール画面の「IAM Identity Centerを有効化」から「有効化」ボタンを押下し、有効化します。
「設定」 > 「アイデンティティソースを変更」画面から「アイデンティティソースを選択」でOktaを利用するため「外部 ID プロバイダー」を選択して「次へ」を押下します。
「外部アイデンティティプロバイダーを設定」で、「サービスプロバイダーのメタデータ」からOkta側でメタデータを利用するため「メタデータファイルをダウンロード」でダウンロードしておくのと、
「AWS アクセスポータルのサインイン URL」「IAM Identity Center Assertion Consumer Service (ACS) の URL」「IAM Identity Center の発行者 URL」の３つの値をコピーしてメモしておきます。
「アイデンティティプロバイダーのメタデータ」で、[Okta-1]で保存しておいたメタデータファイルを選択してアップロードし、「次へ」を押下します。
「変更を確定」画面の「確認および確定」で設定内容を確認して問題なければ、「承認」と入力して「アイデンティティソースを変更」ボタンを押下します。
これで外部IdPをOktaでのSAML認証関連に設定できます。
[Okta-2 Step3]
Settingsの「Edit」を押下します。「Advanced Sign-On Settings」項目で、[AWS-1]でメモしてコピーした内容を入力します。
「AWS SSO ACS URL」には「IAM Identity Center Assertion Consumer Service (ACS) の URL」を、「AWS SSO issuer URL」には「IAM Identity Center の発行者 URL」を入力し「SAVE」ボタンを押下し保存します。
[AWA-2 Step4]
(自動プロビジョニングを有効にする場合)
自動プロビジョニングを有効にするとIdP側ユーザーの情報がAWS側ユーザー情報に全自動で全同期されるため、IdP側のユーザーを全てAWS側のユーザーとして利用したいときに非常に便利です。
IdPのOktaからAWSへ自動プロビジョニングを有効にする場合は、IAM Identity Centerの設定画面内にある「自動プロビジョニング」から「有効にする」ボタンを押下して有効化します。
有効にすると「SCIM エンドポイント」と「アクセストークン」が表示されるので、コピーしてメモしておきます。なお、表示させた後、閉じてしまうと再度表示されないので注意が必要です。
再度必要な場合は、「アクセストークン」を再発行して下さい。
ちなみに、弊社ではOktaで管理しているOktaユーザー全員に対してAWSへのSSOアクセスが必要だった訳では無いかつ導入初期は少数のユーザーでのみ利用をするスモールスタートでしたので、有効にしませんでした。
[Okta-3 Step5]
(自動プロビジョニングを有効にする場合)
Provisioningタブの画面内で「Enable API integration」のチェックボックスにチェックを入れて有効にします。
「Base URL」に[AWS-2]でメモした「SCIM エンドポイント」、「API Token」に「アクセストークン」の値を入力します。コピーしてメモした「SCIM エンドポイント」には末尾にスラッシュが付いてるので、こちら（/）を削除した上で入力します。
スラッシュを削除しないと通りません。
念のため、「Test API Credentials」ボタンを押下し、接続が成功することを確認してから「Save」押下して保存します。
Provisioningタブ、Settings > To App内の画面のProvisioning to Appの「Edit」を押下し、「Create Users」「Update User Attributes」「Deactivate Users」のチェックボックスにチェックを入れて「Save」を押下して、保存します。
これによりOkta側でのユーザーの作成、ユーザー属性の更新、ユーザーの無効化に対して自動で連携されます。
Assignmentsタブ画面で、「Assign」から「Assign to People」を選び、実際にOktaユーザー内でAWSへアサインを行いたいユーザー選び、「Assign」押下してアサインします。
(手動対応の場合)
自動プロビジョニングを有効にせず手動で対応する場合、OktaユーザーがAWSをSSOで利用するため各ユーザーごとにAWSが利用できるように設定する必要があります。
Directory > People画面で利用したいユーザーを検索し、検索して出てきたユーザー名を押下します。
「Groups」タブの追加したいグループに「AWS」と入力し、「AWS」を追加します。
[AWS-3 Step6]
(自動プロビジョニングを有効にする場合)
アサインできるAWSユーザーが存在しているか確認します。[Okta-3]でOktaユーザーがAWS側で連携されているので「IAM Identity Center」の「ユーザー」で確認します。
(手動対応の場合)
手動の場合、初期状態では「IAM Identity Center」の「ユーザー」が存在していないので、「ユーザーを追加する」ボタンを押下して、AWSユーザーを追加していきます。
追加するユーザー情報、「ユーザー名(Eメールアドレス)」はOktaユーザー情報と合わせる必要があります。
(共通)
IAM Identity CenterのAWSユーザーがどのAWSアカウントにどの権限を付与するかどうかの設定を行わないと実際にAWSを利用することが出来ません。
「AWSアカウント」からどのAWSアカウントへアクセス許可したいAWSアカウントのチェックボックスをチェックします。この時、1個でも複数個でもチェック可能です。
「ユーザーまたはグループを割り当て」ボタンを押下して、「ユーザー」または「グループ」タグからユーザー名またはグループ名(両方も可能です)を1個または複数選択して「次へ」を押下します。
「許可セット」ではユーザーにどんな権限を付与したいかを設定します。IAM Identity Centerの初期状態の場合、許可セットが「AWSViewOnlyAccess」と「AWSAdministratorAccess」の2つのみしか存在していないので必要に応じて自分に合った許可セットを作成します。
必要な許可セットのチェックボックスにチェックを入れて「次へ」押下します。
最後にユーザー、許可セットの確認があるので、問題なければ「送信」を押下して、割り当てを完了して下さい。
[Okta-4 Step7]
AWSで割り当てしたOktaユーザーがAWSで設定した通り利用できるか確認します。
Oktaでログイン後、マイアプリに「AWS Single Sign-On」があることを確認し、それを押下します。
画面遷移してAWSのSSOポータル画面に切り替わり、割り当てたAWSアカウントと許可セット一覧があることが確認できれば完了です。
[AWS-4 Step8]
もう1つAWSの入り口として、 https://d-1234567890.awsapps.com/start 形式でSSOログインURLが用意されているのでこちらアクセスすることでも同じ動作します。
このAWS アクセスポータルURLは、IAM Identity Centerの設定 > アイデンティティソースの項目から参照することか可能です。
当然ながら、間にOktaログインが間に入ります。
まとめると、Oktaユーザーが利用するために管理者側としては、下記の操作が必要です。
[Okta側設定]
- Oktaにユーザー登録する
- そのユーザーがSSOでAWSを利用できるようアプリ「AWS」を登録する
[AWS側設定]
- Okta側で登録したユーザー情報と同じ情報でAWSユーザーを登録する
- 登録したAWSユーザーに利用させたいAWSアカウントと権限セットを登録する
これで登録したOktaユーザーはSSOでAWSを利用することが出来ます。
導入してみて感じたメリット・デメリット
メリット
- IAM Identity Center自体無料で利用できる
- セキュリティーを担保しつつ利便性が上がった
- IAMユーザー管理から開放されて重複するAWSユーザーが存在しなくなる
- メジャーなIdPが利用できる
- AWSユーザー以外のEC2インスタンス単位等の小さな範囲に絞ってアクセスさせる連携ができる(今回未説明です)
と多くのメリットが受けられると思いました。
デメリット
- マルチIdP対応が出来ない(IdP設定が1つのみの設定に留まる)
- SSO環境下でのシステムユーザーの扱いが難しい
- SSO仕組みや利用方法の周知するための学習コスト
と不便な点が考えられると思いました。
まとめ
現状IAM Identity Centerを社内では便利に利用していますが、AWSを利用しているのが社内の人に限らず一部社外の人も利用しているため1つのIdPのみ対応ですと外部の人達は結局IAMユーザーで残り続けるという課題が残っています。社外用のIdPも合わせて使用できるよう、マルチIdP対応されることを一番に期待しています。