Cloud Runのデプロイ時に「認証」設定で立ち止まったことはありませんか？
特にGoogle Cloud ConsoleのUIが新しくなり、「Cloud IAM を使用して受信リクエストを認証する」というチェックボックスと、その下のラジオボタンの組み合わせに戸惑う方もいらっしゃるかもしれません。
今回は、現在のCloud Runの認証設定における3つの明確なパターンを一つずつ解説し、それぞれの動作と最適なユースケースを考えてみたいと思います。
Cloud Run認証設定のUIの理解
まず、現在のGoogle Cloud ConsoleにおけるCloud Runの認証設定のUIを見てみましょう。
**「Cloud IAM を使用して受信リクエストを認証する」**というメインのチェックボックスがあります。
このチェックボックスをオンにすると、その下に2つのラジオボタンが表示され、どちらか一方を選択できます。
この選択肢の構造から、以下の3つの異なる設定パターンがあります。
パターン1: 「Cloud IAM を使用して受信リクエストを認証する」のチェックを外した場合
これが最もシンプルな、**「完全に公開されたサービス」**を意味する設定です。
- UI上の設定: 「Cloud IAM を使用して受信リクエストを認証する」のチェックボックスがオフ。
gcloudコマンドの概念:--allow-unauthenticatedに相当（ただし、IAMの認証レイヤーを完全にバイパスする意味合いがより強い）
動作のポイント:
- 匿名アクセスが完全に許可される: インターネット上の誰でも、認証情報を一切提示することなく、Cloud RunサービスのURLにアクセスできます。
- GCP IAMによる認証・認可は行われない: Cloud Runサービス自体が受信リクエストのGoogle IAM認証（IDトークンの検証やIAMポリシーによる権限チェック）を一切行いません。
- 高速な起動: IAM認証プロセスをスキップするため、認証レイヤーでのオーバーヘッドがなく、わずかながらレスポンス速度が向上する可能性があります。
- 用途:
- パブリックに公開するWebサイトやブログ
- 誰でも利用できるような公開API（例: 公開データ取得APIなど）
- フロントエンドアプリケーション（例: Next.js/Nuxt.jsのSSR）
- CORS設定などで特定のドメインからのアクセスを許可するWebサービス
- セキュリティの考慮: もしこのサービスが機密性の高いデータを扱ったり、重要な操作を実行したりする場合は、アプリケーションコード内部で独自の認証・認可ロジックを厳格に実装する必要があります。
まとめ: 「認証は完全にアプリ任せ。誰でもアクセスしてOK」という最もオープンなモードです。
パターン2: 「Cloud IAM を使用して受信リクエストを認証する」にチェック かつ 「認証が必要」にラジオボタンでチェックを入れた場合
これが、Cloud Runサービスを**「厳密に認証されたプライベートサービス」**として運用するモードです。
- UI上の設定:
- 「Cloud IAM を使用して受信リクエストを認証する」のチェックボックスがオン
- その下のラジオボタンで「認証が必要」が選択されている
gcloudコマンドの概念:--no-allow-unauthenticatedに相当
動作のポイント:
- 匿名アクセスは完全に拒否: 有効な認証情報を持たないリクエストは、Cloud Runサービスに到達する前にすべて拒否されます。
- IAM認証が必須: リクエストのヘッダーに、Googleが発行した有効なIDトークンが含まれている必要があります。
- IAM認可が実行: Cloud Runは、そのIDトークンに対応するGoogleアカウント（ユーザーまたはサービスアカウント）が、このCloud Runサービスに対する
run.routes.invoke権限をIAMポリシーで付与されているかを厳密にチェックします。 - 用途:
- 機密情報を扱うバックエンドAPI
- マイクロサービス間の内部通信
- 管理者ツールや特定ユーザーのみがアクセスできるWebアプリケーション
- GCP内の他のサービス（Cloud Functions, Compute Engineなど）からのセキュアな呼び出し
まとめ: 「認証情報がないとNG。さらに、その認証情報が『呼び出し権限を持つ』ものでないとNG」という、最もセキュアなモードです。
パターン3: 「Cloud IAM を使用して受信リクエストを認証する」にチェック かつ 「未認証の呼び出しを許可する」にラジオボタンでチェックを入れた場合
この設定は、一見すると矛盾しているように見えますが、Cloud Runが提供する**「コンテナが受信リクエストのIAM情報を参照できるが、匿名アクセスも許可する」**というモードです。
- UI上の設定:
- 「Cloud IAM を使用して受信リクエストを認証する」のチェックボックスがオン
- その下のラジオボタンで「未認証の呼び出しを許可する」が選択されている
動作のポイント:
- 匿名アクセスが許可される: パターン1と同様に、認証情報を持たないリクエストもCloud Runサービスに到達し、コンテナが起動します。
- IAM認可は常に成功: サービスに
run.invokerロールがallUsersに付与されているため、どのようなリクエスト（匿名を含む）であってもIAM認可チェックはパスします。 - IAM情報の「利用可能性」:
- もしリクエストに有効なGoogle IDトークンが含まれている場合、Cloud Runはそのトークンを検証し、トークン内のプリンシパル情報（誰が呼び出したか）をコンテナ内部の環境変数やヘッダー（例:
X-Goog-Authenticated-User-Email）として渡します。 - これにより、アプリケーションコードは、リクエストが認証されている場合はそのユーザー情報に基づいてパーソナライズされた応答を返したり、ログを記録したりできます。
- 認証情報がない（匿名）リクエストの場合、これらのヘッダーは提供されません。
- もしリクエストに有効なGoogle IDトークンが含まれている場合、Cloud Runはそのトークンを検証し、トークン内のプリンシパル情報（誰が呼び出したか）をコンテナ内部の環境変数やヘッダー（例:
- 用途:
※ まだ動作を完全に理解できておらず、以下のような用途に用いることができるかもしれません。追々検証してみたいと思います。- パーソナライズされたコンテンツ提供: ログインしているユーザーにはカスタマイズされたコンテンツを、ログインしていないユーザーには一般的なコンテンツを表示するようなWebサイト。
- アクセスログの強化: 認証されているリクエストについては、誰がアクセスしたかをCloud Runが提供する情報に基づいてログに記録したい場合。
- 公開APIだが、特定の認証ユーザーには追加機能やより高いレート制限を提供したい場合。
まとめ: 「基本的に誰でもアクセスしてOK。でも、認証情報があればそれをアプリに教えてあげるよ」という設定
※ ただし、「allUsersプリンシパルへのIAMロール付与の制限」とポリシーが設定されているプロジェクトの場合は、IAM ロール（Croud Run起動元）をallusersに付与できないためブロックされてしまいます。
3つの設定パターンを比較
| 設定パターン | 匿名アクセス | Cloud RunでのIAM認証チェック | コンテナでのIAM情報参照（存在すれば） | 主なユースケース |
| 「Cloud IAM を使用して受信リクエストを認証する」を外す | 許可 | 行わない | できない | 完全な公開サービス、アプリ側で認証 |
| 「Cloud IAM を使用して受信リクエストを認証する」 かつ 「認証が必要」 | 拒否 | 行う | 可能（常に存在する） | プライベートAPI、セキュアな内部サービス |
| 「Cloud IAM を使用して受信リクエストを認証する」 かつ 「未認証の呼び出しを許可する」 | 許可 | 行う | 可能（あれば存在する） | ハイブリッドな公開サービス、パーソナライズ |
適切な設定の選び方
- 誰でもアクセスさせたい、認証は完全にアプリ任せ: パターン1
- 特定のGoogleアカウント（ユーザー/サービスアカウント）しかアクセスさせたくない、最高レベルのセキュリティ: パターン2
- 基本的には誰でもアクセスさせたいが、もしユーザーがログインしていれば、その情報を利用してパーソナライズしたい: パターン3
Cloud Runの認証設定における3つの異なるパターンと、それぞれの動作について参考になれば幸いです。
コメント