Antrea Kubernetes クラスタと NSX ネットワーク内の仮想マシン間のトラフィックを保護するためのファイアウォール ポリシー

動的メンバーシップ基準に Kubernetes メンバー タイプの汎用グループを作成して、Antrea Kubernetes クラスタに出入りするトラフィックと一致させることができます。

さらに、これらの汎用グループを分散ファイアウォール ルールまたはゲートウェイ ファイアウォール ルールで使用して、NSX 環境の仮想マシンと Antrea Kubernetes クラスタ内のポッド間のトラフィックを保護できます。

重要： マルチテナント NSX 環境では、Kubernetes クラスタ リソースがプロジェクト インベントリに公開されません。したがって、プロジェクト内で、動的メンバーシップ基準に Kubernetes メンバー タイプを含む汎用グループを作成することはできません。 NSX の [デフォルト] ビュー（デフォルト領域）にグループを作成して、デフォルト領域の分散ファイアウォール ルールまたはゲートウェイ ファイアウォール ルールで使用する必要があります。

前提条件

• Antrea Kubernetes クラスタが NSX に登録されている。
• 分散ファイアウォール セキュリティ ポリシーを構成する資格をシステムに付与する適切なセキュリティ ライセンスを NSX 環境に適用します。

Antrea Kubernetes クラスタから NSX 内の仮想マシンへのトラフィックの保護

Antrea Kubernetes クラスタから NSX へのトラフィックと一致させるために、ファイアウォール ルールで次の Kubernetes メンバー タイプ（リソース）に基づいて汎用グループを追加できます。

• Kubernetes ノード
• Antrea Egress
• Antrea IP プール

次の図は、Antrea Kubernetes クラスタから NSX 論理ネットワーク内の仮想マシンへの一般的なトラフィック フローを示しています。

このトラフィック フロー図のように、Antrea Kubernetes クラスタから送信されるトラフィックと一致させる場合、次のシナリオが考えられます。

シナリオ 1：Egress（ゲートウェイ ノード）を介した SNAT

Antrea Kubernetes クラスタに Egress リソースを展開できます。Egress リソースのマニフェスト ファイルで、Egress リソースが適用されるポッドのグループ化基準を選択します。マニフェスト ファイルで Egress IP を手動で指定することも、Antrea CNI が ExternalIPPool カスタム リソースから Egress IP を割り当てるようにすることもできます。

重要： Egress IP アドレスは、物理ネットワーク上でルーティング可能で、K8s クラスタ内のすべてのノードからアクセスできる必要があります。

Antrea CNI は、選択したポッドからゲートウェイ ノードに送信トラフィックを送信します。ゲートウェイ ノードは送信元アドレス変換 (SNAT) を実行して、送信元 IP (ポッド IP) を Egress IP に変換します。

たとえば、前述のトラフィック フロー図では、node1 で実行されている pod1 と pod2 からの送信トラフィックがゲートウェイ ノードに送信されます。ゲートウェイ ノードは、ポッドの IP アドレスを egress1 IP に変換します。

Egress リソースの詳細については、Antrea ドキュメント ポータルにあるEgress Guideを参照してください。

ゲートウェイ ノードとして使用できるクラスタ ノードは、物理ネットワーク管理者または IaaS ネットワーク管理者によって制御されるノード ネットワーク トポロジによって異なります。ゲートウェイ ノードには次の 2 つの特性があります。

• 物理ネットワークでは、ノードは、外部ネットワークにアクセスするための送信元 IP としてルーティング可能な IP を持つことができます。
• 必要に応じて、物理ゲートウェイ上の物理ファイアウォールは、ゲートウェイ ノードからの送信トラフィックをフィルタリングするように構成されます。

次の例について考えてみましょう。

• 例 1：Antrea Kubernetes クラスタに node1、node2、node3 の 3 つのノードがあります。クラスタ内の node1 と node2 はクラスタ内で特別なノードとなります。これらのノードは、2 つのネットワーク インターフェイスが割り当てられています。1 つのインターフェイスは K8s クラスタとの通信用に、もう 1 つは外部ネットワークに接続するためのインターフェイスとして設定されています。node3 には、クラスタ通信用のネットワーク インターフェイスが 1 つだけ割り当てられています。このシナリオでは、ゲートウェイ ノードとして node1 と node2 のみを使用できます。
• 例 2：K8s クラスタ内の 3 つのノードすべてが 1 つのネットワーク インターフェイスに割り当てられています。ネットワーク管理者は、node-1 と node-2 の MAC アドレスのみがインターネットにアクセスできるように、物理ファイアウォールを構成しています。このシナリオでは、ゲートウェイ ノードとして node1 と node2 を使用できます。
• 例 3：3 つのノードすべてがインターネットにアクセスできます。ネットワーク管理者は、物理ゲートウェイに物理ファイアウォールを構成し、ファイアウォールが特定の Egress IP からトラフィックをフィルタリングするようにします。このシナリオでは、3 つのすべてのノードをゲートウェイ ノードとして使用できます。

次の段落では、実装固有の制限について説明します。

ポッドの送信トラフィックをトンネリングするために、Antrea Kubernetes クラスタの外部にある物理ホストまたは仮想マシンをゲートウェイ ノードとして使用することはできません。これは、Antrea Agent が Egress IP アドレスを維持し、このエージェントが K8s クラスタの各ノードでポッドとして実行されているためです。したがって、ゲートウェイ ノードとして使用する物理ホストまたは仮想マシンは、K8s クラスタの一部である必要があります。

シナリオ 2：ノードを介した SNAT

このシナリオでは、Egress リソースのマニフェスト ファイルでポッドが明示的に選択されていません。

ポッドの送信トラフィックはノード IP にマスカレードされ、トラフィックは IaaS ネットワークに送信されます。たとえば、前述のトラフィック フロー図の場合、SNAT ルールによって送信元 IP（pod3 と pod4 の IP）が node2 の IP に変換され、ポッドの送信トラフィックが IaaS ネットワークに送信されます。

シナリオ 3：IaaS ネットワークに直接ブリッジされたルーティング可能なポッド

ルーティング可能なポッドは、アンダーレイ ネットワークでルーティング可能な IP アドレスが割り当てられているポッドです。通常は、ノードで構成されている PodCIDR プロパティのプライベート IP アドレスがポッドに割り当てられます。ポッドが K8s クラスタの外部にあるネットワークにアクセスする場合、トラフィックに対して、送信元 IP（ポッド IP）をルーティング可能な IP に変換する SNAT 操作を実行する必要があります。

Antrea Kubernetes クラスタが NSX (TKGS) の Tanzu Kubernetes Grid Service オーバーレイ ネットワークに展開されている場合、Tanzu Kubernetes クラスタ (TKC) ノードは、NSX からルーティング可能なサブネットを要求し、このルーティング可能なサブネットをノードの PodCIDR プロパティとして使用します。その後、ポッドはルーティング可能な IP アドレスを取得できます。ルーティング可能なポッド ネットワークを使用した TKC の構成の詳細については、VMware vSphere with Tanzu のドキュメントを参照してください。

Antrea Kubernetes クラスタが NSX オーバーレイ ネットワークに展開されていない場合、Kubernetes 管理者は、ルーティング可能なサブネットまたはルーティング可能な IP 範囲がアンダーレイ ネットワークに予約されるように構成できます。管理者は、IPPool カスタム リソースのマニフェスト ファイルでサブネットまたは IP 範囲を構成できます。その後、Antrea CNI は、ルーティング可能な IP アドレスをポッドに割り当てることができます。

たとえば、前述のトラフィック フロー図の場合、node5 で実行されている pod5 が IPPool カスタム リソースからルーティング可能な IP を取得します。

IPPool カスタム リソースの詳細については、Antrea ドキュメント ポータルにあるAntrea IPAM Guideを参照してください。

NSX 内の仮想マシンから Antrea Kubernetes クラスタへのトラフィックの保護

NSX から Antrea Kubernetes クラスタへのトラフィックと一致させるために、ファイアウォール ルールで次の Kubernetes メンバー タイプ（リソース）に基づいて汎用グループを追加できます。

• Kubernetes サービス
• Kubernetes Ingress
• Kubernetes ゲートウェイ
• Antrea IP プール

次の図は、NSX 論理ネットワーク内の仮想マシンから Antrea Kubernetes クラスタへの一般的なトラフィック フローを示しています。

このトラフィック フロー図のように、Antrea Kubernetes クラスタに入るトラフィックと一致させる場合、次のシナリオが考えられます。

シナリオ 1：仮想 IP とポートを介してポッドを外部トラフィックに公開する

次のネイティブ Kubernetes リソースを使用してサードパーティのロード バランサ ソリューションを実装することで、ポッドを外部トラフィックに公開できます。

• Ingress：レイヤー 7 ロード バランサとして機能します。Ingress リソースは、仮想 IP アドレス (VIP) を提供し、一部のポート (TCP/UDP) を公開します。
• ゲートウェイ：レイヤー 4 およびレイヤー 7 ロード バランサとして機能します。ゲートウェイ リソースは、VIP を提供して一部のポート (TCP/UDP) を公開します。
• LoadBalancer タイプのサービス：レイヤー 4 ロード バランサとして機能します。サービスは、VIP を提供して一部のポート (TCP/UDP) を公開します。

注： Ingress リソースと Gateway リソースはレイヤー 7 ロード バランサとして機能できますが、 NSX の分散ファイアウォール ルールとゲートウェイ ファイアウォール ルールの場合、受信トラフィックと一致させるために IP アドレスとポートを使用すると、これらはレイヤー 3 またはレイヤー 4 のロード バランサとして機能します。

シナリオ 2：ノード IP とポートを介してポッドを外部トラフィックにポッドを公開する

• NodePort タイプの Kubernetes サービス：K8s クラスタ内のすべてのノードをトリガし、各サービス ポートに対してノードのポートを開きます。サービスは、ノードの IP とポートを介して到達可能になります。ノードは、トラフィックに SNAT と DNAT を実行します。
• NodePortLocal 機能が有効になっている ClusterIP タイプの Kubernetes サービス：Antrea Agent で NodePortLocal 機能を有効にし、Kubernetes サービスのマニフェスト ファイルに注釈を追加する必要があります。Antrea CNI は注釈を認識し、ポッドが実行されているノード上の各ポッドにポートを開きます。NodePortlLocal は、K8s クラスタのすべてのノードでポートを開くのを回避します。これにより、使用可能なポート範囲を節約します。また、SNAT 操作を回避し、元のクライアント IP を保持します。

  NodePortLocal 機能の詳細については、Antrea ドキュメント ポータルにあるNodePortLocal Guideを参照してください。

シナリオ 3：ルーティング可能なポッド IP アドレスを介してポッドを外部トラフィックにポッドを公開する

Antrea では、Antrea Kubernetes クラスタに IPPool カスタム リソースを展開し、ルーティング可能な IP アドレスをポッドに割り当てることができます。ポッドには、このプールから IP アドレスが割り当てられ、IaaS ネットワークに直接ブリッジされます。

サポートされている IaaS ネットワーク

Antrea Kubernetes クラスタは、次の IaaS プラットフォームに展開できます。

• vSphere ベースのオンプレミス データセンター：Tanzu Kubernetes Grid Service を使用して作成されるTanzu Kubernetes クラスタとして。クラスタは、Tanzu Kubernetes Grid (TKG) 2.0 および vSphere によって管理されます。
• VMware Cloud：TKG 2.0 および VMC SDDC によって管理される Tanzu Kubernetes クラスタとして。
• パブリック クラウド：パブリック クラウド プラットフォーム上の管理対象 Kubernetes クラスタとして。
• 物理サーバ：ベアメタル サーバ上の Kubernetes クラスタとして。
• OpenShift：
  • OpenShift クラスタに展開された Antrea CNI。OpenShift は、IPI (Installer Provisioned Infrastructure) モードまたは UPI (User Provisioned Infrastructure) モードで展開されます。
  • インフラストラクチャ プロバイダは、vSphere、Amazon Web Services (AWS)、Azure、OpenStack、Google Cloud Platform (GCP)、ベアメタルのいずれかになります。

重要： IaaS ネットワークは、 Antrea Kubernetes クラスタと仮想マシン間のトラフィックを処理します。オンプレミス データセンター、VMware Cloud、パブリック クラウドなどの異なるサイト間のトラフィックには、IaaS 固有の VPN が含まれる場合があります。いずれの場合も、IaaS ネットワークによって SNAT 操作が適用されることがあります。 NSX 管理者は、送信元または宛先の IP アドレスがルーティング可能であることを確認し、仮想マシンと Kubernetes クラスタ間のトラフィックが保護されるようにファイアウォール ルールを使用する必要があります。

ファイアウォール ポリシーを適用する際に推奨されるアプローチ

分散ファイアウォールとゲートウェイ ファイアウォールの両方で、ファイアウォール ルールの送信元と宛先に Kubernetes メンバー タイプを含む汎用グループを指定できます。そのため、分散ファイアウォールまたはゲートウェイ ファイアウォールのグループを参照するかどうかを柔軟に決めることができます。

VMware では、次のことを推奨します。

• NSX ゲートウェイ ファイアウォールを使用して、Antrea Kubernetes クラスタから NSX ネットワーク内の仮想マシンへのトラフィックを許可またはブロックします。

  このアプローチは、トラフィックが NSX オーバーレイ ネットワークに入った最も早い時点でトラフィックをフィルタリングするのに役立ちます。

• NSX 分散ファイアウォールを使用して、NSX ネットワーク内の仮想マシンから Antrea Kubernetes クラスタへのトラフィックを許可またはブロックします。

  このアプローチは、トラフィックがNSXオーバーレイ ネットワーク内の仮想マシンを離れる最も早い時点でトラフィックをフィルタリングするのに役立ちます。

ファイアウォール ポリシーで使用する Kubernetes メンバー タイプのサマリ

次の表に、ファイアウォール ルールでトラフィックと一致させるために NSX 汎用グループで使用できる Kubernetes メンバー タイプの概要を示します。

メンバーのタイプ	スコープ	ファイアウォール ポリシーでの使用
Kubernetes クラスタ	クラスタ	動的グループ基準に AND 条件として表示され、特定のクラスタのリソースと一致させることができます。
Kubernetes ネームスペース	ネームスペース	動的グループ基準に AND 条件として表示され、特定のネームスペースのリソースと一致させることができます。
Antrea Egress	クラスタ	送信元 IP = Egress IP の Antrea Kubernetes クラスタからの送信トラフィックと一致します。
Antrea IP プール	クラスタ	送信元 IP が IP 範囲に含まれる Antrea Kubernetes クラスタからの送信トラフィックと一致します。 宛先 IP が IP 範囲に含まれる Antrea Kubernetes クラスタへのトラフィックと一致します。
Kubernetes ノード	クラスタ	送信元 IP がクラスタ ノードの IP に含まれる Antrea Kubernetes クラスタからの送信トラフィックと一致します。
Kubernetes Ingress	ネームスペース	宛先 IP が Ingress IP アドレスに含まれる Antrea Kubernetes クラスタへのトラフィックと一致します。
Kubernetes ゲートウェイ	ネームスペース	宛先 IP がゲートウェイ IP アドレスに含まれる Antrea Kubernetes クラスタへのトラフィックと一致します。
Kubernetes サービス (type=LoadBalancer)	ネームスペース	宛先 IP が LoadBalancer IP アドレスに含まれる Antrea Kubernetes クラスタへのトラフィックと一致します。
Kubernetes サービス (type=NodePort)	ネームスペース	宛先 IP とポートがノード IP アドレスと NodePort 範囲に含まれる Antrea Kubernetes クラスタへのトラフィックと一致します。
Kubernetes サービス (type=ClusterIP)	ネームスペース	なし
Kubernetes サービス (type=ClusterIP) と NodePortLocal 機能が有効	ネームスペース	宛先 IP とポートがノード IP アドレスと NodePortLocal 範囲に含まれる Antrea Kubernetes クラスタへのトラフィックと一致します。