Traffic Director を使用した gRPC アプリのセキュリティ構成の紹介
Google Cloud Japan Team
※この投稿は米国時間 2021 年 8 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。
デベロッパーは、バックエンドのサービス間通信や、ウェブ、モバイル、クラウド間のクライアント サーバー通信などのユースケースに gRPC RPC フレームワークを使用します。2020 年 7 月、Google のアプリケーション ネットワーキングのマネージド コントロール プレーンである Traffic Director を使用して、運用の複雑さを軽減し、サービス メッシュのパフォーマンスを向上させる プロキシレス gRPC サービスのサポートを発表しました。翌月の 8 月には、ルート マッチングやトラフィック分割などの高度なトラフィック管理機能のサポートを追加しました。そして今回、gRPC サービスは、TLS と相互 TLS を使用して相互に安全な通信を確立するように、Traffic Director コントロール プレーンを介して構成できるようになりました。このブログ投稿では、この機能が重要な理由と、開始するために必要な手順について説明します。
なぜ gRPC サービスなのか
汎用 RPC フレームワークである gRPC は、Google 社内で使用されていた通信プロトコルのオープンソースおよび HTTP/2 ベースのバージョンとして開発されました。現在、gRPC は世界中の 1,000 を超える組織で使用されています。
gRPC は、さまざまなユースケースとデプロイモデルをサポートします。前述のバックエンド サービス間の通信や、Google Cloud サービスにアクセスするためのさまざまなクライアントによる通信がこれに当たります。gRPC は多言語環境をサポートしており、たとえば、Java クライアントを Go 言語で記述されたサーバーと通信できるようにします。
gRPC は HTTP/2 の上に実装され、シリアル化 / シリアル化解除メカニズムとして主に protobuf を使用します（ただし、代替メカニズムも使用できます）。この 2 つの組み合わせにより、組織は、堅固な RPC フレームワークを利用して、規模が拡大するにつれて新たに発生する問題に対処できます。
複数言語に対応
自動クライアント ライブラリ生成に対応。これによりボイラープレート コードの量が減少し、アジリティが向上
発展するメッセージ定義（下位互換性）に対応し、信頼できる唯一の情報源を提供する protobuf サポート
効率とパフォーマンスを向上させる HTTP/2 のバイナリ フレーミング
同時ストリームと双方向ストリーミングに対応する HTTP/2 サポート
プロキシレス gRPC サービス
gRPC には、今日のマイクロサービスベースのアーキテクチャで果たすべき重要な役割があります。大きなモノリシック アプリケーションが小さなマイクロサービスに分割されると、モノリスのコンポーネント間のプロセス内呼び出しは、マイクロサービス間のネットワーク呼び出しに変換されます。gRPC を使用すると、前のセクションで説明した利点と、昨年追加した xDS プロトコルのサポートの両方により、サービスの通信が容易になります。
マイクロサービスベースのアプリケーションには、負荷分散、トラフィック管理、セキュリティを提供するサービス メッシュ フレームワークが必要です。xDS サポートを gRPC に追加することで、xDS プロトコルをサポートするすべてのコントロール プレーンが gRPC サービスと直接通信できるようになり、サービス メッシュ ポリシーに従ってサービスを提供できるようになりました。
2020 年の夏に行った最初のリリースで、gRPC クライアントは、トラフィック管理と負荷分散のポリシーを処理して実装できるようになりました。負荷分散はクライアント側で行われているため、gRPC サーバーは一切変更する必要がありません。負荷分散は、Traffic Director をコントロール プレーンとして公式にサポートしています。昨年の 2 回目のリリースでは、きめ細かいトラフィック ルーティングと、重み付けベースのトラフィック分割が可能になりました。
しかし、ネットワーク呼び出しをプロセス内呼び出しと同じくらい安全にするには、どうすればいいでしょうか。これには、TLS または mTLS を介して gRPC を使用する必要があります。そこで役立つのが、サービス メッシュのセキュリティです。gRPC の最新バージョンでは、暗号化されたサービス間通信のポリシーを構成できます。
サービス メッシュのセキュリティ
これまで、企業はその境界でウェブ アプリケーション ファイアウォール（WAF）とファイアウォールを使用して、サービス、データベース、デバイスを外部の脅威から保護してきました。時間が経過し、ワークロードがクラウドに移行され、VM とコンテナを実行してクラウド サービスを使用するようになると、セキュリティ要件も進化しました。
多層防御モデルでは、組織はアプリ全体にファイアウォールとウェブ アプリケーション ファイアウォールを使用して境界保護を維持します。今日、組織はそれに加えて、可能な限りリソースの近くで追加のセキュリティ ポリシー決定を下して実施できる「ゼロトラスト」アーキテクチャを求めています。リソースの話をするときは、すべての企業資産、つまり組織のデータセンター内のあらゆるものを指しています。
組織は現在、エッジだけでなく、信頼できるバックエンド サービス間でもポリシーを適用できる必要があります。すべての通信の暗号化を有効にするセキュリティ ルールに加えて、サービス ID とレイヤ 7 のヘッダーおよび属性に基づいてアクセスを制御するルールの適用が必要です。
本日提案するソリューションは、サービス間のセキュリティを確立するうえで最も一般的な以下のような課題を解決します。
クライアントとサーバーでの証明書の管理とインストール
信頼バンドルの管理
ID の結び付けと、信頼できる CA からの証明書の発行
証明書のローテーション
証明書を読み取って使用するためのコードの変更
gRPC プロキシレス サービスの TLS / mTLS
インフラストラクチャが、ワークロード ID と CA を提供し、それらのワークロード ID に関連付けられた証明書管理を行う世界を想像してみてください。さらに、ワークロード ライブラリは、サービス メッシュ通信でこれらの機能を利用して、サービス間 TLS / mTLS と承認を提供できます。デベロッパーと管理者がどれだけの時間を節約できるか考えてみてください。
Traffic Director を介して gRPC サービスを構成することにより、サービス間で自動化された方法で、セキュリティを確立するために必要なすべてのツールを利用できます。クライアントとサーバーのセキュリティ ポリシーを構成するだけで、Traffic Director がトラフィックをサービスに分散します。GKE ワークロード証明書サービスは適切な SPIFFE ID を生成し、マネージド プライベート認証局である Google Cloud Certificate Authority（CA）Service への CSR（証明書署名リクエスト）を作成します。CA Service は CSR に署名し、証明書を発行します。そして最後に、GKE の証明書プロバイダは、サービス間のトラフィックの暗号化と認証に使用される「証明書ボリューム」を介して、署名された証明書を gRPC アプリケーションで利用できるようにします。
まとめると、新しいセキュリティ機能を使用することで得られる利点は、以下のようになります。
メッシュ内のすべてのサービスへの鍵と証明書の手間いらずのプロビジョニング
鍵と証明書の自動ローテーションによるセキュリティ強化
デプロイ記述子やラベルなどの機能を含む GKE との統合
サービス メッシュ用の Traffic Director や CA Service などの Google マネージド サービスの高可用性
承認された Google サービス アカウントに基づくサービス承認のための、Google Identity and Access Management に関連付けられたセキュリティ
Envoy ベースのサービス メッシュとのシームレスな相互運用性。たとえば、サービスが Envoy プロキシの背後にある場合でも、クライアントは gRPC プロキシレス サービス メッシュ セキュリティを使用し、またはその逆も可能
今後の予定
次は、gRPC プロキシレス サービスのサービス間通信の承認機能を追加することでセキュリティをさらに一歩進めることや、プロキシレス gRPC サービスが Compute Engine などの GKE 以外の場所で実行されている他のデプロイモデルのサポートをご検討ください。この機会に、ぜひ設定ガイドをご覧いただき、ご意見をお寄せください。
-ネットワーク セキュリティ担当プロダクト マネージャー Megan Yahya
-プロキシレス gRPC 担当テクニカル リーダー Sanjay Pujare
