アンビエントモードのセキュリティ詳細

先日、Istio の新しいアンビエントモードを発表しました。これは Istio のサイドカーレスデータプレーンであり、アンビエントメッシュパターンのリファレンス実装です。発表ブログで述べられているように、アンビエントメッシュで対処する主な懸念事項は、運用の簡素化、より広範なアプリケーション互換性、インフラストラクチャコストの削減、およびパフォーマンスの向上です。アンビエントデータプレーンの設計にあたり、セキュリティや機能を犠牲にすることなく、運用、コスト、パフォーマンスに関する懸念事項のバランスを慎重に取りたいと考えました。アンビエントメッシュのコンポーネントはアプリケーションポッドの外部で実行されるため、セキュリティ境界が変更されました。私たちは、これが改善につながると考えています。このブログでは、これらの変更点と、サイドカーデプロイとの比較について詳しく説明します。

おさらいすると、Istio のアンビエントモードは、トランスポートセキュリティとルーティングを担当するセキュアオーバーレイを備えたレイヤー構造のメッシュデータプレーンを導入します。このオーバーレイには、必要に応じて L7 機能を追加するオプションがあります。詳細については、発表ブログと入門ブログをご覧ください。セキュアオーバーレイは、ノード共有コンポーネントである ztunnel で構成されており、これは DaemonSet としてデプロイされる L4 テレメトリと mTLS を担当します。メッシュの L7 レイヤーは、ID/ワークロードタイプごとにデプロイされる完全な L7 Envoy プロキシであるウェイポイントプロキシによって提供されます。この設計の主な影響には、次のものがあります。

• アプリケーションとデータプレーンの分離
• セキュアオーバーレイレイヤーのコンポーネントは CNI のそれに似ています
• 運用の簡素化はセキュリティ向上につながります
• マルチテナント L7 プロキシの回避
• サイドカーは引き続き第一級のサポート対象のデプロイです

アプリケーションとデータプレーンの分離

アンビエントメッシュの主な目的はサービスメッシュの運用を簡素化することですが、セキュリティの向上にも役立ちます。複雑さは脆弱性を生み出し、エンタープライズアプリケーション（およびその推移的な依存関係、ライブラリ、フレームワーク）は非常に複雑で脆弱になりがちです。複雑なビジネスロジックの処理から、OSS ライブラリやバグのある内部共有ライブラリの活用まで、ユーザーのアプリケーションコードは攻撃者（内部または外部）にとって格好の標的です。アプリケーションが侵害された場合、認証情報、シークレット、キー（メモリにマウントまたは保存されたものを含む）が攻撃者に公開されます。サイドカーモデルを見ると、アプリケーションの侵害にはサイドカーの乗っ取りと、関連する ID/キーマテリアルの乗っ取りが含まれます。Istio のアンビエントモードでは、データプレーンコンポーネントはアプリケーションと同じポッドで実行されないため、アプリケーションの侵害によってシークレットにアクセスできるようになることはありません。

Envoy Proxy は脆弱性の潜在的な標的になりうるのか？Envoy は非常に強固なインフラストラクチャであり、厳重な監視下におかれ、重要な環境で大規模に実行されています（たとえば、Google のネットワークの前面で使用される本番環境）。ただし、Envoy はソフトウェアであるため、脆弱性の影響を受けないわけではありません。これらの脆弱性が発生した場合、Envoy には、それらを特定し、迅速に修正し、幅広い影響が出る前に顧客に展開するための堅牢な CVE プロセスがあります。

「複雑さは脆弱性を生み出す」という以前のコメントに戻ると、Envoy Proxy の最も複雑な部分は L7 処理にあり、実際、歴史的に Envoy の脆弱性の大部分は L7 処理スタックにありました。しかし、Istio を mTLS のみに使用する場合はどうでしょうか。その機能を使用しない場合に、CVE の可能性が高い完全な L7 プロキシを展開するリスクを負う必要があるのでしょうか？ここで、L4 と L7 のメッシュ機能を分離することが重要になります。サイドカーデプロイでは、機能の一部しか使用しない場合でも、すべてのプロキシを採用しますが、アンビエントモードでは、セキュアオーバーレイを提供し、必要に応じて L7 をレイヤー化することで露出を制限できます。さらに、L7 コンポーネントはアプリケーションとは完全に分離して実行され、攻撃の侵入口にはなりません。

L4 を CNI に押し込む

アンビエントモードデータプレーンの L4 コンポーネントは DaemonSet として、またはノードごとに 1 つとして実行されます。これは、特定のノードで実行されているすべてのポッドに対して共有されるインフラストラクチャであることを意味します。このコンポーネントは特に機密性が高く、CNI エージェント、kube-proxy、kubelet、さらには Linux カーネルなど、ノード上の他の共有コンポーネントと同じレベルで扱う必要があります。ワークロードからのトラフィックは ztunnel にリダイレクトされます。ztunnel はワークロードを識別し、mTLS 接続でそのワークロードを表すための適切な証明書を選択します。

ztunnel は、ポッドが現在ノードで実行されている場合にのみ発行される、ポッドごとに異なる認証情報を使用します。これにより、侵害された ztunnel の影響範囲は、そのノードで現在スケジュールされているポッドの認証情報のみが盗まれる可能性があることが保証されます。これは、他の安全に実装された共有ノードインフラストラクチャ（他の安全な CNI 実装を含む）と同様の特性です。ztunnel はクラスター全体またはノードごとの認証情報を使用しません。それらが盗まれた場合、複雑な二次認証メカニズムも実装しない限り、クラスター内のすべてのアプリケーショントラフィックがすぐに侵害される可能性があります。

これをサイドカーモデルと比較すると、ztunnel が共有されており、侵害によってノードで実行されているアプリケーションの ID が漏えいする可能性があることがわかります。ただし、このコンポーネントでの CVE の可能性は、攻撃対象領域が大幅に縮小されているため（L4 処理のみ）、Istio サイドカーよりも低くなります。ztunnel は L7 処理を行いません。さらに、（L7 による攻撃対象領域が大きい）サイドカーの CVE は、侵害された特定のワークロードにだけ限定されるわけではありません。サイドカーの深刻な CVE は、メッシュ内の他のワークロードにも繰り返される可能性が高いです。

運用の簡素化はセキュリティ向上につながります

最終的に、Istio は維持管理する必要がある重要なインフラストラクチャです。Istio は、アプリケーションに代わってゼロトラストネットワークセキュリティの原則の一部を実装するように信頼されており、スケジュールまたはオンデマンドでパッチをロールアウトすることが最も重要です。プラットフォームチームには、アプリケーションとは大きく異なる、予測可能なパッチ適用またはメンテナンスサイクルがあることがよくあります。アプリケーションは、通常、新しい機能や機能が必要になった場合、および通常はプロジェクトの一部として更新されます。アプリケーションの変更、アップグレード、フレームワーク、およびライブラリのパッチに対するこのアプローチは、非常に予測不可能であり、多くの時間が経過し、安全なセキュリティプラクティスには適していません。したがって、これらのセキュリティ機能をプラットフォームの一部としてアプリケーションから分離しておくことで、セキュリティ体制が向上する可能性があります。

発表ブログで特定したように、サイドカーの運用は、その侵襲的な性質（サイドカーの注入/デプロイメント記述子の変更、アプリケーションの再起動、コンテナ間の競合状態など）のために、より複雑になる可能性があります。サイドカーを使用したワークロードのアップグレードには、アプリケーションをダウンさせないために調整する必要がある、より多くの計画とローリング再起動が必要です。アンビエントモードでは、ztunnel のアップグレードは通常のノードパッチ適用またはアップグレードと同時に行うことができ、ウェイポイントプロキシはネットワークの一部であるため、必要に応じてアプリケーションに対して完全に透過的にアップグレードできます。

マルチテナント L7 プロキシの回避

HTTP 1/2/3、gRPC などの L7 プロトコルのサポート、ヘッダーの解析、リトライの実装、データプレーンでの Wasm および/または Lua によるカスタマイズは、L4 のサポートよりも大幅に複雑です。これらの動作を実装するためのコード（Lua や Wasm などのユーザーカスタムコードを含む）が大幅に増え、この複雑さによって脆弱性が生じる可能性があります。このため、L7 機能のこれらの領域では、CVE が発見される可能性が高くなります。

アンビエントモードでは、複数の ID 間でプロキシの L7 処理を共有することはありません。各 ID（Kubernetes のサービスアカウント）には、サイドカーで使用するモデルと非常によく似た、独自の専用 L7 プロキシ（ウェイポイントプロキシ）があります。複数の ID とそれらの異なる複雑なポリシーとカスタマイズを併置しようとすると、共有リソースに多くの変動が加わり、最悪の場合にはコストの不公平な帰属、またはプロキシの完全な侵害につながります。

サイドカーは引き続き第一級のサポート対象のデプロイです

一部のユーザーは、サイドカーモデルとその既知のセキュリティ境界に慣れており、そのモデルを維持したいと考えていることを理解しています。Istio では、サイドカーはメッシュへの第一級の市民であり、プラットフォームの所有者は引き続き使用するかどうかを選択できます。プラットフォームの所有者がサイドカーモードとアンビエントモードの両方をサポートしたい場合は、両方をサポートできます。アンビエントデータプレーンを使用するワークロードは、サイドカーがデプロイされたワークロードとネイティブに通信できます。アンビエントモードのセキュリティ体制をよりよく理解すれば、サイドカーが特定の最適化に使用され、アンビエントモードが Istio の推奨データプレーンモードになると確信しています。