APIゲートウェイを介したプロキシ後にOCIサービスAPIコールが失敗する

問題の症状

次の症状が1つ以上表示される場合があります。

• クライアントはOCIサービスを直接コールできますが、APIゲートウェイを介したルーティング時に同じコールが失敗します。

• OCI APIキー署名または別のOCIリクエスト署名フローを使用するリクエストは、ゲートウェイを介してルーティングされた場合にのみ失敗します。

• プロキシされたリクエストは、ターゲットOCIサービスから認可または署名検証エラーを返します。

• 生成AIなどのOCIサービス・エンドポイント、または署名付きOCIリクエストを期待する別のOCI APIへのコールは、APIゲートウェイがリクエストをプロキシした後に失敗します。

考えられる理由

この問題は、次の理由で発生する可能性があります。

• クライアントは、最終的なOCIサービス・エンドポイントではなく、APIゲートウェイ・エンドポイントの元のリクエストに署名します。

• ターゲットOCIサービスが受信するHostヘッダーは、署名の作成に使用されたhost値とは異なります。

• 符号付き(request-target)値が、最終的なリクエスト・パスおよびメソッドと一致しません。

• 必要な署名ヘッダー(date、host、x-content-sha256など)は、最終的なアウトバウンド・リクエストと一致しません。

• APIゲートウェイはヘッダーを転送できますが、汎用プロキシされたOCIサービス・コールのOCIリクエスト署名は再計算されません。

署名要件のレビュー

ターゲットOCIサービスにOCIリクエスト署名が必要かどうかを確認します。次に、クライアント・リクエストとターゲットOCIサービスが受信するリクエストを比較します。

次のリクエスト詳細を確認します。

• クライアント・リクエストのAuthorizationヘッダーを調べます。

• AuthorizationヘッダーがSignatureで始まるかどうかを確認します。

• 署名付きヘッダー・リストに含まれるヘッダーを識別します。

• OCIサービスが受信する最終的なターゲットURI、HTTPメソッドおよびリクエスト本文に対して署名が作成されたかどうかを確認します。

リクエストが最終的なOCIサービス・エンドポイントではなくAPIゲートウェイのホスト名およびパスに対して署名されている場合、OCIサービスはリクエストを拒否します。

署名済ヘッダーのレビュー

OCIリクエスト署名で一般的に使用されるヘッダーの署名済リクエストを確認します:

• Authorization

• date

• host

• x-content-sha256

• content-type

• content-length

ターゲットOCIサービスがリクエスト署名を検証する場合、署名された値は最終的なアウトバウンド・リクエストと完全に一致する必要があります。

APIゲートウェイ・レスポンスを取得し、返されたopc-request-idを記録します。リクエストIDを使用して、失敗したプロキシ・コールとログおよびサービス側の診断を関連付けます。

OCIサービス・プロキシ・コールの修正

OCIサービスが受信するリクエストに署名する設計を使用します。署名付きOCIサービス・リクエストをプロキシ後に有効にするには、ヘッダー転送のみに依存しないでください。

統合パターンに一致する修正を使用します。

• ターゲットOCIサービスに署名付きリクエストが必要な場合は、APIゲートウェイ以外の最終アウトバウンド・リクエストに署名します。

• APIゲートウェイを統合の前に配置する必要がある場合は、ターゲット・サービスへの正しいOCI署名リクエストを生成するAPIゲートウェイの後ろにコンポーネントを配置します。このパターンでは、ファンクションは独自のOCI認証フローを使用してOCIサービスを呼び出すことができるため、ファンクション・バック・エンドは多くの場合、実行可能なアプローチです。

ヘッダー転送制限の理解

APIゲートウェイはヘッダーを転送できますが、転送されたヘッダーはOCIリクエスト署名の不一致を修復しません。

次の1つ以上の値が変更された場合、元のAuthorizationヘッダーを変更せずに渡すだけでは不十分です。

• 最後のhost値。

• 最終リクエスト・パス。

• 署名付きヘッダー・セット。

• ターゲットOCIサービスが検証するボディ・ハッシュ。

OCIサービス・プロキシ・コールの検証

統合設計を変更した後、プロキシされたリクエストが成功することを確認します。

次のチェックを使用します。

• 更新されたリクエスト・パスを介してリクエストを送信します。

• ターゲットOCIサービスがリクエストを受け入れることを確認します。

• リクエストが、APIゲートウェイ・エンドポイントではなく最終的なOCIサービス・エンドポイントに対して署名されていることを確認します。

• 戻されたopc-request-idが署名または認可の失敗に対応していないことを確認します。

詳細情報

詳細は、次を参照してください:

• リクエストの署名

• APIゲートウェイ・バック・エンドとしてのHTTPまたはHTTPS URLの追加

• APIゲートウェイ・バック・エンドとしてのOCI Functionsでのファンクションの追加

• APIデプロイメントへのロギングの追加