よくある質問とトラブルシューティング

このドキュメントでは、Identity-Aware Proxy（IAP）に関するよくある質問について説明します。

IAP でどのようなアプリを保護できますか？

IAP は、次のものに使用できます。

  • App Engine スタンダード環境と App Engine フレキシブル環境のアプリ
  • HTTP(S) ロード バランシング バックエンド サービスを使用する Compute Engine インスタンス
  • Google Kubernetes Engine コンテナ
  • HTTP(S) ロード バランシング バックエンド サービスを使用する Cloud Run アプリ

Cloud CDN では IAP を使用できません。

アプリにログインすると、URL の末尾に # があります。なぜですか？

一部のブラウザや特定の条件下では、認証後の URL に # が追加されていることがあります。これは正常であり、ログイン時に問題は発生しません。

リクエストが失敗して 405 Method Not Allowed が返されたのはなぜですか？

通常、これはリクエストに Cookie が添付されていない場合に発生します。JavaScript メソッドはデフォルトで Cookie を添付しません。

リクエスト方法によって必要なアプローチは異なります。

  • XMLHttpRequest の場合、withCredentials を true に設定します。
  • Fetch API の場合は、credentials を include または same-origin に設定します。

セッション関連のエラーの処理については、IAP セッションの管理をご覧ください。

302 Redirect ではなく HTTP 401 Unauthorized が表示されるのはなぜですか？

IAP は、クライアントがリダイレクトを処理するように構成されている場合にのみ 302 Redirect を送信します。

リダイレクトのサポートを示すために、リクエスト ヘッダーに HTTP Accept="text/html,*/*" を追加します。

POST リクエストがリダイレクトをトリガーしません。なぜですか？

ブラウザは、POST リクエストに対するレスポンスとしてリダイレクトを行いません。代わりに、IAP は 401 Unauthorized ステータス コードを返します。

IAP で保護されたリソースへの POST リクエストの場合は、次のいずれかを含めます。

API を無効にしている場合、IAP を使用できますか？

はい。IAP で保護されたリソースには、API が無効になってもアクセスできますが、IAM 権限を変更することはできません。

オーナー役割を持つユーザーが TCP に IAP を使用しないようにするには、どうしたらよいですか？

理想的には、よりきめ細かい権限に優先して、オーナー（roles/owner）ロールの使用を制限します。ガイダンスについては、IAM のベスト プラクティスをご覧ください。

できない場合は、ファイアウォール ルールを使用して IAP for TCP をブロックできます。

IAP for TCP で使用されるのは、どのドメインですか？

IAP は、次の Google 所有ドメインを使用します。

Server Error が表示されるのはなぜですか？

次のような場合は、

The server encountered a temporary error and could not complete your request. Please try again in 30 seconds.

ファイアウォールがロードバランサの IP をブロックしている可能性があります。

ファイアウォールが 130.211.0.0/22 と 35.191.0.0/16 からのトラフィックを許可していることを確認します。これらの IP がバックエンドに到達できない場合、アプリケーションにアクセスできなくなります。

特定の VM への IAP TCP 接続の場合は、VM が 35.235.240.0/20 範囲からの接続を受け入れるようにして、

内部サーバーエラーが断続的に表示されるのはなぜですか？

An internal server error occurred while authorizing your request. Error code X などのメッセージは、バックエンドの障害を示します。

エラーコード 1、30、62、63、64、703 は通常、一時的な問題を表します。再試行の指数バックオフを実装する。

割り当て超過エラー（エラーコード 429）に対処するにはどうすればよいですか？

エラーコード 429 は、アプリケーションが IAP のリクエスト上限を超えた場合に発生します。このサービスは、個別の割り当てを適用します。

  • ブラウザベースのリクエスト: 1 プロジェクトあたり 1 分あたり 360,000 件
  • プログラムによるリクエスト: 1 プロジェクトあたり 1 分あたり 360,000 件

プログラマティック リクエストは、AUTHORIZATION または PROXY-AUTHORIZATION ヘッダーが含まれ、IAP クッキーが含まれていないリクエストです。その他のすべてのリクエスト（認証情報のないリクエストを含む）は、ブラウザ リクエストと見なされます。

これらの上限は、プロジェクト内のすべての IAP で保護されたリソースに適用されます。

割り当て関連のエラーが発生した場合は、次の解決方法を検討してください。

  • 本番環境での負荷テストは避ける - IAP をバイパスする代替のネットワーク パスを使用する
  • サービス間トラフィックの場合は、指数バックオフを実装して 429 エラーを適切に処理する
  • トラフィックの多いアプリケーションを複数のプロジェクトに分散する
  • API ベースのアプリケーションには Apigee または同様の API ゲートウェイ ソリューションを使用する
  • 有機的な成長が原因で問題が発生している場合は、Google Cloud サポートに割り当ての増加についてお問い合わせください。

エラーコード

次の表に、IAP の構成時または使用時に返される一般的なエラーコードとメッセージを示します。

エラーコード 説明 トラブルシューティング
7 OAuth クライアント ID またはシークレットが空である 認証情報ページにアクセスして、クライアント ID とシークレットを確認します。設定が正しいように見えても機能しない場合は、API メソッドを使用して設定（Compute Engine の場合は GET、App Engine の場合は GET）を確認し、PATCH で設定をリセットします。
9 OAuth リダイレクト失敗 これは自動的にログに記録される内部エラーです。お客様側での手続きは必要ありません。
9（パスの書き換えルールあり） OAuth リダイレクト失敗 ロードバランサのパスの書き換えルールが OAuth の完了を妨げています。ロードバランサの背後にあるすべてのバックエンドで同じ OAuth クライアント ID を使用していることを確認します。これは、gcloud compute backend-services update コマンドを使用して更新できます。
9（パス ルーティング ルールあり） OAuth リダイレクト失敗 各パスの両方のバージョン（末尾のスラッシュありとなし）のパスルール バリエーションを作成し、同じバックエンドに転送します。たとえば、/path/ と /path の両方のルールを含めます。
11 OAuth クライアント ID が正しく構成されていない 認証情報ページでクライアント ID とシークレットを確認します。設定が正しいように見えても機能しない場合は、API メソッドを使用して設定を確認します（Compute Engine の場合は GET、App Engine の場合は GET）。設定が正しい場合は、PATCH を使用して設定をリセットします。
13 無効な OIDC トークン 認証情報ページに移動して、クライアント ID が削除されていないか、誤って変更されていないことを確認します。
51 ブラウザで接続プーリングがサポートされていない ブラウザを最新バージョンに更新するよう、エンドユーザーに依頼します。接続要件の詳細については、リソースへのアクセスを制限するをご覧ください。
52 ホスト名/SSL 証明書の不一致 システム管理者は、SSL 証明書をホスト名と一致するように更新する必要があります。ガイダンスについては、リソースへのアクセスを制限するをご覧ください。
52（プライマリ証明書マップエントリあり） ホスト名/SSL 証明書の不一致 IAP はプライマリ証明書マップのエントリをサポートしていません。個別のエントリを使用して、各証明書を正しいホスト名にマッピングします。ガイダンスについては、証明書マップエントリを作成するをご覧ください。
53 ホスト名が許可されたドメインにない 管理者が、許可されたドメインのリストにホスト名を追加する必要があります。手順については、リソースへのアクセスを制限するをご覧ください。
429 リクエストの割り当てを超過しました リクエスト数の上限（各リクエスト タイプで 1 分あたり 360,000 件）に達しました。ワークロードを複数のプロジェクトに分散するか、クライアントサイド リクエストの調整を実装するか、正当な増加のために必要に応じてサポートに割り当ての増加をリクエストすることを検討してください。
551 IAP が複数の場所で有効になっている 転送ルールとバックエンド サービスの両方で IAP を有効にすることはできません。Compute Engine で有効にするのガイダンスに沿って、1 つのロケーションで無効にします。
700、701 Workforce プール プロバイダに関する問題 Workforce プールには 1 つのプロバイダのみを構成します。詳細な要件については、Workforce プールの制限事項をご覧ください。
705 Workforce Identity の OAuth クライアント ID がない 設定プロセスをすべて完了します。まず OAuth クライアント ID を作成し、次に IAP 設定を更新します。
708 Workforce プール名が無効です ワークフォース プールが存在し、正しい形式（locations/global/workforcePools/WORKFORCE_POOL_ID）を使用していることを確認します。
4003 接続またはファイアウォールに関する問題 VM プロセスが実行中で、想定されるポートでリッスンしていることを確認します。また、ファイアウォール ルールでそのポートでの接続が許可されていることを確認します。
4010 宛先によって接続が切断されました VM をリセットします。問題が解決しない場合は、auth.log（通常は /var/log/ 内）を調べるか、シリアル コンソールを使用して詳細な診断を行います。
4033 権限、存在、VM の状態に関する問題 IAP ページで、リソースにトンネル ユーザーのロールが割り当てられていることを確認します。また、VM が存在し、実行されていることを確認します。
4047 インスタンスが存在しないか、停止している VM の電源がオンで、起動シーケンスが完全に完了していることを確認します。

問題を解決できない場合や、このページにエラーが表示されない場合は、エラーの説明と、API への GET 呼び出しで返されたレスポンスとともに Cloud カスタマーケアにお問い合わせください。レスポンスからクライアント シークレットを削除してください。