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

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

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

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

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

コンテナは、それ自体では理解するのが難しいトピックであり、コンテナを使ってマイクロセグメンテーションの「問題」を解決しようとすると、問題がさらに複雑になりがちです。

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

幸いなことに、これ です 解決可能な問題です。説明させてください。

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

コンテナとマイクロセグメンテーションについての会話を始めるのに適した場所は、スケールについて説明することです。ハイブリッドクラウド全体にわたるすべてのワークロードを対象とするセグメンテーション戦略を設計する場合、スケーリングは常に重要な注意点です。環境全体の規模はどの程度拡大するのでしょうか。

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

ベアメタルホストは頻繁に移行しないため、セグメントを定義するにはかなり静的なエンティティです。一方、VM は少し予測がつかない場合があります。たとえば、ライフサイクル全体にわたって動的に起動/停止させたり、ネットワークセグメント間で移行したり、複数の IP アドレスを割り当てたりすることができます。そのため、ホストの総数は少し流動的になります。とはいえ、管理やセグメント化が必要なワークロードの総数に達するまでに、クラウドでアクティブになると予想される仮想マシンの数は通常予測できます。多くの場合、この最終的な数は数百または数千にのぼります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

もっと欲しい？方法を読む イルミオ・コアはKubernetesとOpenShiftを保護できる。

今すぐお問い合わせ イルミオゼロトラストセグメンテーションでコンテナを保護する方法を学びましょう。