はじめに
今更かもしれませんが、Cloud Run で利用可能になった **Identity-Aware Proxy（IAP）を直接認証として活用できる Cloud Run for IAP についてやってみた記事を投稿します。
「社内向けのWeb管理画面や開発用ツールを Cloud Run で手軽に動かしたいけれど、アクセス制限はどうしよう？」とお悩みの方に最適な機能です。本記事では、従来の構成との違いや主な「使いどころ」、そして実際にアクセス制御を検証した結果を紹介します。
1. Cloud Run for IAP とは？
これまで Cloud Run で作成したアプリに IAP（Googleアカウント認証＋コンテキストベースのアクセス制御）を適用するには、HTTP(S) Load Balancer（Application Load Balancer）を前段に構築 する必要がありました。
しかし、直近のアップデートにより、ロードバランサを挟まずに Cloud Run 単体に直接 IAP を有効化できる機能 が提供されました。
従来（LB経由）と直接統合（Direct IAP）の比較
| 項目 | 従来の構成 (LB + IAP) | Cloud Run Direct IAP |
|---|---|---|
| ロードバランサ (ALB) | 必要 | 不要 |
| URL (エンドポイント) | カスタムドメイン必須 | デフォルトの *.run.app URL がそのまま使える |
| 構築コスト | 高（固定IP、SSL証明書、BackendServiceなど） | 低（ワンクリック / --iap オプションのみ） |
2. Cloud Run for IAP の「使いどころ」
「手軽さ」と「低コスト」が最大の強みであるため、以下のようなユースケースで真価を発揮します。
① 社内向け管理画面・バックオフィスツール
社内スタッフのみがアクセスするツール（例: 社内データ閲覧用ダッシュボード、管理画面など）において、独自ドメインや複雑なネットワークを組まずに、Google アカウントログインによる認証 を一瞬で付与できます。
② 開発・検証環境（Staging / QA環境）
「本番は独自ドメイン＋LBを組むが、開発・検証環境は低コストかつ手軽に特定のチームメンバーだけに限定公開したい」という場面に最適です。不要なLBのランニングコストを削減できます。
③ Webhook を使わないシンプルな社内マイクロサービス
社内ネットワーク・ブラウザ経由で利用するWebアプリ全般において、個別のアプリケーションコードにログイン処理（OAuth実装など）を組み込むことなく、プラットフォームレベルで安全な認証層を提供できます。
3. 検証手順
Google Cloud で用意されているサンプルコンテナを用いて Cloud Run サービスをデプロイし、IAP を適用する手順を解説します。
Step 1: Cloud Run サービスのデプロイ（IAP有効化）
今回はサンプルコンテナを使ってデプロイするため、重要な設定は下図で赤く囲んだ部分のみです。
デプロイした直後は IAP 認証の設定をしているものの、IAP 側で許可するユーザを制御していないのでエンドポイントにアクセスしても下図のようにアクセスできません。
Step 2: IAP サービスエージェントへ IAM 権限の付与
Google Cloud の内部的には IAP で認証をした後、IAP が Cloud Run を起動しているのか、IAP を使って Cloud Run にアクセスする場合は IAP のサービスエージェントに該当 Cloud Run に対する Cloud Run 起動元 (roles/run.invoker) ロールが必要となります。
既に付与されていることもありますが、付与されていない場合は下図のように Cloud Run 側の権限を確認します。
Step 3: アクセス許可ユーザーの設定
IAP がユーザーを認証した後、代理で Cloud Run を呼び出せるように IAP のサービスアカウントへ権限を付与します。
IAP のコンソール画面にアクセスすると、さきほど作成した Cloud Run に対する IAP が有効化されていることが分かります。
右の「プリンシパルの追加」をクリックし、アクセスを許可したいプリンシパルを追加します。
付与するロールは「IAP-secured Web App User (roles/iap.httpsResourceAccessor)」です。
4. 検証と挙動結果
設定完了後、アクセス制限が正しく動作しているか以下の2パターンで検証しました。
検証結果 ①: 許可されたユーザーでアクセスした場合
- ブラウザで Cloud Run の URL (
*.run.app) にアクセス - 自動的に Google のログイン画面（OAuth 2.0 画面）へリダイレクト
- 許可されたユーザーでログイン
【結果】
認証・認可が成功し、Cloud Run 上のアプリ（Hello画面）が正常に表示された。
検証結果 ②: 許可されていないユーザーでアクセスした場合
- ブラウザで同様の URL にアクセス
- Google ログイン画面にて、許可していないユーザーでログイン
【結果】
Cloud Run のアプリケーションコンテナにはリクエストが一切届かず、IAP 側ではじかれたことが分かります。ログを見ても Cloud Run まではリクエストが到達していないことを確認できます。
5. まとめ
- コストゼロ＆最小手間で認証追加: ロードバランサを用意せず、Cloud Run のデフォルトドメインで速やかに IAP 認証を導入可能。
-
堅牢なアクセス制御: IAMロール（
iap.httpsResourceAccessor）の有無によって、確実に 403 エラーでブロックされる。 - 推奨シナリオ: 社内ツール、ステージング環境、社内限定のプロトタイプ開発。
独自ドメインの割り当てや Custom WAF (Cloud Armor) が必要な本番サービスであれば従来どおり LB + IAP の構成が適していますが、「サクッと社内限定アプリを作りたい」というケースでは **Cloud Run Direct IAP ** がお手軽で便利だと思います。