LBもDNSもSSL証明書も不要！Cloud Run + IAPでの社内向けサービスの限定公開がここまで楽になった

こんにちは！製造ビジネステクノロジー部の石井です。

Cloud Run + IAP（Identity-Aware Proxy）で社内限定のWebサイトを公開する構成、以前はロードバランサーの作成、静的IPアドレスの予約、DNS設定、SSL証明書の管理...と、なかなか手間のかかるセットアップが必要でした。

それが2025年4月頃に、Cloud RunにIAPを直接有効化できる機能が追加されて、これらが全部不要に。
「認証の仕組みをアプリ側に作り込みたくないけど、組織外からはアクセスさせたくない」ってケースで、IAPを挟むだけで比較的楽にアクセス制御できるようになっています。

今回は、こちらの記事で紹介したSlidevの自己紹介スライドを題材に、この新しい構成でCloud Runにデプロイしてみました。
GitHub Actionsによる自動デプロイも組み合わせて、mainブランチにプッシュするだけで本番反映される構成にしています。

GCPリソースの事前準備はすべて Google Cloud コンソール（Web UI）で操作する手順にまとめているので、gcloud cliでのコマンド操作に抵抗がある方でも進められる内容にしてます。

【重要】この構成の対象範囲について

今回紹介するCloud Run + IAP直接統合の構成は、Google Workspace または Google Cloud Identity の組織内ユーザーのみがアクセス対象です。組織外のユーザー（外部パートナーや個人のGmailアカウントなど）を招待してアクセスさせたい場合は、この構成では対応できません。
https://docs.cloud.google.com/run/docs/securing/identity-aware-proxy-cloud-run?hl=ja#known_limitations

組織外ユーザーにもアクセスを許可したい場合は、従来どおりロードバランサー経由でIAPを構成する必要があります。用途に応じて構成を選択してください。

一応こちらの動画内で、組織外ユーザーも今後対応する予定ありみたいな発言をされてますが、現時点ではまだ招待できなそうでした💦
https://youtu.be/YLz3Xtf8LTc?si=v2HqJFOhEtExzu2G
5分20秒ぐらい〜

構成概要

使用技術:

• Cloud Run - コンテナベースのサーバーレス実行環境
• IAP（Identity-Aware Proxy） - Cloud Runに直接統合されたゼロトラスト認証
• GitHub Actions - CI/CDパイプライン
• Artifact Registry - コンテナイメージの管理
• Workload Identity Federation - GitHub ActionsからGCPへのキーレス認証

新構成（今回）

旧構成（以前）

以前のロードバランサー経由の構成と比べると、こんな感じで変わっています。

だいぶスッキリしましたね。

※ Cloud Runサービスの作成・デプロイ・IAP有効化はGitHub Actionsで完結しますが、前提となるGCPリソースのセットアップ（API有効化、Artifact Registry、WIF）と、デプロイ後のIAPアクセス権限設定はコンソール操作が必要です。

前提条件

• Google Cloud プロジェクトが作成済みであること
• プロジェクトが Google Cloud 組織 に属していること（Cloud Run直接IAP の要件）
• 会社のドメインで Google アカウントが発行されていること（IAPで組織内ユーザーのみにアクセスを制限するため）

1. デプロイ対象の準備

コンテナアプリケーションなら何でもいいですが、今回は以前の記事で作成したSlidevスライドをデプロイします。
Slidev自体の紹介はそちらの記事を参照してください。

2. Dockerfileの作成

最小限必要なフォルダ構成はこんな感じです。

project-root/
├── Dockerfile
├── nginx.conf
└── slidev/          # Slidevプロジェクト
    ├── package.json
    └── slides.md

デプロイするコンテンツをNginxで配信するためのDockerfileを作成します。今回はSlidevのビルド成果物を使うので、マルチステージビルドにしています。

# Build Stage
FROM node:20-slim AS build
RUN corepack enable pnpm
WORKDIR /app
COPY slidev/ .
RUN pnpm install --frozen-lockfile
RUN pnpm build

# Delivery Stage
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

SlidevはSPAなので、/5 のようなURLで直接アクセスしたときにも index.html を返すよう、nginx.conf で try_files を設定しておきます。

server {
    listen 80;
    server_name _;
    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

デプロイ時は --port 80 を指定すればOKです。

3. APIの有効化

Cloud RunやIAPを使うために、必要なAPIを有効化します。

1. Google Cloud コンソール の左メニューから APIとサービス > ライブラリ を開く

2. 以下のAPIをそれぞれ検索して「有効にする」をクリック
   • Cloud Run Admin API
   • Artifact Registry API
   • Cloud Identity-Aware Proxy API

検索バーにAPI名を入れて、出てきた結果のページで「有効にする」ボタンを押すだけなのでOKです！

4. Artifact Registryリポジトリの作成

DockerイメージをプッシュするためのArtifact Registryリポジトリを作成します。

1. 上の検索窓から Artifact Registry を開く
   

2. 上部の 「リポジトリを作成」 をクリック
   

3. 以下を入力する。残りはデフォルトから変更なしでOKです！

   • 名前: 任意（例: profile-slides）
   • 形式: Docker
   • ロケーションタイプ: リージョン
   • リージョン: asia-northeast1（東京）

4. 「作成」 をクリック

これでDockerイメージの保管先ができました。

5. GitHub Actions用サービスアカウントの作成

GitHub ActionsからCloud Runにデプロイするためのサービスアカウントを作成し、必要なロールを付与します。

1. 左メニューから IAMと管理 > サービスアカウント を開く

2. 上部の 「サービスアカウントを作成」 をクリック

3. 以下を入力

   • サービスアカウント名: GitHub Actions Deployer
   • サービスアカウントID: github-actions-deployer（自動入力される）

4. 「作成して続行」 をクリック
   

5. 「権限 (省略可)」 で以下のロールを追加

   • Artifact Registry 書き込み（Artifact Registry Writer）
   • Cloud Run 管理者（Cloud Run Admin）
   • サービスアカウント ユーザー（Service Account User）
     

6. 「続行」 → 「完了」 をクリック

ロールは「別のロールを追加」リンクをクリックすると追加できますよ。

6. Workload Identity 連携

GitHub ActionsからGCPにキーレスで認証するためのWorkload Identity連携を設定します。

1. 左メニューから IAMと管理 > Workload Identity 連携 を開く
   

2. 「開始」 をクリックしてウィザードを開始
   

以下、ウィザードの各ステップに沿って設定していきます。

ステップ1: プールの作成

1. 以下を入力
   • 名前: GitHub Actions Pool
2. 「続行」 をクリック
   

ステップ2: プロバイダの追加

1. 以下を設定
   • プロバイダの選択: OpenID Connect (OIDC)
   • プロバイダ名: GitHub Provider
   • プロバイダID: github-provider
   • 発行元（URL）: https://token.actions.githubusercontent.com
   • JWKファイル、オーディエンス: デフォルトのままでOK
2. 「続行」 をクリック
   

ステップ3: 属性マッピングの設定

1. 以下を設定
   • google.subject → assertion.sub
   • 「マッピングを追加」 をクリックして追加:
     • attribute.repository → assertion.repository
   • 属性条件: assertion.repository == '<GITHUB_ORG>/<REPO_NAME>'
     • 例: assertion.repository == 'my-org/profile-slides'
2. 「保存」 をクリック
   

無事作成が完了しました！

ステップ4: アクセスを許可する

GitHub Actionsが使用するサービスアカウントを設定します。

1. 上部の 「+アクセスを許可」 をクリック
   

2. 「サービス アカウントの権限借用を使用してアクセス権を付与する」 を選択

3. 以下を設定

   • サービスアカウント: GitHub Actions Deployer を選択
   • 属性名: repository を選択
   • 属性値: <GITHUB_ORG>/<REPO_NAME>（例: my-org/profile-slides）
     ※<GITHUB_ORG>/<REPO_NAME>の部分はここを使ってください！
     

4. 「保存」 をクリック
   

5. ダイアログが表示されますが閉じるで大丈夫です
   

設定項目が多くて大変ですが、一度設定してしまえばあとはキーのローテーションなど気にせず使えます！

7. GitHub Actionsワークフローの作成と初回デプロイ

ここまでの設定で、フォルダ構成は以下のようになっています。

project-root/
├── .github/
│   └── workflows/
│       └── deploy.yml    # これから作成
├── Dockerfile
├── nginx.conf
└── slidev/
    ├── package.json
    └── slides.md

.github/workflows/deploy.yml を作成します。

name: Deploy to Cloud Run

on:
  push:
    branches:
      - main

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Authenticate to Google Cloud
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: "projects/${{ vars.GCP_PROJECT_NUMBER }}/locations/global/workloadIdentityPools/github-actions-pool/providers/github-provider"
          service_account: "github-actions-deployer@${{ vars.GCP_PROJECT_ID }}.iam.gserviceaccount.com"

      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@v2
        with:
          install_components: 'beta'

      - name: Configure Docker
        run: gcloud auth configure-docker ${{ vars.GCP_REGION }}-docker.pkg.dev

      - name: Build and Push Docker image
        run: |
          docker build -t ${{ vars.GCP_REGION }}-docker.pkg.dev/${{ vars.GCP_PROJECT_ID }}/${{ vars.GCP_REPO_NAME }}/${{ vars.GCP_SERVICE_NAME }}:${{ github.sha }} .
          docker push ${{ vars.GCP_REGION }}-docker.pkg.dev/${{ vars.GCP_PROJECT_ID }}/${{ vars.GCP_REPO_NAME }}/${{ vars.GCP_SERVICE_NAME }}:${{ github.sha }}

      - name: Deploy to Cloud Run with IAP
        run: |
          gcloud beta run deploy ${{ vars.GCP_SERVICE_NAME }} \
            --image=${{ vars.GCP_REGION }}-docker.pkg.dev/${{ vars.GCP_PROJECT_ID }}/${{ vars.GCP_REPO_NAME }}/${{ vars.GCP_SERVICE_NAME }}:${{ github.sha }} \
            --region=${{ vars.GCP_REGION }} \
            --port=80 \
            --no-allow-unauthenticated \
            --iap

gcloud beta run deploy はサービスが存在しない場合は自動的に新規作成してくれるので、コンソールで手動作成したりローカルからイメージをプッシュしたりする必要はありません。
--iap フラグでCloud RunにIAPを直接有効化し、--no-allow-unauthenticated でCloud Runへの直接アクセスを拒否しています。
setup-gcloud の install_components: 'beta' で事前にbetaコンポーネントをインストールしておかないと、デプロイ時にインストール確認で止まっちゃうので注意です。

GitHub リポジトリのVariables設定

リポジトリの Settings > Secrets and variables > Actions > Variables タブに以下を登録します。

プロジェクト番号は Google Cloud コンソール 左メニューから ホーム > ダッシュボード で確認できます。

初回デプロイの実行

Variables設定が完了したら、main ブランチにプッシュして初回デプロイを実行します。

1. ワークフローファイルをコミットして main ブランチにプッシュ
2. GitHub リポジトリの Actions タブでワークフローが正常に完了することを確認
3. Cloud Runのコンソールでサービスが作成され、IAPが有効になっていることを確認

この時点ではIAPは有効になっていますが、ユーザーのアクセス権限がまだ設定されていないため、Cloud RunのURLにアクセスすると403が返ります。

8.アクセス権限の設定

IAP で保護されたリソースに対して、アクセスを許可するユーザーやグループを設定します。Cloud Run のセキュリティタブから直接設定できます。

1. 左メニューから Cloud Run を開き、作成したサービス（例: profile-slides）をクリック
   

2. 「セキュリティ」 タブを開いて**「ポリシーの編集」** をクリック
   

3. 「プリンシパルを追加」 をクリックし、以下を入力

   • プリンシパル: アクセスを許可するユーザー・グループ・ドメインのいずれかを入力
     • 特定のユーザー: user@your-domain.com
     • Google Group: team@your-domain.com
     • ドメイン全体: your-domain.com
   • アクセスレベル: 指定無しでOK！（地理的アクセス制限、パスベースのアクセス制御ができる）
     

4. 「保存」 をクリック

9.動作確認

すべての設定が完了したら、動作確認してみましょう。

1. Cloud RunサービスのURL（https://<SERVICE_NAME>-xxxxxxxx.a.run.app）にブラウザでアクセス
2. Googleアカウントでの認証画面が表示されることを確認
3. 組織内アカウントでログイン後、スライドが表示されればOK

もし403エラーが出る場合は、IAPのアクセス権限（ステップ8）やCloud Run起動権限の設定を見直してみてください。
※権限反映に2,3分程のラグがあるので少し時間をおいてみてください
以降はコードを main ブランチにプッシュするだけで、GitHub Actions経由で自動的にデプロイされます。

カスタムドメインを使いたい場合

今回の構成では *.run.app のデフォルトURLでアクセスしていますが、カスタムドメインを使いたいケースもあると思います。Cloud Runにはカスタムドメインのマッピング機能があるので、IAPの保護を維持したままカスタムドメインでアクセス可能。SSL証明書もCloud Runが自動で管理してくれるので、以前のようにロードバランサーやGoogleマネージド証明書を自分で設定する手間が省けます。

Cloud Runへのカスタムドメインの追加

1. 左メニューから Cloud Run を開く
2. 作成したサービス（例: profile-slides）をクリック
3. 上部の 「カスタムドメインを管理」（または 「インテグレーション」 タブ）をクリック
4. 「マッピングを追加」 をクリック
5. 以下を設定
   • サービスの選択: 対象のCloud Runサービスを選択
   • ドメイン: 使用するドメインを入力（例: profile-slides.your-domain.com）
6. 「続行」 をクリック

DNSレコードの追加

ドメインマッピングの作成後、画面にDNSレコードの設定内容が表示されます。ドメインのDNS管理画面で以下のCNAMEレコードを追加します。

DNSの反映後、Cloud Runが自動的にSSL証明書をプロビジョニングしてくれます。証明書が有効になるまで数分〜数十分かかる場合があります。

注意点

Cloud RunのIAP直接統合とロードバランサー経由のIAPは併用できません。複数リージョンでのグローバル分散やCloud CDNとの組み合わせが必要な場合は、従来どおりロードバランサー経由の構成を検討しましょう。

https://docs.cloud.google.com/run/docs/securing/identity-aware-proxy-cloud-run?hl=ja#known_limitations

まとめ

Cloud Run + IAPで社内限定公開する手順を、Google Cloud コンソールの操作ベースで紹介しました。

Cloud RunにIAPを直接統合できるようになったおかげで、以前必要だったロードバランサー、静的IP、DNS設定、SSL証明書の管理がまるっと不要になりました。さらに gcloud run deploy がサービスの新規作成にも対応しているので、ローカルでのDockerビルドやコンソールでの手動作成も不要で、最初からGitHub Actions一本でデプロイできるのもうれしいポイントです。

改めてこの構成のいいところをまとめると:

• Cloud Run でインフラ管理の手間なくコンテナをデプロイできる
• IAP でアプリ側にコードを追加せずゼロトラストなアクセス制御を実現できる
• Workload Identity Federation でサービスアカウントキーなしにGitHub Actionsから安全にデプロイできる
• GitHub Actions で main ブランチへのプッシュだけで自動的に本番反映される

社内向けの管理画面やちょっとしたWebツールなど、「認証の仕組みをアプリに組み込みたくないけど、組織外からはアクセスさせたくない」ってケースは結構あると思います。
そういうときにIAPを挟むだけでサクッと実現できるのは、覚えておいて損はないかなと。