ゼロトラストアクセス向け gRPC カスタム認可サービス構築 - Alibaba Cloud Service Mesh

Service Mesh (ASM) は、HTTP および gRPC プロトコルベースのカスタム権限付与サービスをサポートしています。gRPC ベースの権限付与サービスは、Envoy から gRPC の CheckRequest メッセージを受信し、リクエスト属性を検査して、許可または拒否の決定を返します。このガイドでは、このようなサービスを実装し、ASM に登録する手順を説明します。

カスタム権限付与サービスの全体的なアーキテクチャについては、「HTTP ベースのカスタム権限付与サービスの開発」をご参照ください。

HTTP ベースのカスタム権限付与サービスとは異なり、gRPC ベースのサービスにはヘッダー関連の構成がありません。すべてのリクエストヘッダーは、Envoy からの gRPC CheckRequest メッセージに直接埋め込まれます。

前提条件

開始する前に、以下のものが準備できていることを確認してください。

ASM に接続されている実行中の Container Service for Kubernetes (ACK) クラスター
ローカルにセットアップされた Go 開発環境
Envoy の外部権限付与 API に関する知識

権限付与サーバーの実装

ASM はオープンソースの Istio と互換性があります。Istio は、HTTP と gRPC の両方のカスタム権限付与をカバーするリファレンス実装を提供しています。gRPC 固有のロジックは、extAuthzServerV3 構造体に実装されています：

type extAuthzServerV3 struct{}
func (s *extAuthzServerV3) Check(_ context.Context, request *authv3.CheckRequest) (*authv3.CheckResponse, error)
func (s *extAuthzServerV3) allow(request *authv3.CheckRequest) *authv3.CheckResponse
func (s *extAuthzServerV3) deny(request *authv3.CheckRequest) *authv3.CheckResponse
func (s *extAuthzServerV3) logRequest(allow string, request *authv3.CheckRequest)

この構造体は、単一のメソッドを必要とする Envoy の AuthorizationServer インターフェイスを実装しています：

type AuthorizationServer interface {
    // 受信リクエストに関連付けられた属性に基づいて権限付与チェックを実行し、
    // ステータス `OK` または `OK` 以外を返します。
    Check(context.Context, *CheckRequest) (*CheckResponse, error)
}

コア権限付与ロジック

Check メソッドは、リクエスト属性を抽出し、それらを評価して、許可または拒否の応答を返します：

// Check は gRPC v3 のチェックリクエストを実装します。
func (s *extAuthzServerV3) Check(_ context.Context, request *authv3.CheckRequest) (*authv3.CheckResponse, error) {
    attrs := request.GetAttributes()

    // リクエストを許可するか拒否するかを決定します。
    allow := false
    checkHeaderValue, contains := attrs.GetRequest().GetHttp().GetHeaders()[checkHeader]
    if contains {
        allow = checkHeaderValue == allowedValue
    } else {
        allow = attrs.Source != nil && strings.HasSuffix(attrs.Source.Principal, "/sa/"+*serviceAccount)
    }

    if allow {
        return s.allow(request), nil
    }

    return s.deny(request), nil
}

決定は 2 つのパスに従います：

ヘッダーベースのチェック -- リクエストに checkHeader ヘッダーが含まれている場合、サービスはその値を allowedValue と比較します。一致した場合、アクセスが許可されます。
ID ベースのフォールバック -- ヘッダーが存在しない場合、サービスはソース ID (attrs.Source.Principal) が /sa/<serviceAccount> で終わるかどうかをチェックします。これにより、特定の Kubernetes サービスアカウントからのリクエストが許可されます。

CheckRequest フィールドのリファレンス

authv3.CheckRequest のフィールドの完全なリストについては、以下をご参照ください：

API バージョン

Envoy は v2 API を非推奨としています。上記の Check メソッドのシグネチャに示されているように、v3 gRPC API のみを実装してください。

権限付与サービスの登録と適用

権限付与サービスを ACK クラスターにデプロイした後、以下の手順を実行します：

ASM コンソールを開き、[カスタム権限付与サービスの定義] ページに移動します。
gRPC ベースの権限付与サービスを登録します。
どのメッシュプロキシが権限付与サービスを使用するかを指定する権限付与ポリシーを作成します。

詳細な手順については、「gRPC プロトコルを使用したカスタム権限付与の実装」をご参照ください。

次のステップ

gRPC プロトコルを使用したカスタム権限付与の実装 -- エンドツーエンドのセットアップと構成。
HTTP ベースのカスタム承認サービスを開発する — gRPC の代わりに HTTP を使用する代替アプローチ。