【アップデート】Cloud RunでIdentity-Aware Proxyを直接構成できる機能がGAされました
はじめに
こんにちは。
クラウド事業本部コンサルティング部の渡邉です。
2026年3月13日に、Cloud RunでIdentity-Aware Proxy（IAP）を直接構成できる機能がGAになりました。
皆さんはGoogle Cloud上に構築した社内サービスへの認証はどのように実装していましたか？
Google Workspaceや、Cloud Identityを社内で利用しており、企業ドメインのGoogleアカウントを保有している場合は、Google CloudのIdentity-Aware Proxyを利用することでGoogleアカウントでの認証を簡単に行うことができます。
社内サービスの基盤にCloud Runサービスを利用するユーザも多いと思いますが、従来、Cloud RunでIAPを適用するには、ロードバランサーを前段に配置し、OAuthの設定をおこなったりと複数のステップを踏む必要がありました。
今回のCloud RunでIdentity-Aware Proxy（IAP）を直接構成できる機能がGAになったことにより、ロードバランサーなしでCloud Runサービスに直接IAPを有効化することができ、run.appのデフォルトURLを含むすべてのイングレスパスが保護されるようになりました。
本記事では、この機能の概要と実際にCloud RunサービスでIAPを有効化して認証させるところまで実施します。
Cloud RunでIAPを直接有効化するメリット
従来、Cloud RunにIAPを適用するには以下のような構成が必要でした。
この構成では、ロードバランサーのリソース（外部IPアドレス、SSL証明書、バックエンドサービス等）のプロビジョニングが必要であり、追加コストや構成の複雑さが課題でした。また、ロードバランサー経由のIAPでは run.app のデフォルトURLは保護されないため、別途イングレスの制御が必要でした。
今回のCloud RunでIdentity-Aware Proxy（IAP）を直接構成できる機能がGAになったことにより、以下のようにシンプルな構成にすることができます。
このようなシンプルな構成にすることにより、以下のメリットがあります。
- ロードバランサー不要: リソースのプロビジョニングが不要で、追加コストがかからない
- セットアップが簡単: コンソールからワンクリック、または gcloud CLI のフラグ1つで有効化
- デフォルトURLも保護:
run.appURLを含むすべてのイングレスパスが保護される - ロードバランサーとの併用も可能: 前段にロードバランサーを配置した場合、そのエンドポイントも保護される
制限事項
一方、IAPをCloud Runで直接有効化する際にはいくつかの制限事項があることを知っておく必要があります。
| 制限事項 | 詳細 |
|---|---|
| 組織が必須 | プロジェクトは組織内に存在する必要がある |
| 組織内IDのみ | 基本、同じ組織内のIDのみがアクセス可能（外部ユーザーは追加でカスタムOAuthの設定が必要） |
| IAP の重複構成不可 | ロードバランサーと Cloud Runサービスの両方でIAPを有効化することはできない |
| 一部の統合機能への影響 | Pub/Subなど一部のサービスがIAP有効化後に正しく認証できない場合がある |
必要な IAM ロール
IAPを有効化するために必要なIAMロールは以下の通りです。
| ロール | ロール ID | 用途 |
|---|---|---|
| Cloud Run 管理者 | roles/run.admin |
Cloud Run サービスの管理 |
| IAP ポリシー管理者 | roles/iap.admin |
IAP ポリシーの管理 |
| Artifact Registry 読み取り | roles/artifactregistry.reader |
コンテナイメージの読み取り |
| サービスアカウントユーザー | roles/iam.serviceAccountUser |
サービス ID の使用 |
やってみた
実際に、Cloud RunサービスでIAPを有効化してみます。
前提条件
- Google Cloudプロジェクトが組織に所属していること
- IAP API が有効化されていること
- 必要なIAMロールが付与されていること
IAP API の有効化
まず、自身のプロジェクトのIAP API を有効化します。
- Google Cloud コンソールで [APIとサービス] > [ライブラリ] に移動します
- 検索バーに [Identity-Aware Proxy] と入力します
- Identity-Aware Proxy API を選択し、[有効にする] をクリックします
gcloudコマンドで有効化する場合は、以下のコマンドを実行してください。
gcloud services enable iap.googleapis.com
Cloud Runサービスのデプロイ（IAP 有効）
次にIAPを有効化にしたCloud Runサービスをデプロイしていきます。
- Google Cloud コンソールで [Cloud Run] に移動します
- [サービス] をクリックします
- [サービスを作成] をクリックします
- コンテナイメージのURLに
us-docker.pkg.dev/cloudrun/container/hello:latestを指定します- これは
サンプルコンテナでテストをクリックすることで、自動的にURLが指定されます。
- これは
- サービスの名前に
cloud-run-for-iap、リージョンにasia-northeast1を設定します - [認証] セクションで [認証が必要] を選択します
- [Identity and Access Management (IAM)]と[Identity-Aware Proxy (IAP)] のトグルを 有効 にします
- [作成] をクリックします
Cloud Runをデプロイすることができました。
gcloudコマンドで新しいサービスをデプロイする場合は、--iap フラグを付けることでデプロイすることができます。
gcloud beta run deploy cloud-run-for-iap \
--region=asia-northeast1 \
--image=us-docker.pkg.dev/cloudrun/container/hello:latest \
--no-allow-unauthenticated \
--iap
IAP サービスエージェントに Invoker 権限を付与
次に、IAPがCloud Runサービスを呼び出せるよう、IAPサービスエージェントに roles/run.invokerロールを付与します。
Cloud Runサービスへの権限状況の確認方法としては以下の方法で行います。
- Google Cloud コンソールで [Cloud Run] に移動します
- サービス一覧から対象のサービスの左側にあるチェックボックスを選択し、[権限] タブをクリックします
- 右側に表示される情報パネルで [Cloud Run起動元] をクリックしてIAPサービスエージェントの
service-{PROJECT_NUMBER}@gcp-sa-iap.iam.gserviceaccount.comを確認します
gcloudコマンドで設定する場合は、以下のコマンドを実行してください。
gcloud run services add-iam-policy-binding cloud-run-for-iap \
--region=asia-northeast1 \
--member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-iap.iam.gserviceaccount.com \
--role=roles/run.invoker
IAP が有効化されたことを確認
IAP が正しく有効化されたことを確認します。
- Google Cloud コンソールで [Cloud Run] に移動します
- 対象のサービス（
cloud-run-for-iap）をクリックします - [セキュリティ] タブを開き、Identity-Aware Proxy (IAP) が「有効」になっていることを確認します
gcloudコマンドで確認する場合は、以下のコマンドを実行してください。
gcloud beta run services describe cloud-run-for-iap \
--region=asia-northeast1
出力に以下の文字列が含まれていれば、IAP が有効化されています。
Iap Enabled: true
アクセスを許可するユーザーの追加
IAP で保護されたサービスにアクセスできるユーザーを追加します。
- Google Cloud コンソールで [セキュリティ] > [Identity-Aware Proxy] に移動します
- [アプリケーション] タブでリソースの一覧から対象の Cloud Run サービス（
cloud-run-for-iap）を見つけます
- サービスの左側にあるチェックボックスを選択します
- 右側に表示される情報パネルで [プリンシパルを追加] をクリックします
- [新しいプリンシパル] にアクセスを許可するユーザーのメールアドレスを入力します
- [ロール] で [IAP-secured Web App User]（
roles/iap.httpsResourceAccessor）を選択します - [保存] をクリックします
gcloudコマンドで設定する場合は、以下のコマンドを実行してください。
gcloud beta iap web add-iam-policy-binding \
--member=user:USER_EMAIL \
--role=roles/iap.httpsResourceAccessor \
--region=asia-northeast1 \
--resource-type=cloud-run \
--service=cloud-run-for-iap
動作確認
ブラウザで Cloud Run サービスの URL にアクセスすると、Google アカウントのログイン画面にリダイレクトされます。
IAPで許可されたユーザーでログインすると、Cloud Run サービスのコンテンツが表示されます。
許可されていないユーザーでアクセスした場合は、You don't have accessとアクセス拒否のエラー画面が表示されます。
従来方式（ロードバランサー経由）との比較
従来のロードバランサ経由でのIAPと今回のCloud Runの直接のIAPの比較について以下に記載します。
| 項目 | Cloud Run 直接 IAP（今回 GA） | ロードバランサー経由 IAP |
|---|---|---|
| セットアップの簡便さ | フラグ1つで有効化 | LB・バックエンドサービス等の構成が必要 |
| 追加コスト | なし | ロードバランサーの費用が発生 |
run.app URL の保護 |
保護される | 保護されない（別途イングレス制御が必要） |
| 複数リージョン対応 | サービスごとに個別設定 | グローバル LB で一元管理可能 |
| 推奨シナリオ | 単一サービスの保護 | 複数リージョンの Cloud Run を集中管理する場合 |
コンテキストアウェアアクセスポリシー
Cloud RunサービスのIdentity-Aware Proxy (IAP)の設定画面から **[ポリシーの編集]**をクリックすると、コンテキストアウェアアクセスポリシーを設定することができます。
コンテキストアウェアアクセスポリシーの設定をすることで、ユーザの接続元IPアドレスやデバイス情報に基づいたアクセスレベルでの制御を行うことも可能です。
まとめ
今回は、2026年3月13日にGAになったCloud RunでIdentity-Aware Proxy（IAP）を直接構成できる機能について解説と検証を行ってみました。
この機能については、去年の4月頃にPreviewでリリースされていましたが、なかなかGAにならず本番適用することに躊躇があった方も多いと思います。
昨今盛り上がりを見せているAIエージェントアプリケーションのデプロイ先や、社内向けのダッシュボード、管理画面など、組織内のユーザーのみがアクセスするアプリケーションでは、Cloud Runを利用するケースも多いです。ロードバランサーのコストや構成の手間をかけずにIAPによる認証を導入できるため、非常に有用な機能だと思います。
一方で、複数リージョンにまたがるサービスを一元管理したい場合は、引き続きロードバランサー経由でのIAP構成が適していますので、ユースケースに応じて、適切な方式を選択していただければと思います。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部コンサルティング部の渡邉でした！
