サービス セキュリティのユースケース

このドキュメントでは、Cloud Service Mesh の一般的なセキュリティ ユースケースについて説明します。この情報を使用して、ニーズに最適なセキュリティ モデルを決定できます。このドキュメントでは、各ユースケースで構成する必要がある対象の概要についても説明します。

サービス セキュリティの概要については、Cloud Service Mesh サービス セキュリティをご覧ください。

メッシュ内のサービスでの相互 TLS の有効化

サービス メッシュでは、通信のクライアントとサーバーの両方が ID を証明し、通信を暗号化する必要があるため、相互 TLS（mTLS）を有効にできます。

サービス メッシュでの相互 TLS（mTLS）認証（クリックして拡大）

次のセクションでは、Mesh、Gateway、Route リソースの説明を省略しています。メッシュを作成してトラフィックをルーティングする場合は、これらの API リソースが必要ですが、mTLS を有効にする場合は、これらの API リソースを更新する必要はありません。

前述のパターンを実現するには、次の Compute Engine API リソースを構成します。この図ではサイドカー プロキシを使用していますが、mTLS を使用してプロキシレス gRPC アプリケーションを構成する場合も同じリソースを使用します。

メッシュ内の mTLS 用の Compute Engine API リソース（クリックして拡大）

このモデルを作成するには、以下のようにします。

1. クライアントの Transport Layer Security（TLS）ポリシーを作成します。
2. サーバーの TLS ポリシーを作成します。
3. 新しいクライアントの TLS ポリシーを参照するには、既存のグローバル バックエンド サービスの securitySettings フィールドを更新します。

4. エンドポイント ポリシーを作成します。

   1. server_tls_policy フィールドでサーバーの TLS ポリシーを参照します。

   2. 受信トラフィックに対して認証を適用する Cloud Service Mesh クライアントを選択するには、EndpointMatcher を定義します。

      Cloud Service Mesh クライアントの選択は、Cloud Service Mesh クライアントのブートストラップ構成で指定されたラベルに基づきます。これらのラベルは、手動で指定することも、Google Kubernetes Engine（GKE）のデプロイに対して指定されたラベルに基づいて自動的に入力することもできます。

      上の図では、ラベル "mesh-service":"true" がエンドポイント ポリシーと Cloud Service Mesh クライアントで構成されています。デプロイに適したラベルを選択できます。

   3. 必要に応じて、データプレーン エンティティの指定ポートへの受信リクエストが行われた場合にのみポリシーを適用する TrafficPortSelector を定義します。

次の図に、Envoy またはプロキシレス gRPC アプリケーションのいずれを使用するかを問わず、mTLS 用に構成する Compute Engine リソースを示します。

メッシュ内の mTLS 用の Compute Engine API リソース（クリックして拡大）

次の図は、トラフィック フローと、mTLS を有効にするように構成した Compute Engine API リソースを示しています。サービス B の GKE Pod とともに配置されたローカル サイドカー プロキシは、通信におけるエンドポイントです。

メッシュ内の mTLS 用の Compute Engine API リソースとトラフィック フロー（クリックして拡大）

エンドポイント ポリシーは、次の処理を行います。

1. エンドポイント マッチャーを使用してエンドポイントのセットを選択し、必要に応じてそれらのエンドポイント上のポートを選択します。

   1. エンドポイント マッチャーを使用すると、Cloud Service Mesh クライアントが構成を受信するかどうかを決定するルールを指定できます。これらのルールは、データプレーン エンティティがコントロール プレーン（この場合は Cloud Service Mesh）に提供する xDS メタデータに基づいています。

      Cloud Service Mesh クライアントにラベルを追加する手順は次のとおりです。

      • このメタデータは、Cloud Service Mesh クライアントのブートストラップ ファイルで手動で指定できます。

      • または、GKE を使用する際に demo_server.yaml ファイルまたは demo_client.yaml ファイルの env セクションに Key-Value ペアを追加することで、メタデータを自動的に入力できます。これらの値は、Envoy 設定ガイドとプロキシレス gRPC 設定ガイドで指定されています。

        たとえば Envoy の場合のみ、鍵に ISTIO_META_ 接頭辞を追加できます。ISTIO_META_ で始まるプロキシ環境変数名は、生成されたブートストラップに含まれ、xDS サーバーに送信されます。

        - name: ISTIO_META_app
          value: 'review'
        - name: ISTIO_META_version
          value: 'canary'
        

   2. ポートを指定すると、エンドポイント ポリシーで参照されるポリシーは、同じポートを指定する受信リクエストにのみ適用されます。ポートを指定しない場合、このポリシーは、ブートストラップ情報で Traffic Director クライアントに提供される TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS フィールドにも存在するポートを指定する受信リクエストに適用されます。

2. リクエストを解決するエンドポイントを構成するクライアント TLS、サーバー TLS、認可ポリシーを参照します。

互換性のない TLS モードを構成すると、通信が中断する可能性があります。たとえば、グローバル バックエンド サービスで OPEN を設定するか、クライアント TLS ポリシー フィールドを空のままにして、エンドポイント ポリシーのサーバー TLS ポリシーの値として MTLS を設定すると、通信の試行が失敗します。これは、mTLS のみを受け入れるように構成されているエンドポイントが、未認証通信チャンネルの確立の試行を拒否するためです。

クライアント TLS ポリシーと、グローバル バックエンド サービスおよびエンドポイント ポリシーに接続されたサーバー TLS ポリシーとの区別に注意してください。

• クライアントの TLS ポリシーはグローバル バックエンド サービスに適用され、Envoy プロキシまたはプロキシレス クライアントに対し、サービスを指定する際に使用する TLS モード、ID、ピア検証アプローチについて指示します。
• サーバーの TLS ポリシーはエンドポイント ポリシーに接続され、受信接続に使用する TLS モード、ID、ピア検証アプローチについてサーバーに指示します。

上り（内向き）ゲートウェイでの TLS の有効化

メッシュ内通信用の mTLS を設定したら、上り（内向き）トラフィックと呼ばれる、メッシュに着信するトラフィックを保護することをおすすめします。Cloud Service Mesh では、上り（内向き）トラフィックに TLS で暗号化された通信チャンネルを使用することを要求するようにデータプレーンを構成できます。

この目標を達成するには、次のいずれかのアーキテクチャ オプションを選択します。

• メッシュ内のサービスでロードバランサからのトラフィックの TLS を終端する。このモデルでは、メッシュ内の各サービスが、ロードバランサの構成でバックエンドとして構成されます。具体的には、ロードバランサの URL マップを使用します。
• 上り（内向き）ゲートウェイは、トラフィックをメッシュ内のサービスに転送する前にロードバランサからのトラフィックの TLS を終端します。このモデルでは、メッシュ内の専用サービスである上り（内向き）ゲートウェイがロードバランサの構成（具体的には、ロードバランサの URL マップ）でバックエンドとして構成されます。

このセクションでは、両方のオプションについて説明します。

メッシュ内のサービスでロードバランサからのトラフィックの TLS を終端する

Google Cloud の外部のクライアントでサービスを使用できるようにするには、外部アプリケーション ロードバランサを使用できます。クライアントは、ロードバランサのグローバル エニーキャスト仮想 IP アドレス（VIP）にトラフィックを送信し、エニーキャスト仮想 IP アドレスはこのトラフィックをメッシュ内のサービスに転送します。つまり、外部クライアントがメッシュ内のサービスにアクセスする必要がある場合には 2 つの接続が存在します。

メッシュ内のサービスへの TLS 接続（クリックして拡大）

内部アプリケーション ロードバランサを使用する場合も、同じパターンが適用されます。内部クライアントからのトラフィックはまずロードバランサに到達し、次にバックエンドへの接続を確立します。

両方の接続を保護するには:

1. 外部アプリケーション ロードバランサを使用して、クライアントとロードバランサ間の接続を保護します。
2. メッシュ内のサービスとの接続を確立しようとしたときに HTTPS プロトコルまたは HTTP/2 プロトコルを使用するようにロードバランサを構成します。
3. Cloud Service Mesh クライアントが HTTPS を終端し、クライアント（この場合はロードバランサ）に証明書を提示するように Cloud Service Mesh を構成します。

ステップ 1 と 2 の詳細については、マルチリージョンのコンテンツ ベースの外部 HTTPS ロードバランサの設定をご覧ください。

Cloud Service Mesh のセキュリティを設定する際に、さまざまな Compute Engine API リソースを構成します。これらのリソースは、ロードバランサ用に構成するリソースとは別のものです。ロードバランサ用の一連の Compute Engine API リソース（グローバル転送ルール、ターゲット プロキシ、URL マップ、グローバル バックエンド サービス）を作成し、サービス ルーティング API を使用して Cloud Service Mesh を構成します。また、バックエンド サービス リソースでは、ロードバランサにロード バランシング スキーム INTERNAL_MANAGED が、Cloud Service Mesh にはロード バランシング スキーム INTERNAL_SELF_MANAGED があります。

ステップ 3 では、Cloud Service Mesh クライアントが HTTPS を終端し、クライアントに証明書を提示するように Cloud Service Mesh を構成します。

メッシュ内のサービスへの TLS 接続用の Compute Engine API リソース（クリックして拡大）

このモデルでは、次の操作を行います。

1. serverTlsPolicy を作成します。serverTlsPolicy リソースで serverCertificate を構成します。
2. エンドポイント ポリシーを作成します。
   1. authentication フィールドでサーバーの TLS ポリシーを参照します。
   2. EndpointMatcher を定義して、受信トラフィックで認証を適用する xDS データプレーン エンティティを選択します。
   3. 必要に応じて、Cloud Service Mesh クライアントの指定したポートへのインバウンド リクエストが行われた場合にのみポリシーを適用するように TrafficPortSelector を定義します。

外部アプリケーション ロードバランサはメッシュ内のサービスへの TLS 接続を開始するようにすでに構成されているため、Cloud Service Mesh で行う必要があるのは、TLS 接続を終端するように Cloud Service Mesh クライアントを構成することのみです。

上り（内向き）ゲートウェイがトラフィックをメッシュ内のサービスに転送する前にロードバランサからのトラフィックの TLS を終端する

上り（内向き）ゲートウェイのみをロードバランサに公開する場合は、上り（内向き）ゲートウェイのデプロイ パターンを使用できます。このパターンでは、ロードバランサはメッシュ内のサービスに直接アクセスしません。代わりに、中間プロキシはメッシュのエッジに配置され、Cloud Service Mesh から受信した構成に基づいてトラフィックをメッシュ内のサービスにルーティングします。中間プロキシは、Compute Engine マネージド インスタンス グループの仮想マシン（VM）インスタンスにデプロイした Envoy プロキシです。

上り（内向き）ゲートウェイへの TLS 接続をメッシュ内で mTLS により保護する（クリックして拡大）

セキュリティの観点から、TLS を終端する上り（内向き）ゲートウェイを構成し、必要に応じてメッシュ内の接続を構成して mTLS によって保護します。構成対象の接続には、上り（内向き）ゲートウェイとメッシュ内のサービス間の接続、およびメッシュ内のサービス間の接続が含まれます。

構成の観点から行う作業は次のとおりです。

1. サービス メッシュを構成し、メッシュ内の通信用に mTLS を有効にします（前述のとおり）。
2. 上り（内向き）ゲートウェイにトラフィックをルーティングし、HTTPS プロトコルを使用して接続を開始するようにロードバランサを構成します（前述のとおり）。
3. 上り（内向き）ゲートウェイとサーバーの TLS ポリシーを表す一連の Compute Engine API リソースを作成します。

3 番目のステップとして、次のように HTTPS を終端して、証明書を提示するように Cloud Service Mesh を構成します。

1. メッシュを表す Mesh リソースを作成します。

2. 正しいグローバル バックエンド サービスを指す Route リソースを作成し、Route リソースを Mesh リソースに接続します。

3. サーバーの TLS ポリシーを作成して serverCertificate を構成します。

4. Cloud Service Mesh が管理する上り（内向き）ゲートウェイを表す Gateway リソースを作成します。

5. サーバーの TLS ポリシー リソースを Gateway リソースに接続します。

上り（内向き）ゲートウェイ パターンは、共有 VPC を使用する大規模な組織で特に有用です。このような設定では、チームは上り（内向き）ゲートウェイを介したサービスへのアクセスのみを許可できます。前の図では、ロードバランサにグローバル転送ルールを構成する際に、メッシュ構成時に指定した IP アドレスと異なる IP アドレス（この例では 10.0.0.2）を指定しています（この例では、メッシュ アドレスは 10.0.0.1 です）。Cloud Service Mesh で構成された xDS データプレーン エンティティを介して通信するクライアントは、このアドレスを使用して上り（内向き）ゲートウェイにアクセスできます。

たとえば、次の場合について考えてみましょう。

• 1 つの共有 VPC ネットワークに接続された 2 つのサービス プロジェクト（1 と 2）。

• サービス プロジェクト 1 には、Cloud Service Mesh によって構成されたサービス メッシュが含まれます。

  サービス プロジェクト 1 はメッシュと上り（内向き）ゲートウェイを構成しています。この上り（内向き）ゲートウェイには 10.0.0.2 アドレス / VIP で到達可能です。

• サービス プロジェクト 2 には、Cloud Service Mesh によって構成されたサービス メッシュが含まれます。

  サービス プロジェクト 2 には、独自の上り（内向き）ゲートウェイが存在する場合と存在しない場合があります。

• Cloud Service Mesh は、各サービス プロジェクトの Cloud Service Mesh クライアントを構成します。クライアントは、同じネットワークを使用するようにブートストラップされます。

この構成の場合、サービス プロジェクト 2 のメッシュのクライアントは、10.0.0.2 VIP を使用してサービス プロジェクト 1 の上り（内向き）ゲートウェイと通信できます。これにより、サービス プロジェクト 1 のオーナーが、メッシュに着信するトラフィックに固有のルーティング、セキュリティ、その他のポリシーを構成できます。実際には、サービス プロジェクト 1 の所有者は、「メッシュに含まれるクライアントが 10.0.0.2 でサービスにアクセスできる」ことを通知できます。

制限事項

Cloud Service Mesh サービスのセキュリティは GKE でのみサポートされています。Compute Engine ではサービスのセキュリティをデプロイできません。

次のステップ

• Envoy プロキシを使用した Cloud Service Mesh サービスのセキュリティ構成について、Envoy での Cloud Service Mesh サービスのセキュリティの設定で確認する。
• プロキシレス gRPC アプリケーションでの Cloud Service Mesh サービス セキュリティの構成について、プロキシレス gRPC での Cloud Service Mesh サービス セキュリティの設定で確認する。