このページでは、Identity-Aware Proxy(IAP)を使用して Cloud Run サービスを保護する方法について説明します。
既知の制限事項
Cloud Run サービスで
allUsers
に呼び出し元のロールを付与するように IAM を構成する必要があります。ただし、ネットワーク レベルではアクセスをロックダウンできるため、すべての外部リクエストは IAP 経由で承認される必要があります。詳細については、アクセスを制限するように Cloud Run を構成するをご覧ください。この制限は解決されているため、プロジェクト固有の IAP アクセス権を Cloud Run サービスに明示的に付与できます。HTTP/2 が有効になっている Cloud Run サービスが、IAP で保護されている場合、リクエスト時に無限リダイレクト ループが発生します。この動作は想定されておらず、将来的には対処される予定です。現時点では、サービスが IAP の背後にある場合は、HTTP/2 構成(デフォルト設定)を無効にすることをおすすめします。
Envoy ベースのロードバランサ モード(
Global external HTTP(S) load balancer
)で処理される Cloud Run サービスには、X-Goog-IAP-JWT-Assertion
IAP ヘッダーがありません。この動作を回避するには、Global external HTTP(S) load balancer (classic)
モードを使用することをおすすめします。内部ロードバランサを含む Cloud Run には、BeyondCorp Enterprise サブスクリプションが必要です。
始める前に
Cloud Run で IAP を有効にするには、次のものが必要です。
- 課金が有効になっている Google Cloud コンソール プロジェクト。
- ロードバランサで処理される 1 つ以上の Cloud Run サービスのグループ。
- 外部 HTTPS ロードバランサの設定についての詳細の確認。
- ロードバランサのアドレスに登録されたドメイン名。
- すべてのリクエストに ID があることを確認するアプリケーション コード。
- ユーザーの ID の取得をご覧ください。
IAP の有効化
Console
プロジェクトの OAuth 同意画面を構成していない場合は、画面を構成する必要があります。この画面では、メールアドレスとプロダクト名が必要です。
- OAuth 同意画面に移動します。
- [サポートメール] で、一般公開される連絡先として表示するメールアドレスを選択します。このメールアドレスは、自分のメールアドレスまたは自身が所有する Google グループにする必要があります。
- [アプリケーション名] に、アプリケーションの表示名を入力します。
- オプションの詳細を追加します。
- [保存] をクリックします。
プロダクト名やメールアドレスなど、OAuth 同意画面の情報を後で変更する場合は、上記の手順を繰り返して同意画面を構成します。
IAP アクセス権の設定
- [Identity-Aware Proxy] ページに移動します。
- IAP で保護するプロジェクトを選択します。
- [アプリケーション] で、メンバーを追加するロードバランサ バックエンド サービスの横にあるチェックボックスをオンにします。
- 右側のパネルで [メンバーを追加] をクリックします。
[メンバーの追加] ダイアログで、プロジェクトに対する IAP で保護されたウェブアプリ ユーザーの役割を持つグループ、または個人のアカウントを入力します。メンバーにすることができるアカウントの種類は以下のとおりです。
- Google アカウント: user@gmail.com - これは、user@google.com やその他のワークスペース ドメインなどの Google Workspace のアカウントでもかまいません。
- Google グループ: admins@googlegroups.com
- サービス アカウント: server@example.gserviceaccount.com
- Google Workspace ドメイン: example.com
[役割] のプルダウン リストから [Cloud IAP] > [IAP で保護されたウェブアプリ ユーザー] を選択します。
[保存] をクリックします。
IAP の有効化
- IAP ページの [アプリケーション] で、アクセスを制限するロードバランサのバックエンド サービスを見つけます。リソースの IAP を有効にするには、[IAP] 切り替えボタンをクリックします。IAP を有効にするには:
- ロードバランサのフロントエンドの構成内では、少なくとも 1 つのプロトコルは HTTPS でなければなりません。ロードバランサの設定をご覧ください。
compute.backendServices.update
、clientauthconfig.clients.create
、clientauthconfig.clients.getWithSecret
権限が必要です。上記の権限は、プロジェクト編集者などの役割によって付与されます。詳細については、IAP で保護されたリソースへのアクセスを管理するをご覧ください。
- 表示された [IAP の有効化] ウィンドウで [有効にする] をクリックし、IAP でリソースを保護することを確認します。IAP が有効になった後は、ロードバランサへのすべての接続でログイン認証情報が必要になります。プロジェクトで IAP で保護されたウェブアプリ ユーザーの役割を持つアカウントにのみアクセスが許可されます。
IAM ページで、次の構成を使用して新しい権限を追加します。
- プリンシパル:
service-[PROJECT-NUMBER]@gcp-sa-iap.iam.gserviceaccount.com
- ロール: Cloud Run 起動元
条件を追加して、このロールを必要な Cloud Run サービスに制限できます。
- プリンシパル:
gcloud
- プログラムによって IAP の OAuth クライアントを作成するの手順に沿って、OAuth 同意画面を構成し、OAuth クライアントを作成します。
- OAuth クライアント ID とシークレットを保存します。
- まだ作成していない場合は、次のコマンドを実行してサービス アカウントを作成します。以前にサービス アカウントを作成している場合、コマンドを実行しても重複するサービス アカウントは作成されません。
gcloud beta services identity create --service=iap.googleapis.com --project=[PROJECT_ID]
- 次のコマンドを実行して、前の手順で作成したサービス アカウントに呼び出し元の権限を付与します。
gcloud run services add-iam-policy-binding [SERVICE-NAME] \ --member=`serviceAccount:service-[PROJECT-NUMBER]@gcp-sa-iap.iam.gserviceaccount.com` \ --role=`roles/run.invoker`
ロードバランサのバックエンド サービスがグローバルかリージョンかに応じて、グローバル スコープまたはリージョン スコープのコマンドを実行して IAP を有効にします。前のステップで作成した OAuth クライアント ID とシークレットを使用します。
グローバル スコープ:
gcloud compute backend-services update BACKEND_SERVICE_NAME --global --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET
リージョン スコープ:
gcloud compute backend-services update BACKEND_SERVICE_NAME --region REGION_NAME --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET
次のように置き換えます。- BACKEND_SERVICE_NAME: バックエンド サービスの名前。
- CLIENT_ID: 前のステップで取得した OAuth クライアント ID。
- CLIENT_SECRET: 前のステップで取得した OAuth クライアント シークレット。
- REGION_NAME: IAP を有効にするリージョン。
IAP を有効にすると、Google Cloud CLI で Identity and Access Management のロール roles/iap.httpsResourceAccessor
を使用して IAP アクセス ポリシーを操作できます。詳細については、ロールと権限の管理をご覧ください。
アクセスを制限するように Cloud Run を構成する
Cloud Run サービスへのアクセスを構成するには、次の手順を行います。
Cloud Run サービスを構成し、上り(内向き)を内部および Cloud Load Balancing に設定します。詳細については、Cloud Run の上り(内向き)の制限をご覧ください。
このステップにより、内部クライアントと外部ロードバランサのみが Cloud Run サービスを呼び出すことが可能となり、公共のインターネットからの直接のリクエストがブロックされるようになります。
Cloud Run サービスに対して、
allUsers
に起動元ロールを付与します。詳しくは、公開(未認証)アクセスを許可するをご覧ください。この手順は、IAP の構成が正しく動作していることを確認するうえで重要です。これは、Cloud Run がそれ自体でリクエストの認証と承認を試行しないためです。代わりに、IAP が認証と承認を行います。
この構成により、内部とみなされるすべてのクライアント(Cloud Run の Ingress を制限するを参照)が認証なしで Cloud Run サービスにアクセスできるようになります。外部ロードバランサ経由で受信する他のすべてのクライアントは、IAP を介して認証します。これは既知の制約であり、将来的には対応される予定です。