この記事では、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
呼び出しで返されたレスポンスも伝えてください。レスポンスからクライアント シークレットを削除できます。