Anthos Service Mesh を使用して Google 社員のためにアプリを保護する

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

皆様こんにちは。アクセスサイト信頼性エンジニアリング（SRE）の David Challoner です。ここではデベロッパー リレーションズの Anthony Bushong と一緒に、コーポレート エンジニアリングがどのように Anthos Service Mesh を Google 社内に導入しているかご説明します。

コーポレート エンジニアリングは、Google の「エンタープライズ IT」を担当しています。コーポレート エンジニアリングの重要な任務は、法務、財務、フロアプラン、さらには社内カフェのメニューを考案するアプリといった、社内のビジネス プロセスの基盤となる、自社ソフトウェアとサードパーティ ソフトウェアを実行することです。これらのプロセスはすべて、Google 製アプリケーションと同一のセキュリティ基準と制作基準を遵守しています。   

Google 社員は、こうしたアプリケーションだけでなく、他のアプリケーションや Google Cloud サービスへのアクセスが必要になる場合があります。このトラフィックはさまざまな信頼境界を横断し、それによって異なるポリシーがトリガーされることがあります。

アクセス SRE はこのアクセスを仲介するシステムを実行し、Google は、社員がこうしたアプリケーションにアクセスする方法を保護するソリューションの一部として、Anthos Service Mesh を実装しています。

なぜでしょうか？

お分かりかもしれませんが、コーポレート エンジニアリングが担当するアプリケーションには別の要件があります。これは多くの場合、特定のアプリケーションが、法務上、業務上、技術上の事由により、別のインフラストラクチャに依存することを意味します。インフラストラクチャごとに動作や機能が異なる場合、アプリケーションの使用は容易ではありません。

そこで Anthos の出番です。Google Cloud は、このように多様な基盤インフラストラクチャ上でアプリを使用する環境を統合する、一貫したプラットフォーム インターフェースを提供するため、Kubernetes API を基盤として Anthos を構築しました。

コーポレート エンジニアリング サービスへのアクセスを仲介する一般的な認可フレームワークの構築に適したツールとして、Google は Anthos を利用することにしました。特に、オープンソース プロジェクト Istio の機能を利用している Anthos Service Mesh が適しています。サービスのデプロイ先が Google Cloud、コーポレート エンジニアリングのデータセンター、実際の Google キャンパスのエッジのどれであっても、Anthos Service Mesh は安全な接続をプログラミングするため、Google に一貫した方法を提供してきました。

ASM が社内組織に及ぼす効果を明らかにするため、この ASM を管理して使用する担当者のロールをご紹介します。

セキュリティ関係者に対しては、ASM はワークロードの ID に基づいた証明書のプロビジョニングと、きめ細かいアプリケーション対応アクセス制御の適用が可能なアプリケーションごとに実行される、拡張可能なポリシー適用ポイントを提供します。

プラットフォーム オペレーターに対しては、ASM は、すぐに使えるリリース チャネル、メンテナンスの時間枠、公開済みのサービスレベル目標（SLO）を提供することで運用上のオーバーヘッドを削減できるマネージド プロダクトとして提供されます。

サービス オーナーに対しては、ASM はネットワークの問題からアプリケーションを切り離し、一方で、レート制限、負荷制限、リクエストのトレースとモニタリングなども提供します。このような機能は通常、Kubernetes の作成に役立つ自社のクラスタ マネージャーである Borg で実行されたアプリケーションでのみ使用できます。

まとめると、運用上のオーバーヘッドを最小限に抑えて、膨大な数の多様なサービスへのアクセスを保護すると同時に、サービス オーナーにはきめ細かいトラフィック制御を提供します。

実際にどのようになっているか下図で見ていきましょう。

アーキテクチャ

このフローでは、ユーザーのアクセスは最初に Identity Aware Proxy（IAP）と Cloud Armor を使用して構成された Google Cloud グローバル ロードバランサに到達します [1]。IAP は BeyondCorp に関する Google 社内の理念の実装を一般公開したものです。BeyondCorp は、VPN を使用しなくても、信頼できないネットワークでも機能する認証レイヤを提供します。

ユーザーが認証されると、リクエストは Anthos Service Mesh から提供される Ingress Gateway に流れます [2]。これにより、リクエストが IAP を介して発生する場合のみ、トラフィックがサービスに流れるかを確認するための追加のチェックが提供されます。同時に、Anthos Service Mesh Gateway とさまざまなチームが所有するコーポレート サービスとの間に相互 TLS（mTLS）も提供されます。

最終的に、各 Service Pod で実行されるサイドカーによって追加のポリシーが適用されます [3]。ポリシーは Anthos Config Management を使用してソース管理から取得され [4]、Anthos Service Mesh が提供するマネージド コントロール プレーンによってすべてのサイドカーに反映されます [5]。

メッシュの管理

Istio の仕組みに不慣れな場合は、コントロール プレーンとデータプレーンのパターンが踏襲されます。データプレーンは、以前少しご説明したとおり、Google のすべての Service Pod とともに稼働するサイドカー コンテナで構成されています。一方コントロール プレーンは、Google が適用を希望するポリシーを使用して、サイドカーの更新を行います。

そのため、コントロール プレーンを正常に保つことが Google にとって非常に重要です。フルマネージドのコントロール プレーンに対する Anthos Service Mesh のサポートに関して、Google のプラットフォーム オーナーに多大なメリットをもたらすからです。他の多くの企業と同様、Google 社内の組織がクラウド リソースをプロビジョニングする場合には、コード プロジェクトとして一般的なオープンソース インフラストラクチャの Terraform を使用します。宣言型の使いやすい方法で、Anthos Service Mesh コントロール プレーンをプロビジョニングできます。

最初に Terraform を使用して下記の google_gke_hub_feature リソースを作成し、GKE 用のマネージド コントロール プレーン機能を有効にします。

リソースを公開する際は、Terraform の google-beta プロバイダからでないと利用できませんのでご注意ください。

リソースが作成されたら、ControlPlaneRevision カスタム リソースを GKE クラスタにプロビジョニングして、このクラスタに ASM 用のマネージド コントロール プレーンをスピンアップします。

このカスタム リソースを使用すると、ASM マネージド コントロール プレーン用にリリース チャネルを設定できます。これで、Google のプラットフォーム チームがそのニーズに対応したアップグレードのペースを定義できるようになります。

ASM はコントロール プレーンの管理に加え、データプレーンに関する管理機能も提供するので、各サイドカー Envoy は最新のセキュリティ更新が適用された状態を保ち、コントロール プレーンとの互換性も維持できます。これでサービス オペレーターの心配事が 1 つ減ります。適切なバージョンのサイドカー プロキシを挿入するように Google の Pod ワークロード定義を変更するには、Kubernetes の変更用アドミッション Webhook と Namespace ラベルを使用します。

必須のアクセス ポリシーの同期

Google のセキュリティ担当者は Anthos Service Mesh の主要コンポーネントが用意された状態で Istio API を使用して、一貫性のある必須のセキュリティ ポリシーを GKE クラスタごとに定義できます。

たとえば、あるポリシーが、自動的にプロビジョニングされる Workload Identity 証明書を使用して Pod 間に厳格な mTLS を適用しているとします。先ほど Istio Gateway 間でこれがどのように適用されるかご説明したように、同じポリシーが Google のクラスタのすべての Pod 間の mTLS に適用されます。

Google が実装するもう 1 つのポリシーは、すべての下り（外向き）トラフィックをデフォルトで拒否するものです。この実装には、サービスチームがそのアウトバウンド依存関係を明示的に宣言する必要があります。次の例では、Istio サービス エントリを使用して、特定の外部サービス（ここでは Google）へのきめ細かいアクセスを許可しています。これは外部サービスへの意図しないアクセスを防ぐうえで有効です。

これらのポリシーは Anthos Config Management を使用して、各クラスタのすべてのサービス メッシュ名前空間と自動的に同期されます。Anthos Config Management は Google 社内のソース管理システムを信頼できるソースとして使用することで、Google の GKE クラスタすべてにわたってポリシーの同期と調整が可能になり、Google のサービスごとにこれらのポリシーが確実に設定されます。Anthos Config Management に関する Google の実装について詳しくは、こちらをご覧ください。

これが行われると、Google のチームは最終的に、明示的な IP、ポート、プロトコルのポリシーに基づいて単独で動作するセキュリティの自動化からの移行に着手します。

Identity-Aware Proxy とのインテグレーション

コーポレート エンジニアリングが使用する BeyondCorp プロキシの一般公開バージョンは Identity-aware Proxy（IAP）と呼ばれ、Anthos Service Mesh とのインテグレーションを提供します。IAP を利用することで、ユーザーは Google のサービスへのアクセスが認証され、コンテキスト アウェア アクセス ポリシーを適用できるようになります。このインテグレーションには次の 2 つのメリットがあります。

• サービス メッシュでのサービスへのユーザー トラフィックを Identity-aware Proxy 経由のみにする

• Google が収集する複数のデバイス シグナルで定義されるデバイスにコンテキストアウェア アクセス（CAA）信頼レベルを適用する

次のポリシーの例は、fullyTrustedDevice アクセスレベルを必要としています。これは、会社所有で、完全に更新され、IT が承認した構成を実行していることが確認されている、組織のデバイスなどが該当します。

このポリシーによって、Google のセキュリティ チームは、サービス間通信やサービスからのアウトバウンド呼び出しを保護すると同時に、信頼できるデバイスと、信頼できるデバイスを使用する認証済みユーザーからの受信リクエストが特に必要になります。

サービスチームを有効にする

SRE としての Google の優先事項の一つは、サービスレベル指標（SLI）、SLO、サービスレベル契約（SLA）がサービスに対応して存在するかを確認することです。Anthos Service Mesh では、メッシュ内のすべてのサービスに対するレイテンシや可用性などの水平リクエスト指標を公開するため、サービス オーナーはこれを自分たちのサービスに対して実行できます。

Anthos Service Mesh を利用する前に、各アプリケーションはこれらの指標を別個にエクスポートしておく必要があります（存在する場合）。ASM を利用することで、サービス オーナーは水平にエクスポートされた指標を使用して、サービスの SLO をクラウド コンソールに、または Terraform 経由で、簡単に定義できるようになります。続いて SLO を Google のより高度なサービス定義に統合し、Google が SLO モニタリングとアラートをデフォルトで利用できるようにします。SRE ブックで SLO とエラー バジェットの詳細をご覧ください。

重要なポイント

ASM は、企業が自社の IT インフラストラクチャをモダナイズするために使用できる便利なツールです。  次の機能を提供します。

• 環境に依存しない共有適用ポイントでセキュリティ ポリシーを管理

• 統一的な方法で ID をプロビジョニングし、アプリケーションの依存関係を記述

分散トレースや段階的カナリヤ ロールアウトなど、これまでにない運用能力も実現されます。これらは、一般的な企業のアプリケーション環境ではほとんど見られないものです。  

既存の認可システムで、ギャップの解消に向けて段階的に導入、普及できるので、導入への障壁が低く、今すぐ評価を開始することをおすすめします。