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

この記事では、Identity-Aware Proxy（IAP）に関するよくある質問を紹介します。

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

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

App Engine スタンダード環境と App Engine フレキシブル環境のアプリ。
HTTP(S) 負荷分散バックエンドサービスを使用する Compute Engine インスタンス。
Google Kubernetes Engine コンテナ。

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

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

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

リクエストが失敗して 405 Method Not Allowed ステータスコードが返されました。なぜですか？

これは、リクエストに Cookie が添付されていないと発生する可能性があります。デフォルトで、JavaScript メソッドはリクエストに Cookie を添付しません。

Cookie を含める方法は、リクエストメソッドによって異なります。たとえば、XMLHttpRequest オブジェクトを使用して送信されるリクエストでは、withCredentials プロパティが true に設定されている必要があります。Fetch API を使用して送信されるリクエストでは、credentials オプションが include または same-origin に設定されている必要があります。

少し時間が経過してからエラーを処理する方法については、IAP セッションの管理をご覧ください。

HTTP 302 Redirect ではなく、HTTP 401 Unauthorized ステータスコードを受け取りました。なぜですか？

クライアントがリダイレクトを処理するように構成されている場合、IAP は 302 Redirect ステータスコードを返します。クライアントがリダイレクトを処理できることを示すには、HTTP Accept="text/html,*/*" をリクエストのヘッダーに含める必要があります。

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

IAP への呼び出しを POST リクエストで行うと、リダイレクトがトリガーされません。ブラウザは、POST リクエストに対するレスポンスとしてリダイレクトを行いません。このため、IAP は 302 Redirect ではなく、401 Unauthorized ステータスコードを返します。

IAP で POST リクエストを処理する必要がある場合は、ID トークンか有効な Cookie のいずれかをリクエストのヘッダーに渡す必要があります。

Authorization: Bearer ヘッダーに ID トークンを含めて、IAP で保護されたリソースに認証済みリクエストを送信します。セッションを更新して有効な Cookie を取得してください。

IAP は、次のような Cookie 接頭辞を想定しています。

GCP_IAAP_AUTH_TOKEN_<random_string>
GCP_IAP_UID

通常、このような Cookie は 1 つのリクエストヘッダー内に複数存在しています。

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

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

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

オーナー（roles/owner）役割は、できる限り使用しないでください。オーナー役割は、Google Cloud 全体にわたる権限を付与します。より限定した役割や権限を割り当てることで、プロジェクトのセキュリティを強化できます。詳細については、IAM のベストプラクティスをご覧ください。

オーナー役割の使用を減らすことができない場合は、ファイアウォールルールを使用すると、TCP での IAP をブロックできます。

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

IAP TCP は、ドメイン tunnel.cloudproxy.app を介してデータをトンネリングします。このドメインは Google が所有しています。このドメインへのトラフィックをブロックしていないことを確認してください。

このドメインへのトラフィックをブロックすると、IAP for TCP を使用できなくなります。いくつかのエラーメッセージのうちの 1 つを受け取る場合があります。

gcloud を使用している場合、エラーメッセージは

Error while connecting [[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed

ブラウザからの SSH 接続を使用している場合、エラーメッセージは

Cloud Identity-Aware Proxy Failed

関連するエラーコードはありません。

エラーコード

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

エラーコードまたはメッセージ	説明	トラブルシューティング
エラーコード 7	OAuth クライアント ID またはシークレット値が空です。	認証情報ページで、クライアント ID とシークレットがアプリに正しく構成されていることを確認してください。クライアント ID とシークレットが正しく構成されている場合は、`GET` メソッドで現在の状態を確認し、`PATCH` メソッドでクライアント ID とシークレットをリセットします。 • Compute Engine API: `GET`、`PATCH` • App Engine API: `GET`、`PATCH`
エラーコード 9	OAuth リダイレクトを完了できませんでした。	これは内部エラーで、確認のためにログに記録されました。
エラーコード 11	OAuth クライアント ID が正しく構成されていません。	認証情報ページで、クライアント ID とシークレットがアプリに正しく構成されていることを確認してください。クライアント ID とシークレットが正しく構成されている場合は、`GET` メソッドで現在の状態を確認し、`PATCH` メソッドでクライアント ID とシークレットをリセットします。 • Compute Engine API: `GET`、`PATCH` • App Engine API: `GET`、`PATCH`
エラーコード 13	OpenID Connect（OIDC）トークンが無効です。	認証情報ページで、IAP 用に構成されたクライアント ID が削除されていないことを確認します。
エラーコード 429	プロジェクトで、1 分あたりのリクエスト数のしきい値を超えました。	IAP プロジェクトでは、1 分あたりのリクエスト数は最大 360,000 件に制限されています。このエラーが発生した場合は、プロジェクトのリクエスト数を減らしてください。ご不明な点がございましたら、Google Cloud サポートまでお問い合わせください。
エラーコード 4003	インスタンスが、接続を試みているポートでリッスンしていないか、ファイアウォールが終了している可能性があります。どちらの問題も、VM インスタンスへの起動接続テストが失敗する原因になる可能性があります。	VM のリスニングプロセスが実行中で、正しいポートでリッスンしていることを確認します。また、Google Cloud ファイアウォールが正しく構成され、接続先のポートで開いていることを確認します。
エラーコード 4033	インスタンスに対するアクセス権限がないか、インスタンスが存在しません。あるいは、インスタンスが停止しています。	Identity-Aware Proxy ページで、IAP で保護されたトンネルユーザーの IAM 役割が接続先のリソースに適用されていることを確認します。

問題の解決方法がわからない場合は、カスタマーサポートに連絡して、どのようなエラーが発生しているのか詳しく説明してください。また、API への GET 呼び出しで返されたレスポンスも伝えてください。レスポンスからクライアントシークレットを削除できます。