日頃の開発に AWS を使いつつ、ビジネスツールとして Google Workspace を導入している企業は多いと思います。その場合、追加の費用なしで、「会社のGoogleアカウントでAWSのマルチアカウント環境にSSOログインできる」ように設定することができます（要するにSAMLですね）。意外と知られていない気もするので簡単に紹介してみます。
Okta などに比べると、Google Workspace は多くの企業で既に採用されているでしょうし、この設定をするにあたり追加の費用もかからないので気軽に試しやすいかと思います。
公式のユーザーガイドはこちら： Google Workspace および IAM アイデンティティセンターによる SAML と SCIM の設定
認証プロバイダをなるべく統一すると、一般の開発者がログインするうえでも便利ですし、管理する人の手間や心配事も減ります。
また、企業によってはSSOを設定するうえでの懸念事項もあると思うので、そのあたりも含めて、ご参考にどうぞ。
前提
まず当然ながら、AWSのマルチアカウント環境がセットアップされていることが必要です：
- AWS Organizations によるマルチアカウント環境になっていること
- マルチアカウント環境へのログインに IAM Identity Center を使っていること
これらは AWS Control Tower を使ってマルチアカウント環境が設定されていれば自動で設定済みかと思います。
つまり「AWSアクセスポータル」を使って複数アカウントにログインできている状態が前提です。アクセスポータルに入る際の認証プロバイダを Google Workspace にしてしまおう、というのが今回の話です。
重要: AWS側の事前準備
Google Workspace の情報でログインしたユーザを IAM Identity Center 上のユーザと紐づけるために、IAM Identity Center 上のユーザ名を、Google Workspace の「メールアドレス」と一致するようにしておく必要があります。IAM Identity Center にて、既存ユーザのユーザ名をひたすら修正しましょう。
既存のユーザ規模が大きい場合は、一手間かかるかもしれません。
設定をはじめる
SSOの設定を致命的に間違えるとAWS組織の管理アカウントに自分がログインできなくなる恐れがあるので、最悪の場合にルートユーザでログインできる用意は整えてから進めましょう。
Google WorkspaceとAWSの管理画面を行ったり来たりして設定するので、下準備としてブラウザで以下のページを開いておきます。
- Google Workspace の管理コンソールにログインしておく
- AWS Organizationsの管理アカウントにログインして IAM Identity Center を開いておく
Google Workspace側の設定 (1)
-
Google Workspace の管理コンソール (https://admin.googlg.com/) に行きます。
-
アプリ → ウェブアプリとモバイルアプリ → アプリを追加 → アプリを検索
-
“Amazon Web Services - ウェブ (SAML)” を選択します
-
「IdPメタデータをダウンロードする」から、メタデータファイルをダウンロードします。AWS側にこのファイルを与えます。
ここまで進んだらAWS側で作業します。
AWS側の設定 (1)
-
IAM Identity Center → 設定 に行きます。
-
アイデンティティソース → アクション → アイデンティティソースの変更 → 外部IDプロバイダを選択
-
以下の情報が表示されるので、控えておきましょう。
- AWS アクセスポータルのサインイン URL:
https://xxxxxx.awsapps.com/start
- IAM Identity Center Assertion Consumer Service (ACS) の URL
https://ap-northeast-1.signin.aws.amazon.com/platform/saml/acs/xxxxxx-xxxxxx-xxxxx-xxxxxx
- IAM Identity Center の発行者 URL
https://ap-northeast-1.signin.aws.amazon.com/platfom/saml/d-0123456789
- AWS アクセスポータルのサインイン URL:
-
IdPメタデータファイルを選択する欄があるので、さきほど Google Workspace からダウンロードしたIdPメタデータファイルを選択します。
-
変更を承認して、「アイデンティティソースを変更」するを押します。
Google Workspace側の設定再び
- 次のページに進み、先ほどAWS側で控えてあった「ACSのURL」と「エンティティID」を入力します。エンティティIDの欄には、AWSで「発行者URL」とされているものを入力します。「開始URL」にはアクセスポータルのサインインURLを記入します。
- 以上で設定終了です！
この状態でAWSアクセスポータル https://xxxxxxxx.awsapps.com/start に行き、Googleによる認証が間に入れば、設定は成功です。
おわり。
その他の話
(optional) ユーザの自動プロビジョニングも設定できる
さらに自動プロビジョニング (SCIM) も有効にすると、Google Workspace上のユーザを自動でAWS Identity Center上に自動でプロビジョニングさせることができます。つまり、Google Workspace上に作られたユーザが自動でAWS Identity Centerにも反映され、同様に、削除されたときも自動で削除されます。
手順としては：
- IAM Identity Center で自動プロビジョニングを有効にする
- SCIM エンドポイントとアクセストークンを控えておく
- Google Workspace 側の AWS SAML アプリの設定で、自動プロビジョニングを有効にして、SCIM エンドポイントなどを入力する。
だけです。
注意点として、この設定を有効にすると、マネージメントコンソールからユーザ情報やグループへの所属の設定を変更できなくなります。（AWS CLIなどによるAPI操作を使いましょう、とのことです…）。
ちなみに弊社では、SCIMを使いつつ、IAM Identity Center のグループや、AWSアカウントへのユーザ権限の割り当てなどは Terraform で行っています。このあたりも別の記事で紹介できるとよいかもしれません。
Google Workspace 組織外のメンバーはどうするか
今回説明した設定によって Google Workspace のアカウントでAWSにログインできるようになり、大変便利ではあるのですが、その代わりに Google Workspace の組織外の方はAWSアクセスポータルからログインできなくなってしまいます。例えば副業の方には Google Workspace のIDを与えていない会社もあるでしょう。さてどうしましょう：
いくつか解決方法があると思います：
- その方々にも Google Workspace のアカウントを作ってしまう
- 必ずしもWorkspaceの有料ライセンスを付与する必要はありません。その方々は “Cloud Identity Free” にしておけば、コストなしで「Googleのログイン機能だけを使えて、他のことは何もできない状態」にできます。
- 個別のAWSアカウントに IAM User でログインさせる → これは避けたいですね。誰も気にしていない、忘れさられた裏口がAWSアカウントに開いてしまうことが目に見えています。