IAPでCloud Runを直接保護する

はじめに

皆さん、こんにちは。SIグループのashinoです。

「社内向けにちょっとしたWebアプリケーションを安全に公開したいけど、どうすればいいんだろう？」 「アクセスできる人をGoogleアカウントで限定したいだけなのに、わざわざロードバランサーを立てるのは大げさだし、設定も複雑そう…」

インフラを学び始めた方や、アプリケーション開発者の方にとって、認証機能の実装は最初の一歩でつまずきやすいポイントではないでしょうか。自前で認証システムを構築するのは大変ですし、かといって誰でもアクセスできる状態にするわけにはいきません。

しかし、ご安心ください。Google Cloudには、この課題を驚くほどスマートに解決する「Cloud RunへのIAP直接設定」機能があります。これを使えば、ロードバランサーなしで、簡単かつセキュアにアクセス制御を実現できてしまいます。

この記事では、Cloud RunとIdentity-Aware Proxy（IAP）の組み合わせについて、その背景にある「ゼロトラスト」という現代的なセキュリティの考え方から、具体的な設定手順まで、一から解説していきます。

Cloud RunとIAPを組み合わせる

本題に入る前に、今回の主役である「Cloud Run」と「IAP」について、簡単におさらいしておきましょう。

Cloud Runとは？

Cloud Runとは、コンテナ化されたアプリケーションを、Googleのインフラ上で実行するためのフルマネージドなサービスです。サーバーやクラスターといったインフラの管理はGoogle Cloudに任せて、開発者はアプリケーションのコードとコンテナイメージに集中できるのが大きな特徴です。アクセスがないときはゼロにスケールダウンしてくれるので、コスト効率も非常に高いのが魅力です。

IAP (Identity-Aware Proxy) とは？

IAPは、その名の通り「IDを意識したプロキシ」です。アプリケーションにアクセスしようとするユーザーが誰であるか（ID）を確認し、許可されたユーザーだけを通過させる「関所」のような役割を果たします。これを導入することで、アプリケーション自体に認証機能を組み込むことなく、Googleアカウントに基づいた強力なアクセス制御を実現できます。

IAPとVPN、何が違うの？ - ゼロトラストという考え方

従来、社内リソースへの安全なアクセスにはVPN（Virtual Private Network）が使われてきました。VPNは「社内ネットワークの内側は安全」という前提に立つ「境界防御」の考え方です。

一方、IAPは「ゼロトラスト（何も信頼しない）」という、より新しいセキュリティ概念を体現しています。これは、社内ネットワークの内外を問わず、すべてのアクセスを疑い、毎回ユーザーの身元と権限を確認するアプローチです。リモートワークが普及し、ネットワークの「境界」が曖昧になった現代において、非常に重要な考え方となっています。

比較項目	IAP（Identity-Aware Proxy）	VPN（Virtual Private Network）
セキュリティ概念	ゼロトラスト（何も信頼しない）	境界防御（内側は信頼する）
アクセス制御	GoogleアカウントとIAMによるきめ細かなアクセス制限	ネットワークレベルでのアクセス許可
運用コスト	クラウドネイティブでハードウェア不要	オンプレミス機器の導入・運用コスト
クライアント	Webブラウザだけでアクセス可能	専用ソフトウェアや設定が必要

なぜ「IAPでCloud Runを直接保護する」のが嬉しいのか？

これまでCloud RunでIAPを利用するには、外部HTTPSロードバランサーを設置する必要がありました。 この構成は強力ですが、設定が複雑でコストもかかります。しかし、Cloud Runに直接IAPを設定できるようになったことで、アーキテクチャは劇的にシンプルになりました。 この新しい方法のメリットは明らかです。

• 構成がシンプル: ロードバランサーが不要で、管理が容易。
• コスト削減: ロードバランサー分の費用がかからない。
• 迅速なデプロイ: 簡単な設定ですぐにセキュアな環境を構築できる。

社内ツールのような小規模なアプリケーションを手軽に、かつセキュアに公開したい、というニーズにまさにぴったりの方法と言えるでしょう。

ただし、この構成には1つ重要な注意点があります。IAPを直接Cloud Runに設定する場合、現状では組織に所属するGoogleアカウントからのアクセスに限定され、組織外のID（個人のGmailアカウントなど）はアクセスできません。 このため、社内ツールやパートナー企業向けポータルなど、アクセスするユーザーが明確に定まっている場合に最適なソリューションです。

Cloud RunにIAPを設定してみよう

それでは、実際に手を動かしてCloud RunサービスにIAPを設定していきましょう。

1: 事前準備

まず、作業を始める前にいくつか準備が必要です。Google Cloudプロジェクトが作成済みで、課金が有効になっていることを確認してください。また、コマンドラインからGoogle Cloudを操作するためのgcloud CLIもインストールし、ご自身のプロジェクトにログインしておきましょう。

そして、今回の作業で必要になるAPIを有効化します。Cloud Shellやターミナルで以下のコマンドを実行してください。

gcloud services enable iap.googleapis.com run.googleapis.com cloudresourcemanager.googleapis.com

このコマンドで、IAPとCloud RunのAPIが使えるようになります。（+IAMポリシーの管理）

2: サンプルのCloud Runサービスをデプロイする

まず、Cloud Runサービスに直接IAPで保護する対象のCloud Runサービスをデプロイします。

gcloud beta run deploy SERVICE_NAME \
  --source=. \
  --region=REGION \
  --no-allow-unauthenticated

デプロイが完了すると、Service URL:としてURLが表示されます。

今回は--no-allow-unauthenticatedフラグを使用しているので、非公開のCloud Runサービスとしてデプロイされています。

実際にブラウザで確認するとError: Forbiddenと表示され、アクセスができません。

3: IAPを有効にしてCloud Runサービスを保護する

先ほどデプロイしたCloud Runサービスを更新し、IAPを有効にします。

gcloud beta run services update SERVICE_NAME \
  --region=REGION \
  --iap

コマンドが成功したら、再度Cloud RunサービスのURLにアクセスしてみてください。 今度は先ほどの画面ではなく、Googleアカウントのログインを求める画面が表示されるはずです。

4: アクセス権限を付与する

IAPを有効にしただけでは、まだ誰もこのサービスにアクセスできません。

最後に、自分自身（またはアクセスを許可したいユーザー）に「IAPを通過できる権限」を付与します。この権限は、IAMの「IAP-secured Web App User」というロール（日本語では「IAPで保護されたウェブアプリ ユーザー」）で管理します。

gcloud beta iap web add-iam-policy-binding \
  --member=user:YOUR_EMAIL_ADDRESS \
  --role=roles/iap.httpsResourceAccessor \
  --region=REGION \
  --resource-type=cloud-run \
  --service=SERVICE_NAME

設定が反映されるまで少し待ってから、もう一度サービスのURLにアクセスしてみましょう。 今度はGoogleアカウントで認証された後、ページが表示されたのではないでしょうか。

これで、ロードバランサーを使わずにCloud RunサービスをIAPで保護する設定は完了です。

これだけの手順で簡単に設定できてしまいましたね。

他のサービスとの連携や使い分け

Cloud Runへのアクセス制御には、IAP以外にもいくつかの選択肢があります。

• IAP + ロードバランサー（従来の方法）: Cloud CDNでの高速化や、Cloud Armor (WAF) による高度なセキュリティ対策が必要な場合は、ロードバランサーを併用する構成を選択します。
• Firebase Authentication: Googleアカウント以外に、メール/パスワード認証や各種ソーシャルログインに対応したい、不特定多数の一般ユーザー向けサービスの場合は、Firebase Authenticationが適しています。
• API Gateway: 公開する対象が、他のプログラムから利用されるバックエンドAPIの場合は、流量制御やAPIキー認証などの機能を持つAPI Gatewayの利用を検討すると良いでしょう。

トラブルシューティング

「You don’t have access」と表示されたら？

これは、Googleアカウントでの「認証」は通ったものの、「認可」が拒否されたことを示しています。ログインしたユーザーに「IAP-secured Web App User」ロールが付与されているか、IAM設定を再確認してください。 もしくは、組織のIDではなく、個人のメールアドレスでアクセスしている場合にもこのように表示されます。

まとめ

今回は、Cloud RunサービスにIAPを直接設定して、ロードバランサーを使わずにアクセス制御を実現する方法を解説しました。

gcloudコマンドをいくつか実行するだけで、驚くほど簡単に認証付きのアプリケーションを公開できることがお分かりいただけたでしょう。これにより、構成のシンプル化とコスト削減という大きなメリットが得られます。

この方法は、従来のVPNとは異なる「ゼロトラスト」という現代的なセキュリティアプローチを手軽に実現する、非常に強力な武器になります。社内向けのツール開発や、関係者限定のステージング環境構築など、様々な場面で活用できるはずです。

私自身も、この機能を学びながら「こんなに簡単にゼロトラストセキュリティの一歩を踏み出せるのか」と感動しました。この記事が、皆さんのGoogle Cloud活用のきっかけになれば幸いです。