Microservices Engine:カスタム認証と認可の設定

カスタム認証ルールの作成

1. MSE コンソールにログインします。

2. 左側のナビゲーションペインで、Cloud-Native Gateway > ゲートウェイリスト を選択します。上部メニューで、リージョンを選択します。

3. ゲートウェイリスト ページで、対象のゲートウェイの名前をクリックします。

4. 左側のナビゲーションペインで、Security Management > Global Authentication を選択します。

5. [Global Authentication] ページで [Create authentication] をクリックします。[Create authentication] パネルで、ゲートウェイ認証パラメーターを設定し、OK をクリックします。

   パラメーター	説明
   認証名	認証ルールのカスタム名を入力します。
   認証タイプ	[User-created authentication] を選択します。
   認証サービス	認証用のバックエンドサービスを選択します。サービス管理セクションでサービスを追加できます。詳細については、「サービスの追加」をご参照ください。 説明 HTTP プロトコルを使用するサービスのみがサポートされています。Dubbo などの他のプロトコルはサポートされていません。 デフォルトでは、ゲートウェイは Kubernetes サービスの最初のポートを使用します。別のポートを使用するには、Container Service for Kubernetes (ACK) で、目的のポートのみを公開する別の Kubernetes サービスを作成します。
   認証 API	認証サービスの API のパスを指定します。API パスはプレフィックス一致をサポートする必要があります。 たとえば、認証サービスが Spring MVC 上に構築され、認証 API が /check の場合は、/check/ とそのサブパスへのリクエストを処理するように設定します： @RequestMapping("/check/") public ResponseEntity<RestResult<String>> check(){}
   トークンロケーション	トークンを含むリクエストヘッダーを指定します。一般的なヘッダーには、Authorization と Cookie があります。[Dropdown list] からヘッダーを選択するか、[Manual Input] を使用してヘッダー名を指定できます。
   認証リクエストで許可されるヘッダー	認証サービスに渡すクライアントリクエストヘッダーの名前を指定します。 説明 Host、Method、Path、Content-Length ヘッダーはデフォルトで含まれているため、手動で追加する必要はありません。
   認証レスポンスで許可されるヘッダー	バックエンドサービスに送信される前に元のリクエストに追加する認証レスポンスヘッダーの名前を指定します。 説明 クライアントリクエストに同じ名前のヘッダーがすでに含まれている場合、その値は上書きされます。
   認証リクエストで本文を許可	このオプションを有効にすると、元のリクエストの本文が認証リクエストに含まれます。 [Maximum body bytes] は、認証リクエストで送信できるリクエスト本文の最大サイズ (バイト単位) を指定します。
   タイムアウト	認証サービスからのレスポンスを待つ最大時間 (秒単位) です。デフォルト値は 10 です。
   モード	障害処理モードを指定します。ルーズモードと ストリクトモードがサポートされています。ルーズモードの使用を推奨します。 ルーズモード： 認証サービスが利用できない場合 (接続に失敗した場合や 5xx エラーが返された場合) 、ゲートウェイはクライアントリクエストを許可します。 ストリクトモード： 認証サービスが利用できない場合、ゲートウェイはクライアントリクエストを拒否します。
   シンプルなルール	Grant の右側にある [simple rule] をクリックします。このモードは、ホワイトリストモードとブラックリストモードをサポートしています。 ホワイトリストモード： 指定されたホストとパスに一致するリクエストは認証をバイパスします。他のすべてのリクエストには認証が必要です。 ブラックリストモード： 指定されたホストとパスに一致するリクエストのみが認証を必要とします。他のすべてのリクエストは認証をバイパスします。 [+ Rule condition] をクリックして、リクエストドメイン名、パス、リクエストヘッダーを設定します。 ドメイン名： リクエストされたドメイン名 (ホスト) 。 パス： リクエストされた API パス。 パス一致条件： パスは、完全一致、プレフィックス一致、および正規表現一致をサポートしています。 完全一致： 完全なパス (例：/app/v1/order) を入力します。 プレフィックス一致： アスタリスク (*) で終わるパスプレフィックスを入力します。たとえば、/app で始まるすべてのリクエストを照合するには、値を /app/* に設定します。 正規表現一致： 正規表現は RE2 構文に従う必要があります。詳細については、「RE2 構文」をご参照ください。 大文字と小文字を区別： このオプションを選択すると、パスの一致で大文字と小文字が区別されます。 リクエストヘッダー： リクエストのヘッダー情報。ヘッダーは論理 AND で結合されます。[+ Request Header] をクリックして、複数のヘッダーを設定します。 ヘッダーキー： ヘッダーフィールドの名前。 条件： ヘッダーでサポートされている一致条件。 次と等しい： リクエストの指定されたヘッダーキーの値が入力値と等しい。 次と等しくない： 指定されたヘッダーキーの値が入力値と等しくない。 存在する： リクエストに指定されたヘッダーキーが含まれている。 存在しない： リクエストに指定されたヘッダーキーが含まれていない。 次を含む： 指定されたヘッダーキーの値に入力値が含まれている。 次を含まない： 指定されたヘッダーキーの値に入力値が含まれていない。 プレフィックス： 指定されたヘッダーキーの値が入力値で始まる。 サフィックス： 指定されたヘッダーキーの値が入力値で終わる。 正規表現： 指定されたヘッダーキーの値が入力された正規表現に一致する。正規表現は RE2 構文に従う必要があります。詳細については、「RE2 構文」をご参照ください。 値： ヘッダーフィールドの値。
   複雑なルール	Grant の右側にある [complex rule] をクリックします。 このモードでは、YAML の Envoy 権限データ構造を使用して、AND/OR/NOT ロジックを組み合わせた認可ルールを設定できます。認証は、これらの条件に一致するリクエストにのみ必要です。他のすべてのリクエストは認証をバイパスします。 説明 権限データ構造のフィールドの詳細については、Envoy の公式ドキュメントをご参照ください。 設定例については、「複雑なルールの例」をご参照ください。

   [Global Authentication] ページに戻ります。新しいゲートウェイ認証ルールがリストに表示された場合、ルールが作成されます。

認証ルールの表示と管理

1. MSE コンソールにログインします。

2. 左側のナビゲーションペインで、Cloud-Native Gateway > ゲートウェイリスト を選択します。上部メニューで、リージョンを選択します。

3. ゲートウェイリスト ページで、対象のゲートウェイの名前をクリックします。

4. 左側のナビゲーションペインで、Security Management > Global Authentication を選択します。

5. [Global Authentication] ページで、対象の認証ルールを見つけ、Actions 列の詳細 をクリックします。現在のサービスのBasic Information と [Authentication Configuration] を表示し、その[Authorization Information] を表示および管理できます。

   [Authentication configuration] セクションには、[authentication service]、[authentication API]、[token location]、[timeout]、[mode]、[allow body in authentication request]、[allowed headers in authentication request]、[allowed headers from authentication response] などのフィールドが表示されます。[Authorization information] セクションはホワイトリストモードです。ルール条件は論理 OR で結合され、ルール内の一致項目は論理 AND で結合されます。認可ルールテーブルには、[Request domain name]、[Request path match items]、[Case sensitive]、[Request header match items]、[Actions] の列が含まれます。

   [Authorization Information] セクションで、[Create authorization info] をクリックします。表示されるダイアログボックスで、[Request domain name] と [Request path] を入力し、[Match mode] を選択して、OK をクリックして認可ルールを追加します。

関連操作

また、次の操作を実行して、認証ルールと認可ルールを管理することもできます：

• ルールの有効化： Global Authentication ページで対象のルールを見つけ、Actions 列の [Enable] をクリックして有効化します。

• ルールの無効化： Global Authentication ページで対象のルールを見つけ、Actions 列の Close をクリックして無効化します。

• ルールの編集： Global Authentication ページで対象のルールを見つけ、Actions 列の Edit をクリックして設定を変更します。

• ルールの削除： Global Authentication ページで対象のルールを見つけ、Actions 列の Delete をクリックして削除します。

複雑なルールの例

permissions:
# and_rules は、以下のすべてのルールが満たされたときに認証が実行されることを指定します。
- and_rules:
    rules:
      - url_path:
          # パスのプレフィックス一致。
          path:
            prefix: /
      - header:
          # 正規表現一致。
          safe_regex_match:
            regex: "(exampleA\\.com|exampleB\\.com)"
          # HTTP 疑似ヘッダーがサポートされています。「:authority」ヘッダーを使用してドメイン名を取得できます。
          name: ":authority"

permissions:
# or_rules は、以下のいずれかのルールが満たされた場合に認証が実行されることを指定します。
- or_rules:
    rules:
      # and_rules は、以下のすべてのサブルールが満たされた場合にのみ、このルールが満たされることを指定します。
      # ルール 1
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/bbb/ccc
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      # ルール 2                
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/ccc/ddd
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      - and_rules:
          rules:
            # ルール 3
            - url_path:
                path:
                  prefix: /api/
            # not_rule は、以下の設定が満たされていない場合にのみ、このルールが満たされることを指定します。
            # ルール 4
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # ルール 5
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc                                
            - header:
                exact_match: "exampleA.com"
                name: ":authority"                                
      - and_rules:
          rules:
            # ルール 6
            - url_path:
                path:
                  prefix: /
            # not_rule は、以下の設定が満たされていない場合にのみ、このルールが満たされることを指定します。
            # ルール 7
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # ルール 8
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc
            # ルール 9
            - not_rule:
                url_path:
                  path:
                    prefix: /api/appc/                                         
            - header:
                exact_match: "exampleB.com"
                name: ":authority"