Kubernetesで効果的なコンテナマイクロセグメンテーション戦略を設計および実装する方法

マイクロセグメンテーション は、大規模な実装が難しいと見なされることがよくあります。クラウドファブリック全体のすべてのワークロードの周囲にセグメント(信頼境界)を作成することが目標である場合、アーキテクチャフェーズでいくつかの要素を考慮する必要があります。ベアメタルまたは VM としてデプロイされるホストは馴染みのあるエンティティであり、その動作はネットワークとセキュリティの両方の観点からよく知られています。ただし、アーキテクチャ全体にコンテナ環境を含めると、従来のネットワークおよびセキュリティアーキテクチャでは通常重要ではないいくつかの注意事項が発生する可能性があります。

コンテナをハイブリッドクラウド全体にデプロイすると、最終的にセキュリティに関していくつかの疑問が生じます。

• すべてのコンテナワークロードにわたるマイクロセグメンテーションのデプロイと管理を自動化するにはどうすればよいですか?
• ベアメタルホストとVMホストの管理に使用される既存のセキュリティツールにコンテナセグメンテーションポリシーと自動化を含めるにはどうすればよいですか?
• コンテナ用とその他すべてのソリューション用の 2 つの異なるマイクロセグメンテーション ソリューションを管理する必要がありますか?

コンテナは、ネットワークとセキュリティの観点から奇妙な動作をする可能性があります。たとえば、Pod が突然停止し、後で自動的にスピンアップされる可能性がありますが、IP アドレスは異なります。一方、サービスはポッドの前にデプロイされ、ロードバランサーのように機能します。では、これらのエンティティのどれに対してセグメントを定義すればよいのでしょうか?名前空間はこれらのエンティティにまたがる可能性がありますが、どのようにセグメント化すればよいでしょうか?また、すべてが完全にデプロイされたときに、最終的に作成されるワークロードの数はどれくらいになりますか?

コンテナは単独で理解するのが難しいトピックであり、コンテナでマイクロセグメンテーションの「問題」を解決しようとすると、問題がさらに複雑になりやすくなります。

マイクロセグメンテーションの課題を解決して、現在のセキュリティ戦略を壊したり、アーキテクチャの進化に伴って誤って障害を生んだりすることなく、既存の環境にコンテナを導入できるようにするにはどうすればよいでしょうか?

幸いなことに、これは解決可能な問題 です 。説明しましょう。

既存のマイクロセグメンテーション戦略にコンテナを追加する際の考慮事項

コンテナとマイクロセグメンテーションに関する会話を始めるのに適した場所は、スケールに対処することです。ハイブリッドクラウド全体のすべてのワークロードのセグメンテーション戦略を設計する場合、スケーリングは常に重要な注意点です。全体的な環境はどの程度大きくなりますか?

一般的に、この質問に対する答えは、ベアメタルと VM のすべてのホストを合計し、予想される将来の成長に対応するために、その数を 2 倍または 3 倍にすることです。一部のアプリケーションはホストまたは VM のクラスターで実行されるため、この数値は少しあいまいになります。1 つのホストが必ずしも 1 つのワークロードに等しいとは限りません。しかし、ワークロードをホストと同一視することは、スケーリング数を推定するための有用なベンチマークです。その最終的な合計数は、特定のマイクロセグメンテーションベンダーがサポートできるマネージドワークロードの上限と比較されます。

ベアメタルホストは頻繁に移行しないため、セグメントを定義するための非常に静的なエンティティです。一方、VM は少し予測できない場合があります。たとえば、動的にスピンアップおよびスピンダウンしたり、ネットワークセグメント間で移行したり、ライフサイクル全体で複数のIPアドレスを割り当てたりすることができます。そのため、ホストの総数は少し流動的になります。とはいえ、通常、管理およびセグメント化する必要があるワークロードの総数に達するために、クラウドでアクティブになると予想される VM の数を見積もることができます。多くの場合、この最終的な数は数百、場合によっては数千未満になります。  

したがって、さまざまなマイクロセグメンテーションベンダーがサポートできるスケールの上限を考慮すると、これらの最大数は「十分」に思えることがよくあります。たとえば、クラウドで現在 1,000 のワークロードが実行されており、この数が今後数年間で 2 倍、場合によっては 3 倍になる可能性がある場合、特定のベンダーのマネージド ワークロードの上限である 20,000 にすぐに到達する心配はほとんどありません。大きな数字は遠い懸念事項と見なされています。

しかし、画像にコンテナを追加するとどうなるでしょうか?コンテナ化されたワークロードは、VMおよびベア・メタル・ホストとは異なる動作をするコンピュート・インスタンスです。

たとえば、Kubernetes は、コンテナを実行している基盤となるホスト (VM またはベアメタル) を「ノード」と呼びます。各ノードで 1 つ以上の「ポッド」が作成され、実際のコンテナランタイムインスタンスが実行されているのは各ポッド内です。Kubernetes では、特定のノードに最大 110 個のポッドをデプロイすることを推奨しています。

したがって、クラウドにKubernetesを実行しているノードが100個あり、各ノードが110個のポッドを実行している場合、何らかの方法で個別のセグメントとして定義する必要がある11,000個のコンピュート・インスタンスが発生する可能性があります。200 ノードがある場合、22,000 個のコンピュート・インスタンスを作成できます。繰り返しになりますが、コンテナ環境内のノードは 200 個だけで、22,000 のワークロード セグメントが発生する可能性があります。

そして、これはコンテナ環境にすぎません。マネージド ワークロードと可能なセグメントの予想される数を見積もるには、ハイブリッド クラウド全体にわたってコンテナー化されていないすべてのワークロードを追加する必要があります。学んだ教訓は、さまざまなマイクロセグメンテーションベンダーがサポートできるマネージドワークロードの最大数が、もはや達成不可能ではないように思えるということです。

コンテナと非コンテナの両方に対応する1つのソリューション

コンテナ環境をセグメント化する方法を検討する場合、Kubernetes または OpenShift のクラスター内およびクラスター間でマイクロセグメンテーションを可能にするベンダーがいくつかあります。ただし、これらのソリューションのほとんどは、ハイブリッドクラウド全体のコンテナ化されていないワークロードではなく、特にコンテナ環境に焦点を当てています。そして現実には、コンテナワークロードを持つほとんどのネットワークには、コンテナ化されていないワークロード、ベアメタルと VM もあり、すべて同じクラウド ファブリックに共存しています。

コンテナー用に 1 つのセグメンテーション ソリューションをデプロイし、ベアメタルと VM 用に別のセグメンテーション ソリューションをデプロイすることを選択した場合、その結果、2 つの異なるツールセットが作成され、それらの間のイベントが自動化または関連付けられません。このアプローチは小規模では機能する可能性がありますが、デプロイが拡大するにつれて運用と管理が困難になります。ワークロードのセグメント化に対するこのサイロ化されたアプローチは避ける必要があります。コンテナ化されたワークロードは、すべての ワークロード セグメンテーションをデプロイおよび管理するための統合ソリューションを作成するために、コンピューティング ファブリック全体で同じ方法で管理する必要があります。

たとえば、Illumioは、ベアメタルからVM、コンテナに至るまで、すべてのワークロードで動作します。コンテナ化されたワークロードとコンテナ化されていないワークロードの間に機能の違いがないため、すべてのワークロードの視覚化、自動化、ポリシー管理によるマイクロセグメンテーションが可能になります。

名前空間、ポッド、またはサービス?

Kubernetesは、エグレスおよびイングレスネットワークトラフィックを制御できる3つの主要なコンテナエンティティ(ポッド、サービス、または名前空間)を定義します。(注: ノードはこれらのエンティティ間の宛先とは見なされず、クラスターはノードのコレクションの周囲の最も広い境界として定義されます)。さらに、多くの場合、クラスター境界にロード バランサーがデプロイされるため、セグメント化できるエンティティが 4 つ存在します。マイクロセグメンテーションアーキテクチャを定義する場合、これらのエンティティのうちどれをセグメントとして分類する必要がありますか?それらの一部またはすべて?

ポッドは、Kubernetes によって IP アドレスを割り当てることができる最小のエンティティです。コンテナランタイムインスタンスは 1 つ以上のポッドで実行され、多くの場合、これらのポッドは相互に通信する必要があります。各ポッドはセグメントとして定義できますが、課題は、Kubernetesがポッドをスピンダウンし、後でスピンアップできることであり、これはネットワークの観点から、宛先または送信元のIPアドレスが突然消えることを意味することを意味します。ネットワークチームとセキュリティチームは、ファブリック全体でエンティティが突然消え、ルートコンバージェンスツールやセキュリティツールへの対処が困難になることを好まない。

Kubernetesは、指定された数のポッドの前にデプロイされるサービスをデプロイでき、その背後にあるポッドのロードバランサーのように機能します。サービスははるかに安定しており、Kubernetes はポッドを動的にスピンアップおよびスピンダウンできますが、サービスではそれが行われることはめったにありません。したがって、サービスを個々の Pod ではなくセグメントとして定義することがベストプラクティスです。

マイクロセグメンテーションベンダーに、ポッドまたはサービスのいずれかをセグメントとして定義できるかどうかを問い合わせ、セキュリティ管理者に選択を任せることが重要です。

コンテナーにデプロイされたアプリケーションは、通常、名前空間としてデプロイされ、コードは基本的に 1 つ以上のポッド内で分散方式で実行されます。コンテナー名前空間は、複数のポッドとサービスにわたる抽象化です。

たとえば、Illumioでは、名前空間に対して「プロファイル」を定義し、このプロファイルをセグメントとして定義できます。その結果、Illumioは、ポッド、サービス、または名前空間のいずれかに対してセグメントの定義を可能にします。また、コンテナ化された環境専用に設計されたマイクロセグメンテーションツールとは異なり、Illumioは、基盤となるホスト、クラスター境界のイングレス/エグレスポイント、およびコンテナ内のリソースにアクセスする必要がある周囲のレガシーワークロードに対してセグメントを定義することもできます。セグメントはコンテナ内だけでなく、クラウドファブリック全体に存在します。

このため、マイクロセグメンテーションベンダーが100,000を超えるワークロードを管理できるようにする必要があります。クラウド ファブリックにデプロイされるコンテナ環境が多ければ多いほど、これらの高い数値に焦点が当てられるのが早くなります。そして、これらの数値は、コンテナ内では一時的なものであることが多く、ワークロードが動的に生き返ったり消えたりするワークロードで構成されています。つまり、マイクロセグメンテーションソリューションは変化にリアルタイムで対応する必要があります。

コンテナクラスターにデプロイされたイルミオのKubelinkインスタンスを使用することで、デプロイおよび廃止されたワークロードを動的に検出し、 アプリケーションの依存関係マップを有効にし、管理されているワークロードのすべての変更にリアルタイムで対応するツールを適用できます。自動化とオーケストレーションはコンテナの2つの重要な概念であり、イルミオはコンテナ環境の内外でマイクロセグメンテーション管理を運用できるように両方を実装しています。

クラウドにコンテナをデプロイするということは、デプロイ方法に関係なく、ワークロードに関するセグメントを定義する機能を犠牲にすることを意味するものではありません。セグメンテーションソリューションが、障害を発生させることなく、コンテナ化されたワークロードが可能にするのと同じ高い数まで拡張し続けるようにしてください。Illumio Coreを使用すると、規模に関係なく、クラウドファブリック全体のすべてのワークロードに対して ゼロトラスト に到達できます。

もっと欲しいですか?Illumio CoreがKubernetesとOpenShiftをどのように保護できるかをご覧ください。

Illumio Zero Trust Segmentationでコンテナを保護する方法については、今すぐお問い合わせください。