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

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

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

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

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

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

アプリにログインすると、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 を使用できますか？

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

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

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

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

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 Cookie を含まないリクエストです。他のすべてのリクエスト（認証情報のないリクエストを含む）は、ブラウザ リクエストと見なされます。

これらの上限は、プロジェクト内の 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 リダイレクトに失敗しました 各パスの 2 つのバージョン（末尾のスラッシュありとなし）のパスルール バリアントを作成し、同じバックエンドに転送します。たとえば、/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 ホスト名が許可されたドメインに含まれていない 管理者がホスト名を許可されたドメインのリストに追加する必要があります。手順については、リソースへのアクセスを制限するをご覧ください。
253、HTTP 429 リクエストの割り当てを超過しました リクエストの上限（リクエスト タイプごとに 360,000 回/分）に達しました。ワークロードを複数のプロジェクトに分散すること、クライアントサイドのリクエスト スロットリングを実装すること、正当な成長に必要な場合は割り当ての増加についてサポートに問い合わせることを検討してください。
551 複数の場所で IAP が有効になっている 転送ルールとバックエンド サービスの両方で IAP を有効にすることはできません。Compute Engine で有効にするのガイダンスに沿って、1 つのロケーションで無効にします。
700、701 Workforce プール プロバイダの問題 Workforce プールにプロバイダを 1 つだけ構成します。詳細な要件については、Workforce プールの制限事項をご覧ください。
705 Workforce Identity の OAuth クライアント ID がありません 完全な設定プロセスに沿って、まず OAuth クライアント ID を作成し、次に IAP 設定を更新します。
708 Workforce プール名が無効です Workforce プールが存在し、正しい形式（locations/global/workforcePools/WORKFORCE_POOL_ID）を使用していることを確認します。
4003 接続またはファイアウォールの問題 VM プロセスが実行中で、想定されるポートでリッスンしていることを確認します。また、ファイアウォール ルールでそのポートでの接続が許可されていることも確認します。
4010 宛先によって接続が閉じられました VM をリセットします。問題が解決しない場合は、auth.log（通常は /var/log/ 内）を調べるか、シリアル コンソールを使用して詳細な診断を行います。
4033 権限、存在、VM の状態に関する問題 IAP ページで、リソースにトンネル ユーザーのロールが割り当てられていることを確認し、VM が存在し、実行されていることを確認します。
4047 インスタンスが存在しないか、停止している VM の電源がオンで、起動シーケンスが完全に完了していることを確認します。

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