🔐

Workforce Identity Federation を利用する

2023/12/11に公開

はじめに

アプリケーションモダナイゼーションスペシャリストの関本と申します。
今回は、Google Cloud Japan Advent Calendar の 8 日目の投稿として、アプリケーションモダナイゼーションとあまり関係がない、Workforce Identity Federation についてご紹介します。

TL;DR

Workforce Identity Federation を利用すると Cloud Identity を利用せずに他の IdP(Microsoft Entra ID などの外部 ID プロバイダー) の ID で Google Cloud を利用できます。

Workforce Identity Federation とは?

Google Cloud の外部(他のクラウドや Kubernetes など)で実行されているアプリケーションが、Service Account の Key を利用せずに Google Cloud 上のリソースを扱うことができる....

ってそれは Workload Identity Federation やないか!!!

と言うことで、とても似た名前の上記 Workload Identity Federation と異なり、Workforce identity federation は、他の IdP を利用して認証・認可を行い、ユーザー(Workforce、言い換えると人間)が Google Cloud にアクセスできるサービスです。実は、他の IdP を利用する方法には、Cloud Identity の Google Cloud Directory Sync (GCDS) と呼ばれる機能もあります。Workforce Identity Federation との違いは、GCDS では Cloud Identity 側にディレクトリが同期されるため、最終的には、Google Cloud の ID を使いログインするという点です。

それに比べてWorkforce Identity Federation では一連のプロセスにおいて Cloud Identity が使われることがありません。(ちなみにこの記事のカテゴリを Cloud Identity にしてしまっていましたのですが、全く真逆の内容になってしまいました )

Workforce Identity Federation は

  • 既存である IdP を利用したいが、ユーザーを同期するなどのディレクトリの二重管理を避けたい
  • Cloud Identity のみでは難しい属性ベース(アサーション、クレーム)での認証・認可をしたい
    などのユースケースが考えられます。

Workforce Identity Federation を使ってみる

前置きが長くなってしまいましたので、早速使ってみることにします。

外部 IdP を構成する

今回は Okta を利用して外部 IdP を構成することにします。他にも、Microsoft Entra ID やその他 OIDC,SAML2.0 をサポートする IdP との連携が可能です。Oktaより無料トライアルを開始します。
無料トライアル環境の作成後、Directory にユーザーとグループを追加しておきます。具体的な手順は、今回の本質的な部分でございませんので、省略いたします。

Workforce Identity Pool を作成する

まずは、連携ユーザーのための Workforce Identity Pool を作成する必要があります。今回は CLI より作成します。Cloud Shell で以下を実行します。

gcloud iam workforce-pools create WORKFORCE_POOL_ID \
    --organization=ORGANIZATION_ID \
    --description="DESCRIPTION" \
    --session-duration=SESSION_DURATION \
    --location=global

コマンド自体は、シンプルなもので、組織 ID やセッション継続時間などが必要なのですが、意外なことに WORKFORCE_POOL_ID はグローバルでユニークである必要性があることにご注意ください。(これは Callback URL に利用されるためです)また、gcp- と言う接頭辞は予約されているため使用できません。

Okta アプリケーションを作成する

こちらは、Okta 管理コンソールでの作業となります。OIDC プロトコルと SAML プロトコルの両方を使用した連携をサポートしていますが、今回は SAML2.0 を利用することとします。基本的には、こちらの手順通りに作業を進めれば問題ありません。

各 URL には Workforce Identity Pool の作成時に設定した Workforce Identity Pool の ID と この後の手順で指定する Workforce Identity Pool Provider の ID を含める必要があります。

https://auth.cloud.google/signin-callback/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID

アトリビュートのマッピングがやや複雑になりますが、最低限以下の画像の情報があれば、Subject と Group を伝えることが可能です。

Group は 正規表現で複数のグループ指定(ワイルドカードも可能)ですが、今回は特定のグループ(gceditors)のみを対象としています。
最後に、 Sign On タブの View SAML setup instructions というリンクをクリックします。
最下部の Optional という部分をコピーして .xml 形式で保存しておきます。

Workforce Identity Pool Provider を作成する

ここから、再度 Google Cloud 側の作業となります。Okta で作成したユーザーが Google Cloud にアクセスするために必要な Workforce Identity Pool Provider を作成します。

Cloud Shell より以下のコマンドを実行します。

gcloud iam workforce-pools providers create-saml WORKFORCE_PROVIDER_ID \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --attribute-mapping="google.subject=assertion.subject,google.groups=assertion.attributes.groups" \
    --attribute-condition="'gceditors' in assertion.attributes.groups" \
    --idp-metadata-path="XML_METADATA_PATH" \
    --location="global"

WORKFORCE_PROVIDER_ID は任意のものを利用できますが、Okta アプリケーションの URL に指定したものと一致する必要があります。
WORKFORCE_POOL_ID はプールの作成時に指定した任意の ID となります。
--attribute-mapping に対しては各属性のマッピングを設定する必要があり、先ほどの Okta アプリケーションで設定したものとマッチする必要があります。ここでは様々な属性を設定することができ SAML アサーションにより複雑な権限管理を可能とします。
XML_METADATA_PATH に対しては、Cloud Shell 上に配置した先ほどの xml ファイルのパスを指定します。

連携ユーザーの Google Cloud リソースへのアクセスを管理する

Workforce Identity federation 由来のユーザーの IAM ロールを設定します。
Cloud Shell で以下のコマンドで IAM を設定します。

ユーザー(1つの ID)に対して付与する場合は以下です。

gcloud projects add-iam-policy-binding TEST_PROJECT_ID \
    --role="ROLE" \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

グループに対して付与する場合は以下です。

gcloud projects add-iam-policy-binding TEST_PROJECT_ID \
    --role="ROLE" \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

attribute.department をマッピングしている場合はその単位でも付与することが可能です。

Workforce Identity Federation 経由でログインしてみる

Workforce Identity Federation 由来のユーザーがログインするページは通常のものとは異なります。
ログイン用の URL は [IAM と管理] > [Workforce Identity の連携]より [Workload Identity プール]の各プールに ログイン URL として記載されています。また、IdP 側を起点とするログインも可能です。

ブラウザにログイン URL を入力すると、Okta の認証画面にリダイレクトされます。

認証情報を入力するとGoogle Cloud コンソール(連携)を表示することができました。今回はrole/editorを IAM で設定していたためほぼ全てのサービスが見れる状態となっています。
このように GKE の Security Posture も表示することができました。とてもわかりやすいですね。(唐突な宣伝)

コンソール(連携)としているのは、実は通常のコンソールとは異なり全てのサービスに対応していない状況となっているためです。
対応状況はこちらとなります。ただし本機能は継続して対応が進んでいるため、今後も対応サービスは増えていく見込みです。ご期待ください。

まとめ

Workforce Identity Federation を利用して、Cloud Identity にユーザーを作らずにコンソールへのログインをすることができました。SAML アサーションを利用して複雑なログイン管理も可能となります。

Google Cloud Japan

Discussion