はじめに

Google Cloud では、Cloud Run を使ってサクッとインターネット上にコンテナを立てられる。

そして 2026 年 3 月、Cloud Run に IAP（Identity-AwareProxy）を直接アタッチできる機能（= IAP for Cloud Run）が GA（一般提供）となった。

これによって、従来の複雑なロードバランサ設定なしで、コンソールなどから手軽に認証を有効化できる非常に強力な機能が利用可能になった。

本記事では、従来方式との比較に加え、Web 上に情報の少ない Terraform での実装手順を紹介する。

用語整理

Cloud Run

Google Cloud における Container as a Service(CaaS)のプロダクト。

ゼロスケールのできるサーバレスのサービスであり、Google Cloud でコンテナを立てたいときにまず選択肢に入る。

Identity Aware Proxy(IAP)

Google Cloud における認証(Authentication)を提供するプロダクト。

ブラウザからアクセスする際に、Google Account などで認証ができる。基本的には組織内部向け。

(ちなみに、一般ユーザー向けの認証機能には Identity Platform というプロダクトがある)

Google Cloud Load Balancing(GCLB)

Google Cloud におけるロードバランサーのサービス。

従来は IAP を利用する際に必須であり、LB 自体の維持にコストが発生する。

従来方式との比較

従来方式である GCLB をもちいた方式や、Identity Platform、Cloud IAM と比較すると下表のようになる。

	IAP for Cloud Run	IAP(LB)	Identity Platform	Cloud IAM
コスト	無料	高額	従量課金	無料
実装の手軽さ	高	低	中	高
アプリとの分離	完全	完全	低	完全
用途	少人数、内部向け	エンタープライズ	BtoC 向け	API, サービス間

今回紹介する IAP for Cloud Run だと、小規模チーム向けのプライベートな開発環境や管理画面を立てる用途などに使えるといえる。

実装手順

基本的に英語版の手順に従うが、OIDC 設定(外部 IdP 連携)については今回扱わない

参考: Configure IAP for Cloud Run | Google Cloud Documentation

また、terraform の使い方についても扱わない。

完成形のイメージ

API,権限の確認

基本的なことであるが、リソースを立てるには、Project 単位でリソースに対応した API の有効化と、作業者の権限が必要である。

有効化が必要な API

run.googleapis.com
iap.googleapis.com
artifactregistry.googleapis.com

作業者に必要な権限

service	role	用途
Cloud Run	roles/run.admin	Cloud Run の作成
IAP	roles/iap.admin	IAP 対応サービスへのアクセス権付与
IAM	roles/iam.serviceAccountUser	サービス ID に対する SA
Artifact Registry	roles/artifactregistry.reader	デプロイされたコンテナイメージに対する Artifact Registry 読み取り

リソース作成

以下に terraform の例を示す。
※ログイン用のアカウントは var で渡すように記載していることに注意されたい。


# 1. Cloud Run リソースの作成
# https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#example-usage---cloudrunv2-service-iap
resource "google_cloud_run_v2_service" "iap_test" {
  name                = "cloud-run-service-with-iap"
  location            = "asia-northeast1"
  deletion_protection = false                      ## terraform から試行錯誤しやすいように
  ingress             = "INGRESS_TRAFFIC_ALL"
  iap_enabled         = true
  scaling {
    max_instance_count = 3
  }

  template {
    containers {
      ## 既存のテスト用イメージを利用
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
  }
}

# 2. IAP から Cloud Run を起動できるように
# https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service_iam#google_cloud_run_v2_service_iam_member

resource "google_cloud_run_v2_service_iam_member" "invoker" {
  project = google_cloud_run_v2_service.iap_test.project
  location = google_cloud_run_v2_service.iap_test.location
  name = google_cloud_run_v2_service.iap_test.name
  role     = "roles/run.invoker"
  member   = "serviceAccount:service-${var.project_number}@gcp-sa-iap.iam.gserviceaccount.com"
}

# 3. IAM の認可を設定する
# https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/iap_web_cloud_run_service_iam#google_iap_web_cloud_run_service_iam_member

resource "google_iap_web_cloud_run_service_iam_member" "member" {
  project = google_cloud_run_v2_service.iap_test.project
  location = google_cloud_run_v2_service.iap_test.location
  cloud_run_service_name = google_cloud_run_v2_service.iap_test.name
  role = "roles/iap.httpsResourceAccessor"
  member = var.user_email ## ログインするユーザーの email,組織外の場合は OIDC の設定が必要(今回は扱わない)
}

output "service_url" {
  value = google_cloud_run_v2_service.iap_test.uri
}

疎通テスト

output.service_url の出力である URL を開く。コンソールや CLI から取得しても OK

※余談だが、 output.service_url は FQDN にリージョン名が含まれないが、コンソールや gcloud CLI から取得するとリージョン名が含まれる。
若干の表記揺れが生じるが、疎通確認には支障はない。

ログイン画面がでるので、ACCESS 権限を設定したアカウントでログイン

正しく疎通できれば、以下のような画面が出る
※IAM の伝播等で terraform apply から反映まで少し遅延が生じる可能性があるので注意されたい。

おわりに

本記事では、面倒なインフラ構築なしでセキュアな環境が手に入る IAP for Cloud Run を紹介した。

手軽に認証つきのコンテナをホストする上で、参考になれば幸いである。

参考ページ

Configure IAP for Cloud Run | Google Cloud Documentation : 英語版ガイド
IAP for Cloud Run を構成する | Google Cloud Documentation :日本語版ガイド(2026/8/11 時点。GA 前の記述)
https://docs.cloud.google.com/run/docs/release-notes#March_13_2026 : リリースノート