OktaとWorkforce Identity 連携について
Oktaのユーザー認証を使用して、Google Cloud環境に入る方法である、Workforce Identity連携についてまとめた記事です。
Table of contents
author: kuribo-,koba
Oktaとは
Oktaとは、クラウド型IDaaSサービスです。
様々なサービスやクラウドに連携できるため、複数のクラウドサービスを利用していたとしても、OktaのID1つでそれぞれのサービスにSSOをできるように設定ができます。
今回はOktaのIDを使ってGoogle Cloudを利用できるようにします。
Workforce Identityとは
他のIDaaSと連携することで、GoogleアカウントがなくてもGoogle Cloudを利用できるようにするためのサービスです。
似た様な名前でWorkload Identityというものがありますが、こちらは他のサービスから証明書情報等なしでサービスアカウントの権限を利用するためのものです。 (GKEのPodからSAの権限を利用するときや、Github ActionsなどでSAの権限を利用してGoogle Cloudのリソースを利用する場合など)
IdP-initiatedとSP-initiated
SAML認証における処理のフローにはIdP-initiatedとSP-initiatedの2つがあります。GoogleCloudでは双方の認証方法をサポートしています。このブログで詳細は割愛しますが、この2つのフローの大きな違いは、認証の開始点です。
IdP-initiated
IdP-initiatedのフローでは名前の通り、IdP(Identityプロバイダ)を出発点として、SP(サービスプロバイダ)にサインインをします。
つまりOktaへのサインインを行った状態でGoogle Cloudへサインインを行います。
Oktaではユーザーホームから該当のアプリケーションを選択することでこのフローをたどります。
以下IdP-initiatedについてのOktaの公式ドキュメントへのリンクです。
https://help.okta.com/oag/en-us/content/topics/access-gateway/ref-arch/flow-idi.htm
SP-initiated
一方SP-initiatedではサービスプロバイダを出発点として、IdPを経由してSPにサインインをします。
よってOktaへのサインインが済んでいなくても、Google Cloudへのサインインを行うタイミングで強制的にOktaを経由し、認証後、再度Google Cloudへのアクセスを行います。
Workforce Identityのプロバイダを作成後、表示されるURLにアクセスすることでこのフローをたどります。
以下SP-initiatedについてのOktaの公式ドキュメントへのリンクです。
https://help.okta.com/oag/en-us/content/topics/access-gateway/ref-arch/flow-spi.htm
設定方法
Okta
今回はOktaのフリートライアルを利用しました。
まずはアカウントを作成します。
↓から登録しましょう。
登録後メールが来るので、アクティベートするとトライアル用のテナントの作成が完了します。
作成されたテナントの初期画面は以下です。
この初期画面はOktaのユーザ画面のようなので、ユーザやグループを作成できる管理画面が表示されるようにします。
画面右上にある「管理者」ボタンをクリックします。
管理者ボタンをクリックすると、管理者画面の初期設定画面?みたいなのが出るので、
今回の初期設定では基本的に「Other」を選択し、値が必要な場合は「test-koba」を入力しました。
以下参考画像です
上記まで設定すると以下の様な管理者画面が表示されます。
今回はWorkforce Identity用のユーザーとグループおよびアプリケーションの設定が必要です。
ユーザー作成
左のメニューから「ディレクトリ>ユーザ」を選択します。
以下の画面が出てくるので、「ユーザを追加」ボタンをクリックします。 「ユーザを追加」をクリックすると、以下のモーダルが表示されるので、適宜入力して「保存」ボタンをクリックします。
これで作成されたユーザの人にメールが飛ぶので、アクティベートして完了です。
グループ作成
左のメニューから「ディレクトリ>グループ」を選択します。
以下の画面が出てくるので、「グループを追加」ボタンをクリックします。
「グループを追加」をクリックすると、以下のモーダルが表示されるので、適宜入力して「保存」ボタンをクリックします。
今回はグループにユーザーを割り当てて使うので、作成したグループ名をクリックしてユーザを追加します。
以下のグループ名をクリックします。
以下の画面で「ユーザーを割り当て」をクリックします。
以下の画面で表示されたユーザの右側にある「+」をクリックし、「完了」ボタンをクリックすることでユーザの割り当てができます。
アプリケーション作成
Oktaの管理画面のサイドメニューから「アプリケーション」を選択します。
「アプリ統合を作成」を選択します。
今回はSAML2.0を選択します。
①一般設定、②SAMLを構成、③フィードバックといった流れで設定をしていきます。
①「一般設定」ではアプリ名・アプリのロゴ等を設定します。
②「SAMLを構成」ではSAMLに関するSAML ACS・オーディエンス等を設定します。
設定するURLについては以下で確認できます。
https://cloud.google.com/iam/docs/workforce-sign-in-okta?hl=ja#create-saml-provider
デフォルトのRelay Stateには、IdP-initiatedフローでのアクセス先を設定します。
このRelay Stateを設定しないとIdP-initiatedフローは利用できません。
以下のGoogleドキュメントにもあるように、Google Cloudコンソールのトップページ( https://console.cloud.google/ )を設定します。
https://cloud.google.com/iam/docs/workforce-sign-in-okta?hl=ja#sign_in
SAML Subject・グループの属性マッピング等もここで設定できますが、後ほどまとめてご紹介いたします。
今回は下の「ソフトウェアベンダーです。自社アプリをOktaと統合したいと考えています。」を選択し、ほかの項目については未記入としています。 アプリケーションの一覧画面に反映されれば完了です。
[事前作業]XMLメタデータファイルのダウンロード
Google CloudのWorkforce Identityの設定に、IdPで生成されたXMLファイルを登録する手順があります。
サイドメニューからアプリケーション>作成したアプリケーション>サインオンタブ>「SAMLの設定手順を表示」を選択します。
オプションのメタデータをコピーし、任意の名前でダウンロードしておきます。
Workforce Identity
Poolの作成
Google CloudコンソールでWorkforce Identityの連携検索し、選択します。 「プールを作成」から新しいプールの名前を設定します。 この名前はのちにIAMで権限設定をする際に、プリンシパルとして使用する文字列になります。
Providerの作成
Poolの中にプロバイダを追加します。 プロバイダの選択として、今回はSAMLを選択します。 プロバイダの名前・事前作業でOktaからダウンロードしたXMLファイルをアップロードします。
属性マッピング
Oktaユーザーの情報やグループの情報をプリンシパル等で使うためには、属性情報をマッピングしておく必要があります。
Oktaの管理画面とWorkforce Identityプロバイダの画面双方で設定が必要なため、属性ごとに分けて説明します。
Oktaの管理画面の「SAMLの設定」>「属性ステートメント」で、Workforce Identityに渡す属性の設定が可能です。
この属性ステートメントに追加した属性は、SAMLアサーションのプレビュー画面からXMLファイルで確認できます。
NameID
Oktaの管理画面
SAMLアサーション内のSubjectステートメントで指定するNameIDの設定です。
Oktaのユーザー名として、Oktaユーザー名(Oktaの仕様でメールアドレスを使用)、Oktaユーザー名のプレフィックス(メールアドレスの@より前の部分)、カスタムIDなどを設定できます。
Workforce Identity プロバイダの設定
Google.subjectは必須のキーです。以下がマッピングの例です。
SAML | |
---|---|
google.subject | assertion.subject |
グループ属性ステートメント
Oktaの管理画面
Oktaで作成したグループ属性を渡すための設定です。
事前にグループを作成し、そのグループ名を値として設定することで、SAMLアサーションに反映されます。
以下はOkta側のグループ属性の設定です。今回はOktaグループとして作成したgceditorsグループをステートメントとして登録しました。
名前 | 名前のフォーマット(オプション) | フィルター | (値) |
---|---|---|---|
groups | 指定なし | 等しい | gceditors |
Workforce Identity プロバイダの設定
グループ属性に対応するキーとしてGoogle.groupsが用意されています。以下がマッピングの例です。
SAML | |
---|---|
google.groups | assertion.attributes.groups |
カスタム属性ステートメント
Oktaの管理画面
任意の属性ステートメントを追加できます。
ユーザーのプロファイルから部署名などをWorkforce Identityに渡したい場合などに使用します。
以下はユーザーのプロファイル内のdepartmentを属性として渡す例です。
名前(例) | 名前のフォーマット(オプション) | (値) |
---|---|---|
department | 指定なし | user.department |
Workforce Identity プロバイダの設定
SAMLアサーションでは以下の記述があるように、属性がリストとみなされるため、リストの番号を指定する必要があります。
SAML アサーションでは、Attribute に複数の AttributeValue タグを設定できます。
したがって、すべての SAML 属性はリストと見なされるため、assertion.attributes.userRole はリストとなります
https://cloud.google.com/iam/docs/troubleshooting-workforce-identity-federation?hl=ja#mapped-attribute-string
よってdepartmentを明示的に指定するのではなく、attributeの配列番号で渡す必要があります。
SAML | |
---|---|
attribute.department | assertion.attributes.[0] |
IAMロールの付与
OktaとWorkforce Identityを連携するだけだと、コンソールを表示する権限を持つだけになるため、各種リソースは表示できません。
表示するためにはIAMにて、連携したユーザー・グループに権限付与する必要があります。
Googleアカウントを用いたユーザーへの権限付与と同様に、IAMでプリンシパルに対してIAMロールを付与可能です。
IAMロールを付与するプリンシパルについて
以下がプリンシパルに関するドキュメントです。
https://cloud.google.com/iam/docs/workforce-sign-in-okta?hl=ja#manage-access
ユーザ単位
WORKFORCE_POOL_IDにはプール作成時に設定したプールIDと、SUBJECT_VALUEにはユーザーIDを設定したプリンシパルを使用して、ユーザーへの権限付与が可能です。
単一のユーザーのプリンシパルの例は以下の通りです。
principal://iam.googleapis.com/locations/global/workforcePools/[WORKFORCE_POOL_ID]/subject/[SUBJECT_VALUE]
グループ単位
以下がグループのプリンシパル例です。
principalSet://iam.googleapis.com/locations/global/workforcePools/[WORKFORCE_POOL_ID]/group/[GROUP_ID]
ユーザの属性単位
事前にOktaのユーザーのプロファイルに設定した部署名をマッピングした場合、プリンシパルセットの例は以下のようになります。
principalSet://iam.googleapis.com/locations/global/workforcePools/[WORKFORCE_POOL_ID]/attribute.department/[DEPARTMENT_VALUE]
Workforceユーザーへの制限事項
付与可能なIAMロールの制限
Workforce Identityプールのユーザーにはオーナーロールを付与できませんが、編集者などのロールは付与できます。 https://cloud.google.com/iam/docs/configuring-workforce-identity-federation?hl=ja#representing-workforce-users
利用可能なサービスの制限
以下のページでは、Workforce Identity連携またはWorkload Identity連携を使用できるGoogle Cloudプロダクトの制限事項とサポートレベルが記載されています。 使用するGoogle Cloudプロダクトが、ID連携でサインインしたユーザーでも利用できるかどうかを確認してください。 https://cloud.google.com/iam/docs/federated-identity-supported-services?hl=ja
まとめ
この記事では、OktaとWorkforce Identityの連携により、Googleアカウントを持たないユーザーでもOktaの認証情報を使ってGoogle Cloudに安全にアクセスする方法を解説しました。
Oktaでのユーザー・グループ・アプリケーションの設定から、Workforce Identityでのプールとプロバイダの作成、属性マッピング、IAMロールの付与まで、具体的な手順をスクリーンショット付きで説明しました。
ぜひこの記事を参考に、OktaとWorkforce Identityの連携を検討してみてください。
参考
・Workforce Identityについて
https://zenn.dev/google_cloud_jp/articles/3f06bac31aa013
・SAMLの仕組みについて
https://www.hitachi-solutions.co.jp/iam/saml.html
https://qiita.com/Shinya-Yamaguchi/items/434fab8c39e806e69a88
※本記事は、ジーアイクラウド株式会社の見解を述べたものであり、必要な調査・検討は行っているものの必ずしもその正確性や真実性を保証するものではありません。
※リンクを利用する際には、必ず出典がGIC dryaki-blogであることを明記してください。
リンクの利用によりトラブルが発生した場合、リンクを設置した方ご自身の責任で対応してください。
ジーアイクラウド株式会社はユーザーによるリンクの利用につき、如何なる責任を負うものではありません。