IAPでCloud Runを直接保護しつつ、組織外ユーザーを通す

はじめに

皆さん、こんにちは。システム開発部のashinoです。

以前、「IAPでCloud Runを直接保護する」という記事を書きました。ロードバランサーなしでCloud RunにIAPを直接設定できる、という機能を紹介した記事です。

その記事の途中に、こんな注意書きを添えていました。

IAPを直接Cloud Runに設定する場合、現状では組織に所属するGoogleアカウントからのアクセスに限定され、組織外のID（個人のGmailアカウントなど）はアクセスできません。

実はこの制約、もう解消されています。

きっかけは、資格試験の勉強用に自作した模擬試験アプリでした。社内の個人用SandboxプロジェクトにCloud Runでデプロイし、直接IAPで保護していたのですが、これを自宅のPCやスマートフォンから、個人のGmailアカウントで見たいと思ったのです。アクセスしてみると、案の定「You don’t have access」の表示。組織外のIDだから弾かれているわけです。

「じゃあやっぱりダメなのか」と思いつつ念のため調べてみたところ、カスタムOAuthクライアントを設定することで、組織外のGoogleアカウントもIAPを通過できるようになっていました。この記事では、その手順と、実際に試してみて分かったハマりどころを紹介します。

何が変わったのか

まず、前回の記事で紹介した「ロードバランサーなしの直接IAP」自体のステータスを整理しておきます。Cloud Runのリリースノートによると、以下のような流れでした。

• 2025年4月 ロードバランサー不要の直接IAPがPreviewとして公開
• 2026年3月13日 直接IAPがGeneral Availability（GA）に

参考: Cloud Run のリリースノート

そしてこのGAと前後して、IAPの旧来のOAuthクライアント管理API（gcloud iap oauth-brands コマンドなど）が廃止されています。サポート終了が2026年1月19日、API自体の完全停止が2026年3月19日で、現在カスタムOAuthクライアントを作るには、後述するようにGoogle Cloud Consoleから設定するのが正規のルートです。

参考: Migrate from the IAP OAuth Admin API

前回の記事を書いた時点（2025年9月）では、直接IAPはまだPreviewで、組織外ユーザーへの対応もありませんでした。今回は、Cloud Runの直接IAP保護がGAし、組織外ユーザーにも対応した後の話、ということになります。

外部ユーザーを通す仕組み - カスタムOAuthクライアント

IAPはデフォルトでは、Googleが管理するOAuthクライアント（Google管理OAuth）を使って認証します。これは組織に所属するGoogleアカウントのみを対象としているため、個人のGmailアカウントなど組織外のIDは、そもそもログイン画面より先に進めません。

このデフォルトのOAuthクライアントを、自分で作成した カスタムOAuthクライアント に差し替え、OAuth同意画面の公開ステータスを External（外部） にすることで、組織外のGoogleアカウントでもログインできるようになります。もちろん、ログインできるだけでは不十分で、実際にアクセスを許可するかどうかはIAMのロール付与で個別に制御します。「認証の対象を広げる」のと「誰を通すか」は別レイヤーの話、というのがポイントです。

なお、そもそも認証自体を必要とせず誰でも見られる状態にしたい場合は、IAMのinvokerチェック自体を無効化する「公開アクセス」という別の設定もあります。ただしこれは「特定の人だけに絞る」話とは逆方向の要件なので、今回は扱いません。

実際に設定してみる

前回の記事の続きとして進めますが、直接IAPを有効にするコマンド自体はGAに伴って変わっており（betaトラック不要のgcloud run deployで設定できます）、前回の記事の手順はPreview当時のものです。まだIAPを直接設定していない場合は、前回の記事ではなくCloud RunでIAPを構成する（公式ドキュメント）を参照して設定してください。

※ このドキュメントの日本語版（?hl=ja）は本稿執筆時点で翻訳が追いついておらず、GA前の「プレビュー版」表記やgcloud beta run deployのコマンドが残っています。正確な情報を確認したい場合は、英語版を参照することをおすすめします。

IAPでカスタムOAuthクライアントを使用する（公式ドキュメント）の構成に沿って、「ブランディングページの構成」→「Audienceの設定」→「カスタムOAuthクライアントの作成（方法1または方法2）」の順で進めます。

1. ブランディング ページを構成する

カスタムOAuthクライアントを使うには、事前にOAuth同意画面（ブランディングページ）を構成しておく必要があります。これは、この後の方法1・方法2どちらを選ぶ場合にも共通の前提です。

1. Google Cloudコンソールで、OAuthの「ブランディング」ページに移動します（初回は「開始」をクリックします）。
2. 「アプリ名」に、同意画面に表示するアプリケーションの名前を入力します。
3. 「ユーザー サポートメール」に、サポート用の管理者のメールアドレスを入力します。
4. 「デベロッパーの連絡先情報」に、管理者のメールアドレスを入力します。
5. 「保存」（初回は「作成」）をクリックします。

ロゴやアプリのドメイン情報は任意項目で、アプリを外部公開審査に出さない限り必須ではありません。

2. 「対象」タブでユーザーの種類を外部にする

ブランディングページとは別に、「対象」タブでユーザーの種類を設定します。組織内のユーザーにアクセスを制限する場合は「内部」、組織外のユーザーにアクセスを許可する場合は 「外部」 にします。

すでに「内部」になっている場合も、「対象」タブのボタンから切り替えられます。

3. カスタムOAuthクライアントを作成する

ブランディングページの構成後、カスタムOAuthクライアントを作成します。公式ドキュメントでは、IAPの「認証情報を自動生成」機能を使う簡単な方法（方法2）も用意されており、こだわりがなければそちらがおすすめです。今回は、OAuthクライアントを個別に作成する方法（方法1）で構築したので、その手順を紹介します。

方法1: Google Cloud コンソールを使用してOAuthクライアントを作成する（今回はこちらのみ紹介）

IAPを構成する前に、OAuthクライアントを個別に作成する方法です。リダイレクトURIは自分で追加する必要があります。

1. Google Cloudコンソールで、「APIとサービス」＞「認証情報」に移動します。

2. 「認証情報を作成」をクリックし、「OAuthクライアントID」を選択します。

3. 「アプリケーションの種類」で「ウェブアプリケーション」を選択します。

4. 「名前」フィールドに、OAuthクライアントのわかりやすい名前を入力します。

5. 「作成」をクリックします。生成されたクライアントIDをメモします。

6. OAuthクライアントが作成されたら、そのクライアントの詳細ページの「承認済みのリダイレクトURI」セクションに移動します。

7. 「URIを追加」をクリックして、次の形式のリダイレクトURIを入力します。

   https://iap.googleapis.com/v1/oauth/clientIds/YOUR_CLIENT_ID:handleRedirect

   YOUR_CLIENT_IDは、前の手順で取得したクライアントIDに置き換えます。

8. 「保存」をクリックします。

この後、IAPの設定画面で「カスタムOAuth」を選択し、先ほど作成したクライアントIDとクライアントシークレットを入力して保存すれば設定完了です。

4. 組織外ユーザーにアクセス権限を付与する

前回の記事と同様に、IAMの「IAP-secured Web App User」ロール（roles/iap.httpsResourceAccessor）を、通したいユーザーに付与します。組織内・組織外を問わず、同じロールで管理できます。

gcloud iap web add-iam-policy-binding \
  --member=user:EXTERNAL_EMAIL_ADDRESS \
  --role=roles/iap.httpsResourceAccessor \
  --region=REGION \
  --resource-type=cloud-run \
  --service=SERVICE_NAME

なお、この設定作業自体を行う管理者側には、roles/iap.settingsAdmin（IAP Settings Admin）とroles/oauthconfig.editor（OAuth Config Editor）のロールが必要です。設定を変更しようとして権限エラーになったら、まずここを確認してください。

設定が反映されるまで少し待ってから、組織外のGoogleアカウントでサービスのURLにアクセスしてみましょう。今度はGoogleアカウントのログイン画面まで進み、ログイン後にページが表示されるはずです。

実際にやってみて気づいたこと

• roles/run.invokerの付与忘れ: 権限を付与していざアクセスしてみたら、ログイン画面は通過したのにForbidden。「あれ、設定したのに？」と一瞬固まりましたが、「たしかさっきドキュメントで見た気がする」と思い出し、併せてAIにも聞いて確認したところ、案の定でした。IAPサービスエージェント（service-[PROJECT_NUMBER]@gcp-sa-iap.iam.gserviceaccount.com）へのCloud Run roles/run.invoker付与が漏れていたのが原因です。前回の記事の手順通りに構築していれば問題ありませんが、既存サービスに後からIAPを追加した場合は見落としがちなポイントでした。
• 設定反映に時間がかかることがある場合も: 公式ドキュメントによると、カスタムOAuthクライアントの設定やIAM権限の反映には数分から数時間かかることがあるそうです。今回は特に待たされることはありませんでしたが、すぐに反映されなくても慌てず、少し時間を置いてから再確認するとよさそうです。
• クライアントシークレットは再表示できない: OAuthクライアントのシークレットは、作成時に一度しか表示されません。今回はハマらずに済みましたが、これは以前別の場面でシークレットを紛失して焦った経験があり、事前に気をつけていたポイントです。紛失した場合は再表示ではなく、ローテーション（再生成）が必要になります。

まとめ

前回の記事で「組織外のIDはアクセスできない」としていた制約は、Cloud Runの直接IAP保護のGAとカスタムOAuthクライアントの組み合わせで解消されていました。ロードバランサーを立てずに、Google Cloud Consoleでの設定だけで、取引先の担当者や個人のGoogleアカウントなど、組織外の特定ユーザーを安全に通せます。

「組織外ユーザーを通したいだけなのに、そのためだけにロードバランサーを立てるのは大げさだ」と感じていた方には、特に刺さる話ではないでしょうか。私自身、資格勉強用の個人アプリで試すことになるとは思っていませんでしたが、リリースノートをこまめに追っておくと、こういう「実は解決していた」に気づけるものだと実感しました。