サービスのセキュリティ

このドキュメントでは、Traffic Director を使用したサービスセキュリティの概要について説明します。これは、Deployment に認証、暗号化、承認を追加する Traffic Director ユーザーを対象としています。このドキュメントは、Envoy による Traffic Director とプロキシレス gRPC アプリケーションに精通していることを前提としています。

Traffic Director を使用すると、メッシュ内のサービス間の通信を保護できます。メッシュ内では、各サービスに ID が割り当てられています。次の機能は、安全な通信をサポートするのに役立ちます。

Envoy とプロキシレス gRPC アプリケーションの両方の Traffic Director に対して Transport Layer Security（TLS）と相互 TLS（mTLS）を使用する認証と暗号化。クライアント TLS ポリシーとサーバーの TLS ポリシーは、サービスが互いに ID を証明し、暗号化された通信チャネルを使用する必要があるかどうかを制御します。
クライアントとリクエストの特性に基づく認可。認可ポリシーでは、サービスが別のサービスへアクセスすることを許可するかどうかと、許可するアクションを制御します。

プライベート認証局（CA）である Google の Certificate Authority Service によって提供される証明書と鍵を使用すると、サービスのセキュリティを容易に維持できます。CA Service は GKE メッシュ証明書を提供します。GKE メッシュ証明書機能と Traffic Director を使用すると、これらの証明書を自動的にデプロイしてワークロードで使用できるようになります。ワークロードで mTLS 認証情報を受信して使用できるように、Pod を修正します。Traffic Director サービスのセキュリティは、現在 GKE ベースのワークロードでのみ使用できます。

最新のマイクロサービスベースのアーキテクチャでは、大規模なモノリシックアプリケーションが的を絞った小規模なサービスに置き換えられています。サービスの呼び出しは、ネットワークを介して相互に通信を行います。これらの呼び出しはモノリシックアプリケーションのインプロセス呼び出しであり、セキュリティ上の課題が発生するため、認証、暗号化、認可を行うことをおすすめします。これらの手順では、トラフィックがネットワーク内部または外部のいずれから発生するかを問わず、すべてのネットワークトラフィックが危険にさらされていると仮定するゼロトラストの原則をサポートしています。

サービスメッシュ設計パターンは、サービス間通信に関連する複雑性をビジネスロジックから分離します。代わりに、データプレーンがこの複雑さを処理します。サービスメッシュ設計パターンによって、アプリケーションの複雑性を軽減するのみでなく、この設計パターンを用いなければ実装と管理が困難であることが考えられるセキュリティパターンを実現することもできます。

このモデルでは、プロキシレス gRPC または Envoy サイドカーが、Traffic Director から構成情報を取得することによる通信と、CA Service プールから取得した証明書を安全に認証し、暗号化します。

これらのセキュリティ機能により、以下の内容を実現することによって Traffic Director のデプロイプロセスを簡易化できます。

メッシュ内のすべてのサービスへの鍵と証明書の自動プロビジョニング。
鍵と証明書の自動ローテーションによるセキュリティの強化。
Google Kubernetes Engine（GKE）と統合した、デプロイ記述子やラベルなどのすべての機能の使用。
Traffic Director や CA Service マネージドプライベート認証局プールなど、Google が管理するサービスの高可用性。
Google Identity and Access Management（IAM）に関連付けられたセキュリティ: 認可済みの Google サービスアカウントに基づくサービス認証。
Envoy ベースのワークロードやプロキシレスワークロードとのシームレスな相互運用性。とえば、サービスは Envoy プロキシの背後にある可能性がありますが、クライアントは gRPC プロキシレスサービスメッシュセキュリティを使用します。逆に、サービスが gRPC プロキシレスサービスメッシュセキュリティの背後にある可能性がありますが、クライアントは Envoy プロキシを使用します。

サービス間の通信を保護する

Traffic Director は、TLS を使用する認証と暗号化によりサービス間のセキュリティを提供します。クライアント TLS ポリシーとサーバー TLS ポリシーを使用すると、サービスで次のことが可能になります。

ID を表明して検証する。
TLS または mTLS を使用して通信セッションを暗号化する。

サービスメッシュでは、データプレーンがこのタイプのセキュリティを処理するため、アプリケーションを保護するために特別なプロビジョニングを行う必要はありません。

認可ポリシーを使用すると、定義したルールに従ってアクセスを拒否または許可できます。

暗号化に TLS を使用する

サービスが HTTP、HTTP/2、または gRPC プロトコルを使用して別のサービスを呼び出すと、ネットワークを経由するトラフィックは平文になります。このトラフィックは中間者攻撃を受ける可能性があり、攻撃者がトラフィックを傍受して、内容を検査、または操作する可能性があります。

この潜在的な問題を軽減するには、Traffic Director で TLS を介して HTTP、HTTP/2、または gRPC を使用します。TLS を介してこれらのプロトコルを使用する場合、クライアントとサーバー間のトラフィックは、サーバーの証明書に基づく TLS を使用して暗号化されます。トラフィックは平文ではなくなり、攻撃者がコンテンツを傍受、検査、または操作する可能性が低減します。

認証に TLS を使用する

サービスが別のサービスを呼び出す場合は、次の点を考慮してください。

クライアントがなりすましではなく、正しいサーバーからレスポンスを受信していることをどのようにして確認しているのか。たとえば、HTTP に基づく一般的なリクエスト / レスポンスのインタラクション場合、クライアントはサーバーの ID を確認しません。
攻撃者がそのトラフィックを傍受した場合、どうなるか。たとえば、HTTP トラフィックは暗号化されないため、トラフィックを受信した任意のユーザーがコンテンツを検査できます。これは「中間者攻撃」として知られています。

この問題を軽減するには、TLS を介して HTTP、HTTP/2、gRPC を使用します。こうしたクライアントとサーバー間の交換では、サーバーがサーバー証明書を使用してクライアントに対して証明を行う必要があります。リクエストとレスポンスは TLS を使用して暗号化されます。

相互 TLS 認証

Traffic Director がクライアントとサーバーの両方に対してアプリケーションネットワーキングを構成する場合（たとえば、クライアント側で Envoy プロキシを構成し、サーバー側で別の Envoy プロキシを構成する場合）、相互認証などの高度な認証パターンを利用できます。

相互認証に基づいていない一般的な HTTP over TLS 交換では、サーバーには、クライアントとサーバーの間の通信の暗号化に使用する証明書があります。クライアントは、TLS handshake 中にサーバーが送り返す署名を確認することで、サーバーの ID を検証できます。ただし、サーバーはクライアントの ID を検証しません。

相互認証が有効になっている場合は、クライアントにも証明書があります。前の段落で説明したように、クライアントはサーバーの ID を検証し、サーバーもクライアントの ID を検証できます。クライアント証明書とサーバー証明書の両方が、通信チャネルを暗号化するために使用されます。また、これにより、サーバーが、検証済みのクライアント ID に基づいてクライアントを認可することもできます。

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

サービス呼び出しを認可する

サービスへのアクセスは、認可ポリシーを使用して、許可または拒否できます。Traffic Director を使用すると、リクエストパラメータに基づいてアクセスを認可する許可ルールと拒否ルールを定義できます。これらのルールは、レイヤ 3 とレイヤ 7 のパラメータ（mTLS 接続の client-cert から派生したクライアント ID、送信元 IP アドレス、ホストの一致、メソッドの一致、ヘッダーの一致など）に基づいて作成できます。次の図では、Envoy プロキシを使用した認可を示します。このプロセスは gRPC クライアントと類似しています。

サービスメッシュでの認可。 — Envoy を使用したサービスメッシュでの認可（クリックして拡大）

認可を使用してアクセスを制限する

サービスメッシュにおけるベストプラクティスは、最小権限の原則に従うことです。この原則に従うには、サービスへのアクセスを、サービスに依存する呼び出し元のみに制限します。呼び出し元が認可されていないサービスにアクセスしようとすると、その試行は拒否されます。

Traffic Director を使用すると、定義したルールに基づいてデータプレーンがサービスへのアクセスを許可または拒否できる認可ポリシーを構成できます。これらのポリシーは、次の 2 つのコンポーネントで構成されます。

アクション: 許可または拒否
ルールのリスト

リクエストや RPC が送信されると、呼び出されたサービスの Traffic Director クライアントでは、一致するルールがあるどうかが判断されます。一致するものがある場合、そのリクエストや RPC は許可または拒否されます。たとえば、属性に関する一致ルールは次のように定義できます。

mTLS が使用されている場合は、呼び出し元サービスの Kubernetes サービスアカウント
呼び出し元のサービスの IP アドレス（またはアドレス範囲）
宛先サービスのポート
リクエストの HTTP 属性（ホスト名、メソッド、ユーザー定義の HTTP ヘッダーなど）

安全な命名

追加のセキュリティメカニズムとして、Traffic Director を使用して安全な命名を構成できます。これにより、クライアントが接続しようとしている特定のサービスに対して許可された名前のリストまたは SPIFFE（Secure Production Identity Framework For Everyone）の ID を定義できます。TLS の交換中に、サービスのバックエンドはクライアントに X.509 証明書を返します。次に、クライアントは証明書を検査して、X.509 証明書が、名前 / SPIFFE ID のいずれかに一致していることを確認します。SPIFFE ID の詳細については、Secure Production Identity Framework for Everyone をご覧ください。

ゲートウェイでトラフィックを保護する

ゲートウェイを構成するには、Traffic Director を使用します。ゲートウェイはスタンドアロンの Envoy プロキシであり、通常は次のいずれかとして機能します。

メッシュまたは他のドメインに入るトラフィックを処理する上り（内向き）ゲートウェイ
メッシュまたは他のドメインから送信されるトラフィックを処理する Egress ゲートウェイ
1 つ以上のサービスで受信トラフィックを分散するリバースプロキシまたは中間プロキシ

トラフィックをメッシュに送信する、またはメッシュから送信することを必要とするクライアントは、トラフィックをゲートウェイに送信します。ゲートウェイは、Traffic Director で設定したルールに従ってリクエストを処理します。たとえば、上り（内向き）ゲートウェイを介してメッシュに入るトラフィックを TLS を使用して暗号化する必要があります。

セキュリティコンポーネント

Traffic Director サービスのセキュリティは、クライアント TLS ポリシー、サーバー TLS ポリシー、認可ポリシーをサポートしています。これらのポリシーを作成して、Traffic Director でデータプレーンを構成し、セキュリティ機能を有効にできるようにします。これらのポリシーを作成または更新するために、アプリケーションを変更する必要はありません。

暗号化モードとサポートされている認証モード

あるサービスで別のサービスを呼び出す際に、安全な通信を確立するための最初のステップは、各サービスが別のサービスに対して自身の ID を証明することです。サービスが ID を証明するために必要な度合いは、構成した TLS モードに基づきます。

次のセキュリティレベルを構成できます。

暗号化なし / 未認証
TLS
相互 TLS（mTLS）
制限なし: クライアントの接続開始方法に応じて、mTLS または暗号化なし / 未認証のいずれか

証明書と認証局

証明書と信頼できる認証局（CA）は、サービスメッシュなどの分散システムの信頼の基盤となります。サービスで証明書を使用すると、以下のように ID を証明し、提示される ID を検証できます。

あるサービスで自身の ID を別のサービスに対して証明する場合、その証明書が他のサービスに提示されます。両方のサービスが信頼する CA により、証明書の署名と証明書の発行が行われます。
この証明書を受信したサービスは、証明書が信頼する CA によって発行されたものであることを検証できます。

Traffic Director は認証局ではありません。安全な通信を有効にするには、次のメカニズムを設定する必要があります。

ID と証明書をプロビジョニングする
Traffic Director で構成された Traffic Director クライアント（Envoy プロキシなど）で証明書を使用できるようにする

Traffic Director は Google の CA Service をサポートしています。この設定手順は、Envoy とプロキシレス gRPC の設定ガイドに記載されています（詳細については、次のステップをご覧ください）。

アーキテクチャとリソース

Traffic Director には Network Security API 名前空間が含まれ、この名前空間は 3 つの Google Cloud API リソースで構成されており、データプレーンに適用するセキュリティポリシーを指定できます。

メッシュ内では、クライアント TLS ポリシーとサーバー TLS ポリシーの 2 つの Google Cloud API リソースが認証をサポートします。3 つ目のリソースである認可ポリシーは認可をサポートします。

Network Services API 名前空間にはエンドポイントポリシーリソースが含まれており、これによって Traffic Director で構成（サーバー TLS、クライアント TLS、認可ポリシー）をエンドポイントに提供できます。エンドポイントは、別の Traffic Director クライアントからのインバウンド通信を終端する Traffic Director クライアントです。

クライアント TLS ポリシー

クライアント TLS ポリシーを使用すると、データプレーンに適用されるクライアント側 TLS モードと証明書プロバイダ情報を指定できます。クライアント TLS ポリシーは、TLS 認証および mTLS 認証をサポートします。クライアント TLS ポリシーは、グローバルバックエンドサービスリソースに接続する必要があります。

TLS を構成するときは、serverValidationCa API フィールドを使用して、TLS 交換中にサーバーから受け取った証明書をクライアントの検証メカニズムを渡す必要があります。クライアントはこの情報を使用して、サーバー証明書の検証に使用できる検証証明書を取得します。

mTLS を構成する場合は、クライアントが clientCertificate API フィールドを使用して証明書と秘密鍵を取得するメカニズムも用意する必要があります。クライアントは、TLS handshake 中に、この情報を使用してサーバーに証明書を提示します。

このリリースでは、Traffic Director はマネージド認証局 CA Service をサポートしています。構成は容易に行うことができます。証明書プロバイダを構成する際に google_cloud_private_spiffe プラグイン名を指定します。これにより、xDS クライアントが静的ロケーションから証明書と鍵を読み込みます。前提条件として、CA Service プールを構成し、GKE クラスタでメッシュ証明書を有効にする必要があります。

サーバー TLS ポリシー

サーバー TLS ポリシー（ServerTlsPolicy リソース）を使用して、データプレーンに適用するサーバー側の TLS モードと証明書プロバイダ情報を指定できます。サーバー TLS ポリシーは、TLS、mTLS、Open_or_mTLS 認証のみをサポートしています。サーバー TLS ポリシーは、エンドポイントポリシーリソースに接続します。

サブジェクトの代替名

グローバルバックエンドサービスの securitySettings フィールドを構成する場合は、subjectAltNames フィールドにサブジェクトの代替名のリストを指定できます。クライアントがサービスのバックエンドのいずれかを使用して TLS handshake を開始すると、サーバーは X.509 証明書を提示します。クライアントは証明書の subjectAltName フィールドを検査します。フィールドに指定された値のいずれかが含まれている場合は、通信が続行されます。このメカニズムについては、前述の安全な命名をご覧ください。

認可ポリシー

認可ポリシー（AuthorizationPolicy リソース）は、サーバーが受信リクエストや RPC を認可する方法を指定します。リクエストを送信したクライアントの ID、ホスト、ヘッダー、その他の HTTP 属性など、さまざまなパラメータに基づいて受信するリクエストや RPC を許可または拒否するように構成できます。認可ポリシーは、エンドポイントポリシーリソースに接続します。

制限事項

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

プロキシレス gRPC アプリケーションの制限事項

プロキシレス gRPC サービスのサービスセキュリティには次の制限があります。

このリリースは Java、Python、C++、Go に限定されています。

次のステップ

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