1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kimura50(Yasuhiro Kimura)
in

Cloud Runへ直接Identity-Aware Proxyを設定する構成でGoogle Workspace組織外ユーザを許容する方法

1
Last updated at Posted at 2026-08-17

こんにちは、博報堂テクノロジーズの木村です。

この記事では、Google CloudのCloud RunにてGoogle Workspace組織外のユーザーに対して、Identity-Aware Proxy（IAP）を利用した認証機能を利用する方法について解説します。

各構成要素と課題

この章では各構成要素の解説と、この構成で直面した課題について説明します。

Cloud Run

Cloud Run は、コンテナイメージをそのままデプロイできるサーバーレスなコンテナ実行基盤です。

Cloud Run単独では認証の機能を持たないため、アプリケーション側で実装するか、手前に認証の仕組みを置く必要があります。

Identity-Aware Proxy

Identity-Aware Proxy（IAP）は、アプリケーションの手前に立ち、認証認可処理を代行してくれるマネージドサービスです。アプリケーション側に認証コードを一切書かずに認証処理を実装することができます。

また、IAP では Access Context Manager（ACM）のアクセスレベルを利用することができます。アクセスレベルには接続元 IP レンジなどの条件を定義できるため、「許可されたメンバーが、特定のIPアドレスからアクセスした場合のみ許可する」といった制御もIAPでのみ実現することが可能です。

一方で従来の IAP は、LBのバックエンドサービスに対して有効化する方式が前提でした。そのため、グローバル IP・SSL証明書・DNS レコード・URLマップ・サーバーレスNEGといった ロードバランサー関連のリソースを全て構築する必要がありました。

Cloud RunへのIAPの直接設定

これに対し、2026年3月よりCloud Runへ直接IAPを適用する方式がGAされました。Terraform では、Cloud Runのリソースに1行追加するだけで利用可能です。

resource "google_cloud_run_v2_service" "main" {
  name     = "test-run-iap"
  ...
  # LBを挟まずCloud Runへ直接IAPを割り当てる
  iap_enabled = true
  ...
}

LBを利用しない構成となるため、社内向けのアプリケーションなどで、独自ドメインとWAFが不要で、認証とIP制限さえあればよいという要件に向いた構成となります。この構成をとることで、LBの構築と運用が不要となり、メンテナンスコストを下げて運用することが可能です。

課題

このように要件次第では便利なCloud Runへ直接IAPを設定する機能ですが、構築を進める中で組織外ユーザーのログインに失敗するという事象にあたりました。

これは、IAPはデフォルトでGoogleが管理するOAuth設定を用いて動作するためです。組織外のアカウントにIAM上でロールを付与してもログインできず、プロジェクトが属する組織内ユーザーしかログインできません。

これを解消するには、External（外部）のOAuth同意画面を持つカスタムOAuthクライアントを作成し、それを IAPに適用する必要があります。しかし、Cloud Runに直接IAPを設定する機能はGAされて日が経っておらずノウハウがまとまっていなかったため、今回はこの部分を中心に解説します。

設定手順

全体の流れは次のとおりです。ステップ1で必要なリソースをTerraformで構築した上で、ステップ2以降は手動手順にてOAuth周りの設定を実施します。

  1. TerraformでCloud Run+IAP+ACMを構築する
  2. OAuth同意画面をExternalで作成する
  3. 公開ステータスを設定する
  4. OAuthクライアントを作成し、リダイレクトURIを設定する
  5. カスタムOAuthクライアントをIAPに適用する

1. TerraformでCloud Run+IAP+ACMを構築する

まず、Cloud Run、IAP、ACMを構築します。なお、Cloud RunとIAPのAPIは有効化済みであることを前提に進めます。

ACMのアクセスレベルを作成する

以下の通り、ACMのアクセスレベルを作成します。なお、このACMのリソースのみ組織単位での作成となるため、組織レベルの権限が必要となります。

# 組織単位のアクセスポリシー。1組織につき1つしか作成できないため、
# 既存のポリシーがある場合はこのリソースを作らず、そのpolicy_idを参照する。
resource "google_access_context_manager_access_policy" "org" {
  parent = "organizations/<組織ID>"
  title  = "default policy"
}

resource "google_access_context_manager_access_level" "ip_restricted" {
  parent = "accessPolicies/${google_access_context_manager_access_policy.org.name}"
  name   = "accessPolicies/${google_access_context_manager_access_policy.org.name}/accessLevels/iprestricted"
  title  = "iprestricted"

  basic {
    conditions {
      # 許可する接続元IPレンジ
      ip_subnetworks = [
        "XX.XX.XX.XX/24",
      ]
    }
  }
}

Cloud Runを作成する

以下の通り Cloud Runを作成します。LBを挟まずアクセスを受け付けるため、 ingress は INGRESS_TRAFFIC_ALL とし、 iap_enabled を true に設定します。

locals {
  project = "test-project"
  location = "asia-northeast1"
}

resource "google_cloud_run_v2_service" "main" {
  project  = local.project
  location = local.location
  name     = "direct-iap-test-run"

  # LBを挟まないためIngressは全てのネットワークから受け付ける
  # IAPにてIP制限を実施する
  ingress = "INGRESS_TRAFFIC_ALL"

  # LBを挟まずCloud Runへ直接IAPを割り当てる
  iap_enabled = true

  template {
    containers {
      # テストコンテナ
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
  }
}

IAPに呼び出し権限を与える

IAPからCloud Runへの実際の呼び出しは、Google管理のサービスアカウントにて行われます。したがってCLoud Runの呼び出し権限である roles/run.invoker はこのサービスアカウントに付与します。

data "google_project" "this" {
  project_id = var.project_id
}

locals {
  project = "test-project"
  location = "asia-northeast1"
  # Google管理のサービスアカウント。iap.googleapis.com有効化時にGCPが自動作成する。
  iap_service_agent_email = "service-${data.google_project.this.number}@gcp-sa-iap.iam.gserviceaccount.com"
}

# run.invokerを付与する。
resource "google_cloud_run_v2_service_iam_member" "iap_invoker" {
  project  = local.project
  location = local.location
  name     = google_cloud_run_v2_service.main.name
  role     = "roles/run.invoker"
  member   = "serviceAccount:${local.iap_service_agent_email}"
}

アクセス許可とIP制限を設定する

アクセスを行うユーザーに対して roles/iap.httpsResourceAccessor を付与し、IAM Conditions で ACM のアクセスレベルを要求します。

locals {
  # ダッシュボードの利用者、ユーザーでもグループでも適用可
  iap_members = [
    "user:test-user@example.com"
    "group:test-grou@example.com",
  ]

  # IAPのIP制限に用いるACMアクセスレベル。組織レベルで作成済みのものを設定する。
  access_levels = [
    "accessPolicies/<ポリシーID>/accessLevels/iprestricted",
  ]
}

resource "google_iap_web_cloud_run_service_iam_member" "accessor" {
  for_each = toset(local.iap_members)

  project                = local.project
  location               = local.location
  cloud_run_service_name = google_cloud_run_v2_service.main.name
  role                   = "roles/iap.httpsResourceAccessor"
  member                 = each.value

  # IAMコンディションでACMアクセスレベルを要求する
  condition {
    title       = "access-level-restriction"
    description = "許可されたAccess Context Managerアクセスレベルからのアクセスのみを許可する"
    expression  = join(" || ", [for level in local.access_levels : "\"${level}\" in request.auth.access_levels"])
  }
}

動作確認

ここまでの手順を実施すると組織内のユーザーの場合はアクセス可能になりますが、組織外のユーザーの場合はアクセスが拒否されることが分かります。

image1.png

2. OAuth同意画面をExternalで作成する

対象プロジェクトのコンソールから Google Auth Platform → ブランディング を開き、開始 から以下を入力します。

  • アプリ名：<アプリ名>
  • ユーザーサポートメール：担当者のメールアドレス
  • 対象（Audience）：External（外部）
  • デベロッパーの連絡先メール：担当者のメールアドレス

対象を External にすることで、組織外ユーザーを許可することが可能になります。

なお、「OAuthブランドは1プロジェクトにつき1つ」しか作成できません。同一プロジェクト内の他の機能がOAuth同意画面を利用している場合は共用することになるため、アプリ名などを事前に調整する必要があります。

3. 公開ステータスを設定する

Externalの同意画面を作成後の テスト 状態から 本番 に切り替えます。

なお、本番に設定することでOAuth同意画面に全てのユーザーが到達できるようになりますが、ログイン自体ができても、IAMで許可されていなければ403となり、アプリケーションには到達できません。

4. OAuthクライアントを作成し、リダイレクトURIを設定する

Google Auth Platform → クライアント から クライアントを作成 を選び、以下を入力します。

  • アプリケーションの種類：ウェブアプリケーション
  • 名前：<アプリ名>

作成後に表示されるクライアントIDとクライアントシークレットを控えておきます。

続いて、作成したクライアントを再度編集し、承認済みのリダイレクトURIに以下を追加します。

<https://iap.googleapis.com/v1/oauth/clientIds/><クライアントID>:handleRedirect

リダイレクト URI に自身のクライアント ID を含める必要があるため、一度OAuthクライアントを作成してから、もう一度編集して設定するという順序になります。

5. カスタムOAuthクライアントをIAPに適用する

最後に、作成した OAuthクライアントをIAPに紐付けます。この操作はコンソールではなく gcloud コマンドで行います。--resource-type=cloud-run を設定することで、Cloud Runに対するIAPの設定ができます。

cat << EOF > iap-oauth.yaml
accessSettings:
  oauthSettings:
    clientId: <クライアントID>
    clientSecret: <クライアントシークレット>
EOF

gcloud beta iap settings set iap-oauth.yaml \
  --project=<プロジェクトID> \
  --resource-type=cloud-run \
  --region=asia-northeast1 \
  --service=<Cloud Runのサービス名>

動作確認

ここまでの手順を実施すると組織外のユーザーについてもログインできるようになります。

image2.png

まとめ

本記事では、Cloud Runに対してLBを介さず直接IAPを適用する構成と、組織外ユーザーにアクセスを許可するための手順を解説しました。

「認証とIP制限さえあればよい」という要件であれば、今回紹介した直接IAPを適用する設定は維持・メンテナンスコストを下げることができる構成となります。

同様の構成を検討されている方の参考になれば幸いです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?