やりかた
現在 AWS へ SSO するには AWS Identity Center を使うのが公式おすすめとなっている。で、これは IdP として外部サービスを指定可能だ。
つまり、 AWS Identity Center の外部 IdP として Google Workspace を指定すればやりたいことができる。
手順
次のドキュメントを参照しながら設定する。
日本語版ドキュメントは古い可能性もあるので、使用する場合は必ず英語版との差異がないかを確認すること。英語版を機械的に日本語翻訳して参照してもよいが変な文章となることがあるので、英語版で意味を取りづらいときに参考とする程度が良いだろう。
注意点
アクセス権限セット: Permission sets は AWS IAM で言うところのポリシーにあたる。が、 access portal にはアクセス権限セットの名前がそのまま表示されるので、チームメンバーが何の目的でそのアカウントにアクセスするかの役割を名前としよう。
見たほうが早い。 AWS access portal は次のように表示される。
上の例では次のような設定にしている。
-
accounting: マネージドポリシーの Billing -
admin: マネージドポリシーの AdministratorAccess -
dev: マネージドポリシーの PowerUserAccess
access portal 経由でロールの使い分けも一発なので SwtichRole 感覚で使っていける。
Google Workspace をディレクトリーサービスとして使う楽さ
現在、チームメンバーが使う基幹サービスを契約する場合、まず間違いなく Google Workspace を選択するだろう。次の理由からその他のサービスが選択肢にすら上がらない状況だ。
- 一部として提供されている Gmail の使い勝手が良いこと
- グループという名のメーリングリストが作成できること
-
+で用途ごとにメールアドレスを分けられること
- Google Sheets や Google Slides などビジネスアプリケーションも使用可能なこと
- 直感的に管理できること
- 大体のサービスで OAuth IdP としてサポートされていること
- 価格が安すぎること
つまりたいていの状況において、チームメンバーの情報は Google Workspace に集約されている。これを Single Source of Truth として使おうとするのは道理だろう。
また、チームメンバーが使うツールへは SSO したいというのも人情としてわかる。監査やガバナンスなどという言葉を持ち出す以前に、楽だからだ。チームメンバーにサービスごとのパスワードを管理させるのは明らかなトイルだろう。
以上から Google Workspace をディレクトリーサービスとして使うのが自然な流れとなる。
Discussion