認可ポリシーの正規化

このページでは、認可ポリシーでサポートされているすべての正規化について説明します。正規化されたリクエストは、認可ポリシーの評価と、最終的にバックエンドサーバーに送信されるリクエストの両方に使用されます。

詳細については、認可正規化のベストプラクティスを参照してください。

パス関連

これは、pathsフィールドとnotPathsフィールドに適用されます。

1. 単一のパーセントエンコード文字（%HH）

Istioは、単一のパーセントエンコードされた文字を次のように正規化します（正規化は1回のみ実行され、二重デコードは行われません）。

例えば、パスが/some%2fdata/%61%62%63のリクエストは/some/data/abcに正規化されます。

2. バックスラッシュ（\）

Istioはバックスラッシュ\をフォワードスラッシュ/に正規化します。例えば、パスが/some\dataのリクエストは/some/dataに正規化されます。

これは、正規化オプションBASEでデフォルトで有効になっています。

3. 複数のスラッシュ（//、///など）

Istioは複数のフォワードスラッシュを単一のフォワードスラッシュ（/）にマージします。例えば、パスが/some//data///abcのリクエストは/some/data/abcに正規化されます。

これはデフォルトでは無効になっていますが、正規化オプションMERGE_SLASHESで有効にできます。有効にした場合、パスはパステンプレート演算子{**}を含むパスと一致しない可能性があります。例えば、MERGE_SLASHESを有効にすると、/some/data//abcは/some/data/{**}/abcと一致しなくなります。なぜなら、パスは/some/data/abcに正規化されるからです。

4. 単一のドットと二重ドット（/./、/../）

Istioは、RFC 3986に従って、単一ドット/./と二重ドット/../を解決します。単一ドットは現在のディレクトリとして解決され、二重ドットは親ディレクトリとして解決されます。

例えば、/public/./data/abc/../xyzは/public/data/xyzに正規化されます。

これは、正規化オプションBASEでデフォルトで有効になっています。

5. クエリ付きパス（/foo?v=1）

Istioの認可ポリシーは、パスとの比較時にクエスチョンマーク（?）以降のすべてを削除します。バックエンドアプリケーションは依然としてクエリを参照することに注意してください。

これはデフォルトで有効になっています。

メソッド関連

これは、methodsフィールドとnotMethodsフィールドに適用されます。

1. メソッドが大文字でない

HTTPリクエスト内の動詞が大文字でない場合、IstioはHTTP 400でリクエストを拒否します。

これはデフォルトで有効になっています。

ヘッダー名関連

これは、request.headers[<header-name>]条件で指定されたヘッダー名に適用されます。

1. 大文字と小文字を区別しないマッチング

Istioの認可ポリシーは、ヘッダー名を大文字と小文字を区別しない方法で比較します。

これはデフォルトで有効になっています。

2. 重複ヘッダー

Istioは、重複するヘッダーをカンマを区切り文字としてすべての値を連結することにより、単一のヘッダーにマージします。

認可ポリシーは、マージされたヘッダーに対して単純な文字列マッチを行います。例えば、ヘッダーx-header: fooとx-header: barを持つリクエストは、x-header: foo,barにマージされます。

これはデフォルトで有効になっています。

3. ヘッダー名の空白

ヘッダー名に空白が含まれている場合、IstioはHTTP 400でリクエストを拒否します。

これはデフォルトで有効になっています。