0.はじめに
概要
- 本記事は前半 (AWS側) と後半 (IDaaS1 側) の2部構成です。
- こちらは前半 (AWS側) です。後半 (IDaaS側) はこちら。
- この記事では、社内でIDaaSからAWSへのシングルサインオン (以下、SSO) および案件で利用する各AWSアカウントへのスイッチロールを連携させた際の背景や手順などを紹介します。
- 多数のWebサービスとAWSアカウントを抱え、IAMユーザー管理に頭を悩ませているシステム管理者の方に読んでいただければと思っています。
やりたいこと概略図
- before
- 今までは複数アカウントのIAMユーザーを個々の社員が自己責任で管理していました
- after
- SSOとスイッチロールで会社側から一元管理できるようにしたいと思います。
想定する読者
- 各種サービスのアカウント管理に悩んでいる社内インフラ管理者の方
- 複数のAWSアカウントを利用されている方
- 必要な予備知識は特にありませんが、CloudFormationの操作経験があると良いかもしれません。
導入の経緯
- そもそもは社内で利用しているAWSアカウント数が20を超え、各チームとメンバー個々人でのアカウント・IAMユーザー管理に限界を感じてきたことが発端でした。
- また、社員の入退社や移動、プロジェクトの開始終了に合わせて各AWSアカウントにIAMユーザーを作成・削除するというのも非効率で改善すべき点だと考えていました。
- この2点を解消すべく、私が所属する社内のAWSアカウントを統括するチーム (以下、AWSチーム) では下記の仕組みを取り入れようと試みました。
- IDaaSから踏み台AWSアカウントへのSSO
- 踏み台AWSアカウントから各プロジェクトで利用するAWSアカウントへのスイッチロール
- この仕組みがうまくできれば、多数のAWSアカウントで個別にIAMユーザーを管理していた管理者は、IDaaS上で1社員1ユーザーで統合されたユーザーアカウントを管理すればよいことになります。
- ちなみに当社ではIDaaSとしてCloudGate UNO2を利用していますが、Google Workspace導入時に契約したもので今回IDaaSとして個別に選定したものではありません。(たまたますでにCloudGate UNO契約済みで、IDaaSとして利用できるので利用した、という程度の動機です。)
背景・前提
- 当社ではAWSアカウント費用の支払いに、ClassMethodさんの請求代行サービスを利用しています。
- 前述の通り、IDaaSとしてすでにCloudGate UNOを利用しています。
- AWSチームにはすべてのAWSアカウントに対してIAMポリシー：AdministratorAccessが付与されています。
1. 大まかな流れ
- 2部構成で、本記事ではAWS側で実施する内容を記載しています。
AWS側
- 踏み台となるAWSアカウントの用意
- IAM Identity Centerの設定
- スイッチロール作成
IDaaS側 (この記事ではCloudGate UNO)
- サービスプロバイダーの追加
- 既存ユーザーのプロビジョニング
- → 次の記事へ
2. AWS側
2-1. 踏み台となるAWSアカウントの用意
ここはClassMethodさんの請求代行サービスとSSOとの兼ね合いについてのセクションとなりますので、利用されていない方は読み飛ばしていただいて構いません。
どのアカウントを踏み台にするかだけ決めておいてください。
- そもそもClassMethodさんの請求代行サービスはClassMethodさんのOrganizations配下に属することで利用できるものですので、別途自社Organizationsを構築するための専用アカウント (以下、専用Payerアカウント) を作成します。アカウント作成フォームからOrganizationsの利用ありで申し込みましょう。
- 専用Payerが作成されたら、ClassMethodさんのOrganizations配下にある既存アカウントのうち踏み台とするアカウントを指定して専用Payer配下のメンバーアカウントとして登録してもらいましょう。
- この操作はClassMethodさんでしか実施できないため、依頼が必要となります。
2-2. IAM Identity Centerの設定
- 踏み台アカウントの用意が出来たら、まずは専用PayerアカウントでIAM Identity Center (旧：AWS SSO) を設定しましょう。テキストベースで申し訳ないのですが、手順を詳細にまとめましたので参考にしてください。
- IAM Identity Centerのダッシュボード
2-2-1. IAM Identity Center
- 専用PayerアカウントでIAM Identity Centerを有効にします。
- リージョンは任意ですが、東京 (ap-northeast-1) を選択しました。
- 一度作成すると別リージョンに作り直したいときに既存を削除する必要があります。
- ダッシュボードから「アイデンティティソースの登録」を実施します。
- 外部IDプロバイダーを選択
- CloudGate UNOのアイデンティティプロバイダー設定画面からダウンロードした「SAML 2.0 メタデータ」と「証明書」をインポート
- 下記はCloudGate UNOのサービスプロバイダー画面に設定するのでメモしておいてください。
- AWS アクセスポータルのサインイン URL
- IAM Identity Center Assertion Consumer Service (ACS) の URL
- IAM Identity Center の発行者 URL
- IAM Identity Centerの設定が完了するので「設定」画面から下記をメモしておいてください。
- ARN (arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxxxxxxxxxxx)
- ダッシュボードから「複数の AWS アカウントへのアクセスを管理」またはナビゲーションメニューから「AWSアカウント」を選択します。
- 「組織構造」から、『「MembersDefaultOU」に所属している踏み台となるAWSアカウント』にチェックし「ユーザーまたはグループを割り当て」を選択します。
- ユーザー一覧が表示されます。初回はユーザーがいないので「ユーザーを作成」をクリックします。
- 下記項目を入力しユーザーを作成します。 (下記以外は未入力可)
- ユーザー名
- CloudGateとのマッピングに使う
- E メールアドレス (E メールアドレスを確認)
- 名、姓、表示名
- ユーザー名
- 「次へ」
- 許可セット一覧が表示されます。初回は許可セットがないので「許可セットを作成」を選択します。
- 許可セットのタイプを選択します。
- 今回は「事前定義された許可セット」の「AdministratorAccess」を選択します。
- 許可セット名を入力して「次へ」、確認画面で「作成」をクリックします。
- 許可セット名は最終的にSSO時のユーザー名に含まれるので適切な名称にしてください。
- 下記項目を入力しユーザーを作成します。 (下記以外は未入力可)
- 作成した「許可セット」を選択し「次へ」、確認画面で「送信」をクリックします。
- 送信することで、組織構造で選択したアカウントにSSO用のIDプロバイダーとそれに紐づいた許可アセット＝ロールが作成されます。
- 自動プロビジョニング3 を設定したい場合、下記の手順を実施します。
- ナビゲーションメニューの「設定」を選択します。
- 「プロビジョニング」 の横にある 「自動プロビジョニングを有効にする」 をクリックします。
- 「SCIMエンドポイント」と「アクセストークン」が表示されるので、それぞれメモしておいてください。(後半の記事で使用します。)
3. この記事のまとめ
- ここまではいかがでしたでしょうか。IDaaS側まで設定を終えて疎通してみるまでは何とも言えないと思いますが、ひとまずこの記事はここまでです。
- 次回記事はこちら。
-
”IDaaSとは、「Identity as a Service」の略称であり、「アイダース」または「アイディアース」と呼ばれています。クラウド経由でID認証、ID管理、シングルサインオン (SSO)、アクセス制御、ログ管理などを提供するサービスです。” (CloudGate社 用語集 より引用) ↩
-
プロビジョニングとは、”コンピュータシステムを新規の利用者が使えるようにする場合、ユーザーアカウントの作成やアクセス権限の指定、ソフトウェアの設定、個人用フォルダの割り当てなどの操作や作業を行う必要がある。これをユーザープロビジョニング、アカウントプロビジョニングなどという。” (IT用語辞典 e-Wordsイーワーズより引用) ↩