コンテンツに移動
セキュリティ & アイデンティティ

GKE、Traffic Director、CA サービスによるゼロトラスト ワークロード セキュリティ

2021年11月15日
https://storage.googleapis.com/gweb-cloudblog-publish/images/security_BXcinb9.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2021 年 11 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

ゼロトラスト アプローチの核心は、複数のメカニズムによって信頼を確立し、継続的に検証する必要があるという考え方です。Google はこの考え方を、クラウドネイティブ インフラストラクチャ上で本番環境システムを稼働させ、ワークロードを保護するエンドツーエンドのプロセスに応用し、社内で BeyondProd と呼んでいます。このようなシステムの信頼性を確立し、検証するには、1)各ワークロードが固有の Workload Identity と認証用の認証情報を持つこと、2)システムのどのコンポーネントが他のコンポーネントと通信できるかを決定する認証レイヤが必要です。

アプリがマイクロサービスに分割されているクラウドネイティブ アーキテクチャを考えてみましょう。プロセス内のプロシージャ コールやデータ移転は、マイクロサービス間のネットワークを介したリモート プロシージャ コール(RPC)になります。このシナリオでは、サービス メッシュがマイクロサービス間の通信を管理しており、ゼロトラスト アプローチを実現する重要なコントロールを埋め込むのに適した場所です。RPC を確保することは非常に重要です。各マイクロサービスは、認証された承認済みの送信者からのみ RPC を受信し、意図した受信者にのみ RPC を送信し、送信中に RPC が変更されないことを保証する必要があります。したがって、サービス メッシュは、サービス ID、それらのサービス ID に基づくピア認証、認証されたピア ID 間の通信の暗号化、およびサービス ID(およびその他の属性)に基づくサービス間通信の承認を提供する必要があります。

これらの要件を満たすマネージド サービス メッシュのセキュリティを提供するために、Google は新しいセキュリティを Traffic Director に一般提供することを発表します。Traffic Director は CA サービスを介して Google Kubernetes Engine(GKE)のワークロードの認証情報を完全に管理し、ワークロードの通信を管理するポリシー適用を提供します。フルマネージド認証情報は  ワークロードの ID を表現し、  相互 TLS(mTLS)を活用してワークロード間の接続を保護するための基盤となるもので、ゼロトラスト原則に従っています。

現状では、サービス間のセキュリティに mTLS を使用することは、開発者、SRE、デプロイメント チームにとって、かなりの労力とオーバーヘッドを必要とします。デベロッパーは、事前に構成された場所から証明書や鍵を読み込み、サービス間の接続で使用するためのコードを記述する必要があります。また、通常、これらの接続に対して、フレームワークやアプリケーション ベースの追加のセキュリティ チェックを行う必要があります。さらに、SRE やデプロイ チームは、鍵や証明書を必要とするすべてのノードに配備し、その有効期限を追跡しなければならないという複雑さがあります。これらの証明書の交換やローテーションには、CSR(証明書署名リクエスト)の作成、発行 CA による署名の取得、署名された証明書のインストール、適切なルート証明書の相手先へのインストールなどが必要です。ID やルート証明書の有効期限が切れると、サービスが長時間停止する可能性があるため、ローテーションのプロセスは非常に重要です。

RPC のルーティングはトラフィック コントロール プレーンによって編成されているため、このセキュリティ ロジックをハードコードできません。また、マイクロサービスが複数のデプロイ用インフラストラクチャにまたがるように拡張されているため、アプリケーション コードが ID を検証し、それに基づいて認可の決定を行うことは困難です。

Google のソリューションは、認証局のインフラストラクチャ、コンピューティングとデプロイ用インフラストラクチャ、サービス メッシュのインフラストラクチャをシームレスにインテグレーションすることで、これらの課題を解決します。当社の実装では、Certificate Authority Service (CAS)がサービス メッシュ用の証明書を提供し、GKE インフラストラクチャが CAS と統合され、Traffic Director のコントロール プレーンが GKE と統合され、データ プレーン エンティティがピアとの mTLS 接続を作成する際にこれらの証明書(および鍵)を使用するように指示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/traffic_director_UVuLeBO.max-2000x2000.jpg

GKE クラスタのメッシュ証明書コンポーネントは、CA プールと継続的に通信してサービス ID 証明書を作成し、GKE ポッドで実行されるワークロードがこの証明書を利用できるようにします。発行した認証局は自動的に更新され、期限が切れる前に新しいルートがクライアントに push されます。Traffic Director は、データ プレーン エンティティにポリシー、構成、インテリジェンスを提供し、クライアントとサーバー アプリケーションに構成を提供するサービス メッシュ コントロール プレーンです。これらの構成には、必要なトランスポート レベルとアプリケーション レベルのセキュリティ情報が含まれており、消費側のサービスが mTLS 接続を作成し、その接続を介して流れる RPC に適切な認可ポリシーを適用できます。最後に、ワークロードはセキュリティ構成を利用して、適切な mTLS 接続を作成し、提供されたセキュリティ ポリシーを適用します。

詳しくは、Traffic Director のユーザーガイドをご覧ください。Traffic Director のセットアップ方法、それに付随するサービスをお客様の環境で設定する方法、GKE ワークロードのセキュリティをゼロトラスト アプローチで確保する方法を紹介しています。

-ゼロトラスト、プロダクト マネージャー、Anoosh Saboori

-プロキシレス gRPC 担当テクニカル リーダー、Sanjay Pujare

投稿先