gRPC プロトコルを使用したカスタム認証の実装によるサービスセキュリティの向上 - Alibaba Cloud Service Mesh

カスタム認証機能を使用すると、gRPC プロトコルを使用するサービスに対してきめ細かいリソースアクセス管理 (RAM) を実行できます。この機能を使用すると、ビジネス要件に基づいて認証メカニズムをカスタマイズできます。サービスが相互に通信する場合、認証が必要です。これにより、認証および承認されたリクエストのみが特定のサービスリソースにアクセスできるようになり、サービス間の通信のセキュリティが向上します。このトピックでは、httpbin アプリケーションと sleep アプリケーションを次の例で使用して、gRPC プロトコルを使用したカスタム認証の実装方法について説明します。

前提条件

コンテナサービス Kubernetes 版 (ACK) クラスタが ASM インスタンスに追加されています。詳細については、「ASM インスタンスへのクラスタの追加」をご参照ください。

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

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

説明

次のサンプル認証サービスを使用するか、サンプル認証サービスのコードに基づいてカスタム認証サービスを作成できます。詳細については、GitHub の Web サイトをご覧ください。

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

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

# Istio 作者による著作権
#
#   Apache License, Version 2.0（以下「ライセンス」）に基づいてライセンスされています。
#   ライセンスに準拠する場合を除き、このファイルを使用することはできません。
#   ライセンスのコピーは以下から取得できます。
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   適用法または書面による合意がない限り、ソフトウェア
#   ライセンスに基づいて配布されるものは、「現状のまま」で配布されます。
#   明示または黙示を問わず、いかなる種類の保証または条件もありません。
#   ライセンスに基づく権限と制限を規定する特定の言語については、ライセンスを参照してください。

# メッシュ内に個別に 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
---

kubectl を使用してクラスターに接続し、次のコマンドを実行して、クラスターにカスタム承認サービスをデプロイします。
詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。
```
kubectl apply -f ext-authz.yaml
```
予想される出力:
```
service/ext-authz created
deployment.apps/ext-authz created
```
次のコマンドを実行して、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/20 08:15:39 Starting gRPC server at [::]:9000
2023/12/20 08:15:39 Starting HTTP server at [::]:8000
```
上記の通りの結果が返された場合、カスタム承認サービスがデプロイされています。
ext-authz サービスで使用されている gRPC ポートを取得します。
1. ACKコンソールにログオンします。左側のナビゲーションペインで、[クラスター] をクリックします。
2. [クラスター] ページで、管理するクラスターを見つけて、その名前をクリックします。左側のペインで、[ネットワーク] > [サービス] を選択します。
3. [サービス] ページで、[ext-authz] をクリックします。
  サービス詳細ページの [エンドポイント] セクションで、gRPCポートを表示できます。この例では、ポートは 9000 です。

手順 2: サンプルアプリケーションをデプロイする

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

httpbin.yaml ファイルを表示する

# Istio 作者による著作権
#
#   Apache ライセンス バージョン 2.0（以下「ライセンス」）に基づいてライセンスされています。
#   ライセンスに準拠する場合を除き、このファイルを使用することはできません。
#   ライセンスのコピーは以下から取得できます。
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   適用法で要求されている場合、または書面で合意されている場合を除き、ソフトウェア
#   ライセンスに基づいて配布されるものは「現状有姿」で配布され、
#   明示または黙示を問わず、いかなる種類の保証も条件も提供されません。
#   ライセンスに基づく権限と制限を規定する特定の言語については、ライセンスを参照してください。

##################################################################################################
# httpbin サービス
##################################################################################################
apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

次のコマンドを実行して、クラスターに httpbin アプリケーションをデプロイします。
```
kubectl apply -f httpbin.yaml
```

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

sleep.yaml ファイルを表示する

# Istio 作者による著作権
#
#   Apache ライセンス バージョン 2.0（以下「ライセンス」）に基づいてライセンスされています。
#   ライセンスに準拠する場合を除き、このファイルを使用することはできません。
#   ライセンスのコピーは以下から取得できます。
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   適用法で要求されている場合、または書面で合意されている場合を除き、ソフトウェア
#   ライセンスに基づいて配布されるものは「現状有姿」で配布され、
#   明示または黙示を問わず、いかなる種類の保証も条件も提供されません。
#   ライセンスに基づく権限と制限を規定する特定の言語については、ライセンスを参照してください。

##################################################################################################
# Sleep サービス
##################################################################################################
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

次のコマンドを実行して、クラスターに sleep アプリケーションをデプロイします。
```
kubectl apply -f sleep.yaml
```

ステップ 3：gRPC プロトコルを使用してカスタム認証サービスに接続する

ステップ 1 でデプロイしたカスタム認証サービスを ASM インスタンスで宣言します。これにより、ASM インスタンスはサービスを使用してリクエストを認証できます。

ASM コンソールにログオンします。左側のナビゲーションペインで、[サービスメッシュ] > [メッシュ管理] を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[メッシュセキュリティセンター] > [カスタム認証サービス] を選択します。表示されるページで、[カスタム認証サービスの定義] をクリックします。

[カスタム認証サービスの登録] ページで、[envoy.ext_authz に基づいて実装されたカスタム認証サービス (HTTP または Grpc プロトコル)] タブをクリックし、関連パラメーターを設定して、[作成] をクリックします。

タイプ	パラメーター	説明
必須パラメーター	プロトコル	カスタム認証サービスで使用されるプロトコル。この例では、GRPC が選択されています。
	名前	カスタム認証サービスの名前。この例では、値は `test` に設定されています。
	サービスアドレス	`<Service name>.<Namespace>.svc.<Domain name of the cluster>` の形式のカスタム認証サービスのエンドポイント。この例では、値は `ext-authz.default.svc.cluster.local` に設定されています。
	ポート (1 ～ 65535)	カスタム認証サービスのサービスポート。この例では、値は `9000` に設定されています。
	タイムアウト (秒)	認証結果を返却する必要がある期間。単位：秒。カスタム認証サービスがこの期間内に応答に失敗した場合、サービスは利用不可と見なされます。この例では、値は `10` に設定されています。
オプションパラメーター	認証サービスが利用できない場合に認証をスキップする	カスタム認証サービスが利用できない場合にリクエストを許可するかどうかを指定します。このスイッチをオンにすると、カスタム認証サービスが利用できない場合にリクエストが許可されます。
	認証サービスが利用できない場合に ASM プロキシによって返されるエラーコード	カスタム認証サービスが利用できない場合に返すエラーコード。このパラメーターは、[認証サービスが利用できない場合に認証をスキップ] をオフにした場合にのみ使用できます。[認証サービスが利用できない場合に ASM プロキシによって返されるエラーコード] をオンにした場合は、エラーコードを指定する必要があります。このようにして、カスタム認証サービスが利用できない場合、ASM はこのエラーコードを呼び出し元に返します。
	認証リクエスト内に元のリクエスト本文を含める	認証されるリクエストの本文を、カスタム認証サービスに送信される認証リクエストに追加するかどうかを指定します。このスイッチをオンにした場合は、リクエスト本文の最大長を指定する必要があります。不完全なメッセージを認証サービスに送信することを許可するもオンにした場合、リクエスト本文の長さが最大長を超えると、ASM はリクエスト本文を切り捨てます。次に、ASM は切り捨てられたリクエスト本文を含む認証リクエストをカスタム認証サービスに送信します。

ステップ 4: 承認ポリシーの作成

認証が必要なリクエスト操作を設定するために、承認ポリシーを作成します。

ASM コンソールにログインします。左側のナビゲーションペインで、[サービスメッシュ] > [メッシュ管理] を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[メッシュセキュリティセンター] > [承認ポリシー] を選択します。表示されるページで、[作成] をクリックします。

[作成] ページで、関連パラメーターを設定し、[作成] をクリックします。

パラメーター	説明
名前	カスタム承認ポリシーの名前。この例では、値は `test1` に設定されています。
ポリシータイプ	カスタム承認ポリシーのタイプ。この例では、値はカスタム承認サービスに設定されています。
カスタム承認サービス	この例では、grpcextauth-test(GRPC) が選択されています。
名前空間	承認ポリシーを作成する名前空間。この例では、[ワークロードスコープ] タブの [名前空間] パラメーターは default に設定されています。
有効範囲	承認ポリシーの有効範囲。この例では、値はサービスに設定されています。
ワークロード	承認ポリシーが有効になるワークロード。この例では、値は httpbin に設定されています。
リクエスト一致ルール	この例では、[リクエストターゲットの追加] セクションでパスがオンになり、値は `/headers` に設定されています。

ステップ 5：カスタム承認が想定どおりに実装されていることを確認する

次のコマンドを実行して、httpbin.default:8000/ip にアクセスします。
```
kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/ip" -s -o /dev/null -w "%{http_code}\n"
```
ステータスコード 200 が返されます。これは、カスタム承認がトリガーされていないことを示します。
次のコマンドを実行して、x-ext-authz: deny リクエストヘッダーを含むリクエストを使用して、httpbin.default:8000/headers にアクセスします。
```
kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -ndefault -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: deny" -s
```
予期される出力：
```
denied by ext_authz for not found header `x-ext-authz: allow` in the request
```
上記の結果は、カスタム承認がトリガーされたものの、認証が失敗したことを示します。

次のコマンドを実行して、x-ext-authz: allow リクエストヘッダーを含むリクエストを使用して、httpbin.default:8000/headers にアクセスします。

kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: allow" -s

予期される出力：

{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.default:8000",
    "User-Agent": "curl/8.5.0",
    "X-Envoy-Attempt-Count": "1",
    "X-Ext-Authz": "allow",
    "X-Ext-Authz-Check-Result": "allowed",
    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=c3e5364e87add0f4f69e6b0d029f5961b404c8f209bf9004b3d21a82cf67****;Subject=\"\";URI=spiffe://cluster.local/ns/default/sa/sleep"
  }
}

上記の結果は、カスタム承認がトリガーされ、認証が成功したことを示します。x-ext-authz: allow ヘッダーを含むリクエストのみが httpbin.default:8000/headers にアクセスできることが検証結果に示されています。これは、カスタム承認が想定どおりに実装されていることを示します。

参照資料

HTTP ベースのカスタム認証サービスを開発する方法の詳細については、「HTTP ベースのカスタム認証サービスを開発する」をご参照ください。
gRPC ベースのカスタム認証サービスを開発する方法の詳細については、「gRPC ベースのカスタム認証サービスを開発する」をご参照ください。
HTTP リクエストに対してきめ細かい RAM を実行する方法の詳細については、「HTTP プロトコルを使用してカスタム認証を実装する」をご参照ください。
ASM インスタンス内のサービスから外部サービスへのアクセストラフィックを制御する方法の詳細については、「認証ポリシーを使用して ASM インスタンス内のサービスから外部 Web サイトへのアクセストラフィックを制御する」および「認証ポリシーを使用して ASM インスタンス内のサービスから外部データベースへのアクセストラフィックを制御する」をご参照ください。
メッシュ監査機能を有効にして、さまざまなユーザーの日常業務を記録または追跡できます。また、ASM リソースに対する操作の監査アラートを設定し、重要なリソースが変更されたときに、アラート連絡先にタイムリーにアラート通知を送信することもできます。詳細については、「ASM で KubeAPI 操作監査機能を使用する」および「ASM リソースに対する操作の監査アラートを構成する」をご参照ください。