イングレスゲートウェイのカスタム権限付与サービスの設定 - Alibaba Cloud Service Mesh

HTTPリクエストのドメイン名、パス、メソッドに基づいてリクエストを認証するなど、ニーズに合わせてアクセス制御ポリシーをカスタマイズする必要がある場合は、イングレスゲートウェイを使用してカスタム認証を実装し、認証されたユーザーのみが主要サービスにアクセスできるようにすることができます。

前提条件

機能の説明

ユーザーがサービスリクエストを開始すると、バックエンドはユーザーリクエストの有効性を検証する必要があります。たとえば、バックエンドは、ユーザーがリクエストされたリソースにアクセスする権限を持っているかどうかを確認します。ユーザーが認証に合格した場合、返されるメッセージには追加情報が含まれています。たとえば、サービスのバージョン番号とユーザー ID がレスポンスヘッダーに追加されます。サービスメッシュ（ASM）では、カスタム認証サービスを定義できます。イングレスゲートウェイに認証プロセスを追加して、承認されたユーザーのみが主要サービスにアクセスできるようにすることができます。

ビジネスニーズに基づいて認証サービスをカスタマイズできます。この例では、イングレスゲートウェイにルーティングされるリクエストを認証するために、イングレスゲートウェイ用にカスタム認証サービスがデプロイされています。リクエストは、認証結果に基づいて許可または拒否されます。次の構成を指定する必要があります。

イングレスゲートウェイがカスタム認証サービスに接続するために必要な情報
カスタム認証サービスを使用して認証する必要があるリクエスト

カスタム認証は、Service Mesh の高度なセキュリティ機能です。特別なセキュリティ要件がある場合は、この機能を使用できます。セキュリティ要件が一般的な場合は、イングレスゲートウェイのブラックリストまたはホワイトリストの設定、または「ゼロトラストセキュリティの概要」トピックの認証ポリシーセクションを参照して、認証ポリシーを設定できます。

カスタム認証の実装方法

ASM は Istio のカスタム認証機能をカプセル化しています。 Istio のカスタム認証機能の実装方法の詳細については、カスタム認証サービスの設定後に生成されるネイティブ Istio リソースを参照してください。次の例は、ASM でカスタム認証を実装する方法を示しています。

カスタム認証サービスを定義し、このサービスを ASM の目的のイングレスゲートウェイに関連付けます。これにより、ASM はカスタム認証サービスを使用して認証を実行できます。カスタム認証サービスの定義方法の詳細については、手順 1 を参照してください。
ASM で認証ポリシーを作成し、カスタム認証を必要とするアプリケーションを設定してから、手順 2 で設定したカスタム認証サービスを使用して認証を実行します。

基于ASM实现应用请求认证授权

手順 1：カスタム認証サービスをデプロイする

Container Service for Kubernetes（ACK）クラスターにカスタム認証サービスをデプロイします。このサービスは、カスタム認証サービスの Istio の API 仕様に準拠し、HTTP および gRPC プロトコルをサポートしている必要があります。このトピックで提供されているサンプル認証サービスでは、x-ext-authz: allow ヘッダーを持つリクエストのみが認証を通過できると指定しています。

説明

このトピックのサンプルコードに基づいて、カスタム認証サービスを作成できます。詳細については、extauthz を参照してください。

次の内容を含む ext-authz.yaml ファイルを作成します。

ext-authz.yaml ファイルを表示する

# Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");  // Apache License バージョン 2.0（「ライセンス」）に基づいてライセンスされています。
#   you may not use this file except in compliance with the License.  // ライセンスに準拠する場合を除き、このファイルを使用することはできません。
#   You may obtain a copy of the License at  // ライセンスのコピーは以下から取得できます。
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software  // 適用法で要求されている場合、または書面で合意されている場合を除き、ソフトウェア
#   distributed under the License is distributed on an "AS IS" BASIS,  // は「現状有姿」で配布され、
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  // 明示的または黙示的を問わず、いかなる種類の保証も条件も提供されません。
#   See the License for the specific language governing permissions and  // 権限と制限を規定する特定の言語については、ライセンスを参照してください。
#   limitations under the License.

# Example configurations for deploying ext-authz server separately in the mesh.  // メッシュに ext-authz サーバーを個別にデプロイするための設定例。

apiVersion: v1
kind: Service
metadata:
  name: ext-authz
  labels:
    app: ext-authz
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 8000
  - name: grpc
    port: 9000
    targetPort: 9000
  selector:
    app: ext-authz
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ext-authz
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ext-authz
  template:
    metadata:
      labels:
        app: ext-authz
    spec:
      containers:
      - image: istio/ext-authz:0.6
        imagePullPolicy: IfNotPresent
        name: ext-authz
        ports:
        - containerPort: 8000
        - containerPort: 9000
---

次のコマンドを実行して、目的の ACK クラスターに認証サービスをデプロイします。
kubectl を使用してクラスターとアプリケーションを管理する方法の詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」を参照してください。
```
kubectl apply -f ext-authz.yaml
```

次のコマンドを実行して、Pod のステータスをクエリします。

kubectl get pod

予期される出力：

NAME                              READY   STATUS    RESTARTS       AGE
ext-authz-6d458d5f8f-bh2m9        2/2     Running   0              1m

次のコマンドを実行して、ext-authz サービスが想定どおりに動作するかどうかを確認します。
```
kubectl logs "$(kubectl get pod -l app=ext-authz -n default -o jsonpath={.items..metadata.name})" -n default -c ext-authz
```
予期される出力：
```
2023/12/12 10:01:31 Starting HTTP server at [::]:8000
2023/12/12 10:01:31 Starting gRPC server at [::]:9000
```
上記の結果が返された場合、ext-authz サービスは正常に動作しています。目的のカスタム認証サービスが正常にデプロイされました。
ext-authz サービスの gRPC ポートと HTTP ポートを取得します。
1. ACK コンソールにログインします。左側のナビゲーションペインで、[クラスター] をクリックします。
2. [クラスター] ページで、管理するクラスターを見つけて名前をクリックします。左側のペインで、[ネットワーク] > [サービス] を選択します。
3. [サービス] ページで、[ext-authz] をクリックします。
  [エンドポイント] セクションで、gRPC プロトコルのポートが 9000、HTTP プロトコルのポートが 8000 であることがわかります。したがって、サービスにアクセスするために使用される gRPC アドレスは ext-authz.default.svc.cluster.local:9000 で、HTTP アドレスは ext-authz.default.svc.cluster.local:8000 です。

手順 2：目的のイングレスゲートウェイに HTTP プロトコルを使用するカスタム認証サービスを設定する

イングレスゲートウェイはカスタム認証機能を統合しています。ASM コンソールでカスタム認証サービスを設定できます。

ASM コンソールにログインします。左側のナビゲーションペインで、[サービスメッシュ] > [メッシュ管理] を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[ASM ゲートウェイ] > [イングレスゲートウェイ] を選択します。
[イングレスゲートウェイ] ページで、カスタム認証サービスを設定するイングレスゲートウェイをクリックします。
左側のナビゲーションペインで、[ゲートウェイセキュリティ] > [カスタム認証サービス] を選択します。
設定ウィザードの [カスタム認証サービスの設定] 手順で、[ゲートウェイカスタム認証サービスを有効にする] をオンにし、次のいずれかの方法を使用してカスタム認証サービスを設定し、[次へ] をクリックします。
方法 1：カスタム認証サービスを作成する
[envoy.ext_authz に基づいて実装されたカスタム認証サービス（HTTP または Grpc プロトコル）] タブで、パラメーターを設定します。パラメーターの詳細については、HTTP プロトコルを使用したカスタム認証の実装を参照してください。
方法 2：既存のカスタム認証サービスをインポートする
[既存のカスタム認証サービスをインポートする] タブで、既存のカスタム認証サービスを選択します。
設定ウィザードの [一致ルール] 手順で、パラメーターを設定し、[送信] をクリックします。
このルールに一致するリクエストは、認証サービスを使用して認証されます。
設定が完了すると、[ゲートウェイカスタム認証サービスが正常に作成されました] メッセージが表示されます。

手順 3：イングレスゲートウェイを使用してカスタム認証を実装できることを確認する

次のコマンドを実行して、イングレスゲートウェイの /api/v1/products パスにあるリソースにアクセスします。
イングレスゲートウェイの IP アドレスを取得する方法の詳細については、Istio リソースを使用してトラフィックをサービスの異なるバージョンにルーティングするの手順 3 のサブステップ 1 を参照してください。
```
curl -I http://{イングレスゲートウェイの IP アドレス}/api/v1/products
```
予期される出力：
```
HTTP/1.1 200 OK
server: istio-envoy
date: Wed, 13 Dec 2023 02:41:20 GMT
content-type: application/json
content-length: 395
x-envoy-upstream-service-time: 1
```
上記の結果は、カスタム認証がトリガーされていないことを示しています。その理由は、パスが前の手順で設定された /productpage ではなく、/api/v1/products であるためです。
次のコマンドを実行して、x-ext-authz: deny ヘッダーを持つリクエストを使用して /productpage パスのリソースにアクセスします。
```
curl -I -H "x-ext-authz: deny" http://{イングレスゲートウェイの IP アドレス}/productpage
```
予期される出力：
```
HTTP/1.1 403 Forbidden
x-ext-authz-check-result: denied
date: Wed, 13 Dec 2023 02:42:59 GMT
server: istio-envoy
transfer-encoding: chunked
```
上記の結果は、カスタム認証がトリガーされたが認証に失敗したことを示しています。返された結果には、新しく追加されたレスポンスヘッダー x-ext-authz-check-result: denied が含まれています。カスタム認証がトリガーされた理由は、パスが認証ポリシーで定義された /productpage であるためです。
次のコマンドを実行して、x-ext-authz: allow ヘッダーを持つリクエストを使用して /productpage パスのリソースにアクセスします。
```
curl -I -H "x-ext-authz: allow" http://{イングレスゲートウェイの IP アドレス}/productpage
```
予期される出力：
```
HTTP/1.1 200 OK
server: istio-envoy
date: Wed, 13 Dec 2023 02:50:38 GMT
content-type: text/html; charset=utf-8
content-length: 5290
x-envoy-upstream-service-time: 47
```
上記の結果は、カスタム認証がトリガーされ、認証が成功したことを示しています。返された結果には、新しく追加されたレスポンスヘッダー x-ext-authz-check-result: allowed が含まれています。認証が成功した後、イングレスゲートウェイによってアプリケーションに転送されたリクエストは、x-ext-authz-check-result: allowed ヘッダーを保持しており、期待どおりです。

参照

ASM では、イングレスゲートウェイのブラックリストまたはホワイトリストを設定して、特定の IP アドレス、HTTP リクエストのドメイン名、ポート、またはリモート IP アドレスに基づいてリクエストを拒否または許可できます。これにより、メッシュ内のアプリケーションのセキュリティが確保されます。詳細については、イングレスゲートウェイのブラックリストまたはホワイトリストの設定を参照してください。
Alibaba Cloud IDentity as a Service（IDaaS）または OpenID Connect（OIDC）プロトコルに準拠する他の ID プロバイダー（IdP）が提供する ID 情報を使用して、アプリケーションを変更することなく、複数の関連システムに単一の ID でログオンできます。詳細については、イングレスゲートウェイでの OIDC ベースの SSO の設定を参照してください。