Istioにおける下り（Egress）トラフィックの安全な制御 パート3

パフォーマンスに関する考慮事項を含む、下りトラフィックを制御するための代替ソリューションの比較。

2019年7月22日 | Vadim Eisenberg - IBM

Istioにおける下りトラフィックの安全な制御に関するシリーズのパート3へようこそ。 シリーズの第1部では、下りトラフィックに関連する攻撃と、下りトラフィックの安全な制御システムに求められる要件について説明しました。 シリーズの第2部では、Istioによる下りトラフィックの保護方法と、Istioを使用して攻撃を防ぐ方法を紹介しました。

このパートでは、Istioにおける下りトラフィックの安全な制御を、Kubernetesネットワークポリシーや従来の下りプロキシとファイアウォールなどの代替ソリューションと比較します。最後に、Istioにおける下りトラフィックの安全な制御に関するパフォーマンスの考慮事項について説明します。

下りトラフィック制御の代替ソリューション

最初に、以前にまとめた下りトラフィック制御の要件を思い出してみましょう。

  1. TLSとSNI、またはTLSオリジネーションのサポート。
  2. すべての下りアクセスについて、SNIと送信元ワークロードを監視する。
  3. クラスタごとにポリシーを定義し、適用する。
  4. 送信元ごとに、Kubernetesを認識したポリシーを定義し、適用する。
  5. 改ざんを防止する.
  6. トラフィック制御はアプリケーションに対して透過的である。

次に、下りトラフィック制御の2つの代替ソリューション、Kubernetesネットワークポリシーと下りプロキシとファイアウォールについて説明します。これらのソリューションが満たす要件と、さらに重要なこととして、満たすことができない要件を示します。

Kubernetesは、ネットワークポリシーを通じて、トラフィック制御、特に下りトラフィックの制御のためのネイティブソリューションを提供しています。これらのネットワークポリシーを使用することで、クラスタオペレーターは、どのPodが特定の外部サービスにアクセスできるかを設定できます。クラスタオペレーターは、Podラベル、名前空間ラベル、またはIP範囲によってPodを識別できます。外部サービスを指定するために、クラスタオペレーターはIP範囲を使用できますが、`cnn.com`のようなドメイン名を使用することはできません。これは、KubernetesネットワークポリシーがDNSを認識しないためです。ネットワークポリシーは、TCPトラフィックを制御できるため、最初の要件を満たしています。ネットワークポリシーは、クラスタオペレーターがクラスタごとまたはPodごとにポリシーを指定できますが、オペレーターはドメイン名で外部サービスを識別できないため、3番目と4番目の要件を部分的にしか満たしていません。ネットワークポリシーは、攻撃者が悪意のあるコンテナからKubernetesノードに侵入して、ノード内のポリシーの実装に干渉できない場合にのみ、5番目の要件を満たします。最後に、ネットワークポリシーは6番目の要件を満たしています。オペレーターはコードやコンテナ環境を変更する必要はありません。まとめると、Kubernetesネットワークポリシーは、DNSを認識しない、透過的でKubernetesを認識した下りトラフィック制御を提供すると言えます。

2番目の代替案は、Kubernetesネットワークポリシーよりも前から存在します。 **DNSを認識する下りプロキシまたはファイアウォール**を使用すると、アプリケーションがプロキシにトラフィックを転送し、SOCKSなどのプロキシプロトコルを使用するように設定できます。オペレーターはアプリケーションを設定する必要があるため、このソリューションは透過的ではありません。さらに、下りプロキシはPodラベルやPodサービスアカウントを認識しないため、オペレーターはそれらを使用してプロキシを設定できません。したがって、下りプロキシはKubernetesを認識しません。また、Kubernetesアーティファクトが送信元を指定する場合、下りプロキシは送信元ごとにポリシーを適用できないため、4番目の要件を満たすことができません。まとめると、下りプロキシは1番目、2番目、3番目、5番目の要件を満たすことができますが、透過的ではなく、Kubernetesを認識しないため、4番目と6番目の要件を満たすことができません。

Istio下りトラフィック制御の利点

Istio下りトラフィック制御はDNSを認識しています。`*.ibm.com`のようなURLまたはワイルドカードドメインに基づいてポリシーを定義できます。この点で、DNSを認識しないKubernetesネットワークポリシーよりも優れています。

Istio下りトラフィック制御は、TLSトラフィックに関して透過的です。Istioは透過的であるため、アプリケーションを変更したり、コンテナを設定したりする必要はありません。TLSオリジネーションを使用したHTTPトラフィックの場合、メッシュ内のアプリケーションがHTTPSではなくHTTPを使用するように設定する必要があります。

Istio下りトラフィック制御はKubernetesを認識しています。下りトラフィックの送信元のIDは、Kubernetesサービスアカウントに基づいています。Istio下りトラフィック制御は、透過的ではなく、Kubernetesを認識しない従来のDNS対応プロキシまたはファイアウォールよりも優れています。

Istio下りトラフィック制御は安全です。Istioの強力なIDに基づいており、追加のセキュリティ対策を適用すると、Istioのトラフィック制御は改ざんに対して耐性があります。

さらに、Istioの下りトラフィック制御には、次の利点があります。

上記の利点を持つシステムを**Istio対応**と呼びます。

次の表は、Istioと代替ソリューションが提供する下りトラフィック制御機能をまとめたものです。

Istio下りトラフィック制御Kubernetesネットワークポリシー従来の下りプロキシまたはファイアウォール
DNS対応
Kubernetes対応
透過的
Istio対応

パフォーマンスに関する考慮事項

Istioを使用して下りトラフィックを制御するには、外部サービスへの呼び出しのレイテンシの増加と、クラスタのPodによるCPU使用率の増加という代償が伴います。トラフィックは2つのプロキシを通過します。

ワイルドカードドメインへのTLS下りトラフィックを使用する場合、アプリケーションと外部サービスの間に追加のプロキシを追加する必要があります。下りゲートウェイのプロキシと、ワイルドカードを使用した任意のドメインの構成に必要なプロキシ間のトラフィックは、Podのローカルネットワーク上にあるため、そのトラフィックはレイテンシに大きな影響を与えるべきではありません。

下りトラフィックを制御するために設定されたさまざまなIstio構成のパフォーマンス評価をご覧ください。ユースケースでパフォーマンスオーバーヘッドを許容できるかどうかを決定する前に、独自のアプリケーションと独自の外部サービスを使用して、さまざまな構成を慎重に測定することをお勧めします。必要なセキュリティレベルとパフォーマンス要件を比較検討し、すべての代替ソリューションのパフォーマンスオーバーヘッドを比較する必要があります。

Istioを使用して下りトラフィックを制御することで追加されるパフォーマンスオーバーヘッドに関する私の考えを共有させてください。外部サービスへのアクセスにはすでに高いレイテンシが発生する可能性があり、クラスタ内に2つまたは3つのプロキシがあるために追加されるオーバーヘッドは、比較するとそれほど重要ではない可能性があります。結局のところ、マイクロサービスアーキテクチャを持つアプリケーションは、マイクロサービス間で数十の呼び出しチェーンを持つことができます。したがって、下りゲートウェイに1つまたは2つのプロキシがある追加ホップは、大きな影響を与えるべきではありません。

さらに、Istioのパフォーマンスオーバーヘッドを削減するために、引き続き取り組んでいます。考えられる最適化には、次のものがあります。

まとめ

このシリーズを読んだ後、クラスタのセキュリティにとって下りトラフィックの制御が非常に重要であることを確信していただければ幸いです。また、Istioが下りトラフィックを安全に制御するための効果的なツールであり、Istioが代替ソリューションよりも多くの利点を持っていることを納得していただければ幸いです。Istioは、私が知っている限り、次のことができる唯一のソリューションです。

私の意見では、最初のIstioユースケースを探している場合、下りトラフィックの安全な制御は最適な選択肢です。この場合、クラスタ内のマイクロサービス間のトラフィックに適用される、他のすべてのIstio機能（トラフィック管理、セキュリティ、ポリシー、可観測性）を使用し始める前でも、Istioはすでにいくつかの利点をもたらします。

Istioをまだ使ったことがない場合は、クラスタにIstioをインストールし、下りトラフィック制御タスクと他のIstio機能のタスクを確認してください。また、皆様のご意見をお待ちしております。 discuss.istio.ioにご参加ください。

この記事を共有する