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

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

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

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

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

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

次のセクションでは、グローバル転送ルール、ターゲット HTTPS プロキシ、URL マップの説明は省略します。メッシュを作成するために Compute Engine API のリソースが必要ですが、mTLS を有効にするためにリソースを更新する必要はありません。

前述のパターンを実現するには、次の 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. 受信トラフィックに対する認証を必須とする Traffic Director クライアントを選択するには、EndpointMatcher を定義します。

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

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

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

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

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

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

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

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

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

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

      次のように、Traffic Director クライアントにラベルを追加できます。

      • このメタデータは、Traffic Director クライアントのブートストラップ ファイルで手動により指定できます。

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

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

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

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

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

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

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

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

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

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

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

Traffic Director セキュリティを設定する際に、さまざまな Compute Engine API リソースを構成します。これらのリソースは、ロードバランサ用に構成するリソースとは別のものです。つまり、異なる負荷分散スキームで 2 組の Compute Engine API リソース（グローバル転送ルール、ターゲット プロキシ、URL マップ、グローバル バックエンド サービス）を作成します。

• 1 つのリソースセットでロードバランサを構成し、負荷分散スキーム INTERNAL_MANAGED を設定します。
• もう一方のリソースセットで、負荷分散スキーム INTERNAL_SELF_MANAGED が存在する Traffic Director を構成します。

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

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

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

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

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

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

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

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

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

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

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

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

1. メッシュへの上り（内向き）トラフィックのパスを表すグローバル転送ルールとターゲット HTTPS プロキシを作成します。

2. メッシュ用の既存の URL マップを、このターゲット HTTPS プロキシに接続します。URL マップには、メッシュと mTLS の構成時に指定された構成に基づいて、メッシュのさまざまなグローバル バックエンド サービスへの参照がすでに含まれています。

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

4. サーバーの TLS ポリシー リソースをターゲット HTTPS プロキシに接続します。

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

たとえば、次のように想定します。

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

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

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

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

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

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

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

制限事項

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

次のステップ

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