Configuring Multiple Tier-0 Routers for Tenant Isolation

This topic describes how to create multiple NSX-T Tier-0 (T0) logical routers for use with VMware Tanzu Kubernetes Grid Integrated Edition multi-tenant environments.

About Multi-T0 Router for Tenant Isolation

Tanzu Kubernetes Grid Integrated Edition multi-T0 lets you provision, manage, and secure Kubernetes cluster deployments on isolated tenant networks. As shown in the diagram below, instead of having a single T0 router, there are multiple T0 routers. The Shared Tier-0 router handles traffic between the TKGI management network and the vSphere standard network where vCenter and NSX-T Manager are deployed. There are two Tenant Tier-0 routers that connect to the Shared Tier-0 over an NSX-T logical switch using a VLAN or Overlay transport zone. Using each dedicated T0, Kubernetes clusters are deployed in complete isolation on each tenant network.

Prerequisites

To implement Multi-T0, verify the following prerequisites:

• Supported version of vSphere IaaS is installed. See vSphere with NSX-T Version Requirements.
• Supported version of VMware NSX-T Data Center is installed. See vSphere with NSX-T Version Requirements.
• If you are using NAT mode for the Shared Tier-0 router, review Considerations for NAT Topology on Shared Tier-0 and Considerations for NAT Topology on Tenant Tier-0 before proceeding.

Base Configuration

Step 1: Plan and Provision Additional NSX-T Edge Nodes for Each Multi-T0 Router

Multi-T0 requires a minimum of four NSX-T Edge Nodes: Configure two nodes per T0. Use the T0 attached to the TKGI management plane as the Shared Tier-0 router that connects all T0 routers. In addition, deploy an additional T0 router for each tenant you want to isolate.

Each Tenant Tier-0 router requires a minimum of two NSX-T Edge Nodes. The formula for determining the minimum number of nodes for all tenants is as follows:

2 + (TENANTS x 2)

Where TENANTS is the number of tenants you want to isolate.

For example, if you want to isolate three tenants, use the following calculation:

2 + (3 x 2) = 8 NSX-T Edge Nodes

To isolate ten tenants, use the following calculation:

2 + (10 x 2) = 22 NSX-T Edge Nodes

Using the NSX-T Manager interface, deploy at least the minimum number of Edge Nodes you need for each Tenant Tier-0 and join these Edge Nodes to an Edge Cluster. For more information, see Installing and Configuring NSX-T Data Center v3.0 for TKGI.

Note: An Edge Cluster can have a maximum of 10 Edge Nodes. If the provisioning requires more Edge Nodes than what a single Edge Cluster can support, multiple Edge Clusters must be deployed.

Step 2: Configure Inter-T0 Logical Switch

Connect all NSX-T Edge Nodes using an overlay logical switch. This overlay network is used to transport traffic between the T0 routers. Plan to allocate a network of sufficient size to accommodate all Tier-0 router interfaces that need to be connected to this network. You must allocate each T0 router one or more IP addresses from that range.

For example, if you plan to deploy two Tenant Tier-0 routers, a subnet with prefix size /28 may be sufficient, such as 50.0.0.0/28.

Once you have physically connected the Edge Nodes, define a logical switch to connect the Shared Tier-0 router to the Tenant Tier-0 router or routers.

To define a logical switch based on an Overlay or VLAN transport zone, follow the steps below:

1. In NSX-T Manager, go to Networking > Switching > Switches.
2. Click Add and create a logical switch (LS).
3. Name the switch descriptively, such as inter-t0-logical-switch.
4. Connect the logical switch to the transport zone defined when deploying NSX-T. See Installing and Configuring NSX-T Data Center v3.0 for TKGI.

Step 3: Configure a New Uplink Interface on the Shared Tier-0 Router

The Shared Tier-0 router already has an uplink interface to the external (physical) network that was configured when it was created. For more information, see Installing and Configuring NSX-T Data Center v3.0 for TKGI.

To enable Multi-T0, you must configure a second uplink interface on the Shared Tier-0 router that connects to the inter-T0 network (inter-t0-logical-switch, for example). To do this, complete the following steps:

1. In NSX-T Manager, go to Networking > Routers.
2. Select the Shared Tier-0 router.
3. Select Configuration > Router Ports and click Add.
4. Configure the router port as follows:
   1. For the logical switch, select the inter-T0 logical switch you created in the previous step (for example, inter-t0-logical-switch).
   2. Provide an IP address from the allocated range. For example, 50.0.0.1/24.

Step 4: Provision Tier-0 Router for Each Tenant

Create a Tier-0 logical router for each tenant you want to isolate. For more information, see Create Tier-0 Router in Installing and Configuring NSX-T Data Center v3.0 for TKGI.

When creating each Tenant Tier-0 router, make sure you set the router to be active/passive, and be sure to name the logical switch descriptively, such as t0-router-customer-A.

Step 5: Create Two Uplink Interfaces on Each Tenant Tier-0 Router

Similar to the Shared Tier-0 router, each Tenant Tier-0 router requires at a minimum two uplink interfaces.

• The first uplink interface provides an uplink connection from the Tenant Tier-0 router to the tenant’s corporate network.

• The second uplink interface provides an uplink connection to the Inter-T0 logical switch that you configured. For example, inter-t0-logical-switch.

For instructions, see Create Tier-0 Router in Installing and Configuring NSX-T Data Center v3.0 for TKGI. When creating the uplink interface that provides an uplink connection to the Inter-T0 logical switch, be sure to give this uplink interface an IP address from the allocated pool of IP addresses.

Step 6: Verify the Status of the Shared and Tenant Tier-0 Routers

When you have completed the configuration of the Shared and Tenant Tier-0 routers as described above, verify your progress up to this point. On the Shared Tier-0 router, you should have two uplink interfaces, one to the external network and the other to the inter-T0 logical switch. On the Tenant Tier-0 router, you should have two uplink interfaces, one to the inter-T0 logical switch and the other to the external network. Each uplink interface is connected to a transport node.

The images below provide an example checkpoint for verifying the uplink interfaces for the Shared and Tenant Tier-0 routers. In this example, the Shared Tier-0 has one uplink interface at 10.40.206.10/25 on the transport Edge Node edge-TN1, and the second uplink interface at 10.40.206.9/25 on the transport Edge Node edge-TN2.

Similarly, the Tenant Tier-0 has one uplink interface at 10.40.206.13/25 on the transport Edge Node edge-TN3, and the second uplink interface at 10.40.206.14/25 on the transport Edge Node edge-TN4.

Step 7: Configure Static Routes

For each T0 router, including the Shared Tier-0 and all Tenant Tier-0 routers, define a static route to the external network. For instructions, see Create Tier-0 Router in Installing and Configuring NSX-T Data Center v3.0 for TKGI.

For the Shared Tier-0 router, the default static route points to the external management components such as vCenter and NSX-T Manager and provides internet connectivity. As shown in the image below, the Shared Tier-0 defines a static route for vCenter and NSX-T Manager as 192.168.201.0/24, and the static route for internet connectivity as 0.0.0.0/0:

For each Tenant Tier-0 router, the default static route should point to the tenant’s corporate network. As shown in the image below, the Tenant Tier-0 defines a static route to the corporate network as 0.0.0.0/0:

Step 8: Considerations for NAT Topology on Shared Tier-0

The Multi-T0 configuration steps documented here apply to deployments where NAT mode is not used on the Shared Tier-0 router. For more information, see NSX-T Deployment Topologies for Tanzu Kubernetes Grid Integrated Edition.

For deployments where NAT-mode is used on the Shared Tier-0 router, additional provisioning steps must be followed to preserve NAT functionality to external networks while bypassing NAT rules for traffic flowing from the Shared Tier-0 router to each Tenant Tier-0 router.

Existing Tanzu Kubernetes Grid Integrated Edition deployments where NAT mode is configured on the Shared Tier-0 router cannot be re-purposed to support a Multi-T0 deployment following this documentation.

Step 9: Considerations for NAT Topology on Tenant Tier-0

Note: This step only applies to NAT topologies on the Tenant Tier-0 router. For more information on NAT mode, see NSX-T Deployment Topologies for TKGI.

Note: NAT mode for Tenant Tier-0 routers is enabled by defining a non-routable custom Pods IP Block using a Network Profile. For more information, see Defining Network Profiles.

In a Multi-T0 environment with NAT mode, traffic on the Tenant Tier-0 network going from Kubernetes cluster nodes to TKGI management components residing on the Shared Tier-0 router must bypass NAT rules. This is required because TKGI-managed components such as BOSH Director connect to Kubernetes nodes based on routable connectivity without NAT.

To avoid NAT rules being applied to this class of traffic, you need to create two high-priority NO_SNAT rules on each Tenant Tier-0 router. These NO_SNAT rules allow “selective” bypass of NAT for the relevant class of traffic, which in this case is connectivity from Kubernetes node networks to TKGI management components such as the TKGI API, Ops Manager, and BOSH Director, as well as to infrastructure components such as vCenter and NSX-T Manager.

For each Tenant Tier-0 router, define two NO_SNAT rules to classify traffic. The source for both rules is the Nodes IP Block CIDR. The destination for one rule is the TKGI Management network where TKGI, Ops Manager, and BOSH Director are deployed. The destination for the other rule is the external network where NSX-T Manager and vCenter are deployed.

For example, the following image shows two NO_SNAT rules created on a Tenant Tier-0 router. The first rule un-NATs traffic from Kubernetes nodes (30.0.128.0/17) to the TKGI management network (30.0.0.0/24). The second rule un-NATs traffic from Kubernetes nodes (30.0.128.0/17) to the external network (192.168.201.0/24).

The end result is two NO_SNAT rules on each Tenant Tier-0 router that bypass the NAT rules for the specified traffic.

Step 10: Configure BGP on Each Tenant Tier-0 Router

The Border Gateway Protocol (BGP) is used for route redistribution and filtering across all Tier-0 routers. BGP allows the Shared Tier-0 router to dynamically discover the location of Kubernetes clusters (Node networks) deployed on each Tenant Tier-0 router.

In a Multi-T0 deployment, special consideration must be given to the network design to preserve reliability and fault tolerance of the Shared and Tenant Tier-0 routers.

Failover of a logical router is triggered when the router is losing all of its BGP sessions. If multiple BGP sessions are established across different uplink interfaces of a Tier-0 router, failover will only occur if all such sessions are lost. Thus, to ensure high availability on the Shared and Tenant Tier-0 routers, BGP can only be configured on uplink interfaces facing the Inter-Tier-0 network. This configuration is shown in the diagram below.

Note: In a Multi-T0 deployment, BGP cannot be configured on external uplink interfaces. Uplink external connectivity must use VIP-HA with NSX-T to provide high availability for external interfaces. For more information, see Deploy NSX-T Edge Nodes in Installing and Configuring NSX-T Data Center v3.0 for TKGI.

You must configure BGP routing on each Tier-0 router. The steps that follow are for each Tenant Tier-0 router. The instructions for the Shared Tier-0 are provided in subsequent steps. As a prerequisite, assign a unique Autonomous System Number to each Tier-0 router. Each AS number you assign must be private within the range 64512-65534. For more information, see Configure BGP on a Tier-0 Logical Router in the NSX-T documentation.

Note: To configure BGP for the Tenant Tier-0, you will need to use the Shared Tier-0 AS number. As such, identify the AS numbers you will use for the Tenant and Shared Tier-0 routers before proceeding.

Configure BGP AS Number

Once you have chosen the AS number for the Tenant Tier-0 router, configure BGP with the chosen AS number as follows:

1. In NSX-T Manager, select Networking > Routers.
2. Select the Tenant Tier-0 router.
3. Select Routing > BGP, the click ADD.
4. Add the AS number to the BGP configuration in the local AS field.
5. Click on the enabled slider to activate BGP.
6. Lastly, deactivate the ECMP slider.

Configure BGP Route Distribution

To configure BGP route distribution for each Tenant Tier-0 router, follow the steps below:

1. In NSX-T Manager, select the Tenant Tier-0 router.
2. Select Routing > Route Redistribution.
   
3. Click Add and configure as follows:
   1. Name: NSX Static Route Redistribution
   2. Sources: Select Static, NSX Static, and NSX Connected

Configure IP Prefix Lists

In this step you define an IP Prefix List for each Tenant Tier-0 router to advertise any Kubernetes node network of standard prefix size /24, as specified by the less-than-or-equal-to (le) and greater-than-or-equal-to (ge) modifiers in the configuration. The CIDR range to use for the definition of the list entry is represented by the Nodes IP Block network, for example 30.0.0.0/16.

For more information about IP Prefix Lists, see Create an IP Prefix List in the NSX-T documentation.

To configure an IP Prefix List for each Tenant Tier-0 router, follow the steps below:

1. In NSX-T Manager, select the Tenant Tier-0 router.
2. Select Routing > IP Prefix Lists.
3. Click Add and configure as follows:
   1. Name: Enter a descriptive name.
   2. Click Add and create a Permit rule that allows redistribution of the exact /24 network, carved from the Nodes IP Block.
   3. Click Add and create a Deny rule that denies everything else on the network 0.0.0.0/0.

Configure BGP Peer

To configure BGP peering for each Tenant Tier-0 router, follow the steps below:

1. In NSX-T Manager, select the Tenant Tier-0 router.
2. Go to Routing > BGP.
3. Click Add and configure the BGP rule as follows:
   1. Neighbor Address: Enter the IP address of the Shared Tier-0 router.
   2. Local Address: Select the individual uplink interfaces facing the inter-tier0 logical switch.
   3. Address Families: Click Add and configure as follows:
      1. Type: IPV4_UNICAST
      2. State: Enabled
      3. Out Filter: Select the IP Prefix List created above.
      4. Click Add.
   4. Back at the Routing > BGP screen:
      1. Enter the Shared Tier-0 AS number.
      2. After creating the BGP neighbor, select Edit and click Enable BGP.

Step 11: Configure BGP on the Shared Tier-0 Router

The configuration of BGP on the Shared Tier-0 is similar to the BGP configuration each Tenant Tier-0, with the exception of the IP Prefix list that permits traffic to the TKGI management network where TKGI, BOSH, and Ops Manager are located.

As with each Tenant Tier-0 router, you will need to assign a unique private AS number within the private range 64512-65534 to the Shared Tier-0 router. Once the AS number is assigned, use NSX-T Manager to configure the following BGP rules for the Shared Tier-0 router.

Configure BGP AS Number

To configure BGP on the Shared Tier-0 with the AS number, complete the corresponding set of instructions in the tenant BGP section above.

Configure BGP Route Distribution

To configure BGP route distribution for the Shared Tier-0 router, complete the corresponding set of instructions in the BGP tenant section above.

Configure IP Prefix Lists

To configure IP prefix lists for each Tenant Tier-0 router, follow the steps below:

1. In NSX-T Manager, select the Tenant Tier-0 router.
2. Select Routing > IP Prefix Lists.
3. Click Add and configure as follows:
   1. Name: Enter a descriptive name.
   2. Click Add and create a Permit rule for the infrastructure components vCenter and NSX-T Manager.
   3. Click Add and create a Permit rule for the TKGI management components (TKGI, Ops Manager, and BOSH).
   4. Click Add and create a Deny rule that denies everything else on the network 0.0.0.0/0.
      

Configure BGP Peer

1. In NSX-T Manager, select the Tenant Tier-0 router.
2. Go to Routing > BGP.
3. Click Add and configure the BGP rule as follows:
   1. Neighbor Address: Enter the IP address of the Shared Tier-0 router.
   2. Local Address: Select All Uplinks.
   3. Address Families: Click Add and configure as follows:
      1. Type: IPV4_UNICAST
      2. State: Enabled
      3. Out Filter: Select the IP Prefix List that includes the network where vCenter and NSX-T Manager are deployed, as well as the network where the TKGI management plane is deployed.
      4. Click Add.
   4. Back at the Routing > BGP screen:
      1. Enter the Tenant Tier-0 AS number.
      2. After creating the BGP neighbor, select Edit and click Enable BGP.

Note: You must repeat this step for each Tenant Tier-0 router you want to peer with the Shared Tier-0 router.

Step 12: Test the Base Configuration

Perform the following validation checks for all Tier-0 routers. You should perform the validation checks on the Shared Tier-0 first followed by each Tenant Tier-0 router. For each Tier-0, the validation should alternate among checking for the BGP summary and the router Routing Table.

Shared Tier-0 Validation

Verify that the Shared Tier-0 has an active peer connection to each Tenant Tier-0 router. To verify BGP Peering.

• In NSX-T Manager, select the Shared Tier-0 router and choose Actions > Generate BGP Summary.
• Validate that the Shared Tier-0 router has one active peer connection to each Tenant Tier-0 router.

Verify that the Shared Tier-0 routing table includes all BGP routes to each Shared Tier-0.

• In NSX-T Manager, select Networking > Routers > Routing.
• Select the Shared Tier-0 router and choose Actions > Download Routing Table.
• Download the routing table for the Shared Tier-0 and verify the routes.

Tenant Tier-0 Validation

Verify that the Shared Tier-0 has an active peer connection to each Tenant Tier-0 router. To verify BGP Peering.

• In NSX-T Manager, select the Tenant Tier-0 router and choose Actions > Generate BGP Summary.
• Validate that the Tenant Tier-0 router has one active peer connection to the Shared Tier-0 router.
• Repeat for all other Tenant Tier-0 routers.

Verify that the T0 routing table for each Tenant Tier-0 includes all BGP routes to reach vCenter, NSX-T Manager, and the TKGI management network.

• In NSX-T Manager, select Networking > Routers > Routing.
• Select the T0 router and choose Actions > Download Routing Table.
• Download the routing table for each of the Tenant Tier-0 routers.

Note: At this point, the Shared Tier-0 has no BGP routes because you have not deployed any Kubernetes clusters. The Shared Tier-0 will show BGP routes when you deploy Kubernetes clusters to the Tenant Tier-0 routers. Each Tenant Tier-0 router shows a BGP exported route that makes each Tenant Tier-0 router aware of the TKGI management network and other external networks where NSX-T and vCenter are deployed.

Security Configuration

In a multi-T0 environment, you can secure two types of traffic:

• Traffic between tenants. See Secure Inter-Tenant Communications.
• Traffic between clusters in the same tenant. See Secure Intra-Tenant Communications.

Secure Inter-Tenant Communications

Securing traffic between tenants isolates each tenant and ensures the traffic between the Tenant Tier-0 routers and the Shared Tier-0 router is restricted to the legitimate traffic path.

Step 1: Define IP Sets

In NSX-T an IP Set is a group of IP addresses that you can use as sources and destinations in firewall rules. For a Multi-T0 deployment you need to create several IP Sets as described below. For more information about creating IP Sets, see Create an IP Set in the NSX-T documentation.

The image below shows a summary of the three required IP Sets you will need to create for securing Multi-T0 deployments:

First, define an IP Set that includes the IP addresses for the NSX-T Manager and vCenter hosts. In the following IP Set example, 192.168.201.51 is the IP address for NSX and 192.168.201.20 is the IP address for vCenter.

Next, define an IP Set that includes the network CIDR for TKGI management components. In the following IP Set example, 30.0.0.0/24 is the CIDR block for the TKGI Management network.

Lastly, define an IP Set for the Inter-T0 CIDR created during the base configuration.

Note: These are the minimum IP Sets you need to create. You may want to define additional IP Sets for convenience.

Step 2: Create Edge Firewall

NSX-T Data Center uses Edge Firewall sections and rules to specify traffic handling in and out of the network. A firewall section is a collection of firewall rules. For more information, see About Firewall Rules in the NSX-T documentation.

For each Tenant Tier-0 router, create an Edge Firewall and section as follows:

1. In NSX Manager, go to Networking > Routers.
2. Select the Tenant Tier-0 router and click Services > Edge Firewall.
3. Select the Default LR Layer 3 Section.
4. Click Add Section > Add Section Above.
   
5. Configure the section as follows:
   1. Section Name: Enter a unique name for the firewall section.
   2. State: Stateful
      

Step 3: Add Firewall Rules

The last step is to define several firewall rules for the Edge Firewall. The firewall rules allow only legitimate control plane traffic to traverse the inter-Tier-0 logical switch, and deny all other traffic.

The following image shows a summary of the five firewall rules you will create:

Note: All firewall rules are applied to the Inter-T0-Uplink interface.

Select the Edge Firewall Section you just created, then select Add Rule. Add the following five firewall rules:

BGP Firewall Rule

• Name: BGP
• Direction: in and out
• Source: IP Set defined for the Inter-T0 CIDR
• Destination: IP Set for Inter-T0 CIDR
• Service: Any
• Action: Allow
• Apply the rule to the Inter-T0-Uplink interface.
• Save the firewall rule.

Clusters Masters Firewall Rule

The source for this firewall rule is a Namespace Group (NSGroup) you define in NSX Manager. The NSGroup is the Bootstrap Security Group specified in the Network Profile associated with this tenant. See Bootstrap Security Group (NSGroup).

Once you have defined the NSGroup, configure the firewall rule as follows.

• Name: Clusters-Masters-to-NSX-and-VC
• Direction: out
• Source: NSGroup for Kubernetes Control Plane Nodes
• Destination: IP Set for Inter-T0 CIDR
• Service: Any
• Action: Allow
• Apply the rule to the Inter-T0-Uplink interface.
• Save the firewall rule.

Node Network to Management Firewall Rule

This firewall rule allows Kubernetes node traffic to reach TKGI management VMs and the standard network.

• Name: Node-Network-to-Management
• Direction: out
• Source: IP Set defined for the Nodes IP Block network
• Destination: IP Sets defined for vCenter, NSX Manager, and TKGI management plane components
• Service: Any
• Action: Allow
• Apply the rule to the Inter-T0-Uplink interface.
• Save the firewall rule.

TKGI Firewall Rule

This firewall rule allows TKGI management plane components to talk to Kubernetes nodes.

• Name: TKGI-to-Node-Network
• Direction: ingress
• Source: IP Set defined for the TKGI management network
• Destination: IP Set defined for the Nodes IP Block network
• Service: Any
• Action: Allow
• Apply the rule to the Inter-T0-Uplink interface.
• Save the firewall rule.

Deny All Firewall Rule

• Name: Deny All. This setting drops all other traffic that does not meet the criteria of the first three rules.
• Direction: in and out
• Source: Any
• Destination: Any
• Service: Any
• Action: Drop
• Apply the rule to the Inter-T0-Uplink interface.
• Save the firewall rule.

(Optional) Step 4: Create DFW Section

To use distributed firewall (DFW) rules, you must create a DFW section for the DFW rule set. The DFW section must exist before you create a Kubernetes cluster.

This optional step is recommended for inter-tenant security. It is required for intra-tenant security as described in Secure Intra-Tenant Communications. Because you need to create the DFW section only once, you can use the DFW section you configure in this step when defining DFW rules for intra-tenant communications.

Even if you do not currently plan to use DFW rules, you can create the DFW section and use it later if you decide to define DFW rules. Those rules will apply to any cluster created after you define the DFW section for the tenant Tier-0 router.

Note: You must perform this procedure before you deploy a Kubernetes cluster to the target tenant Tier-0 router.

1. In NSX Manager, navigate to Security > DFW, select the top-most rule, and click Add Section Above.
2. Configure the section as follows:
   1. In the Section Name field, enter a name for your DFW section. For example, tkgi-dfw.
   2. Use the defaults for all other settings on the New Section page.
   3. Navigate to the Manage Tags page and add a new tag.
      1. In the Tag field, enter top.
      2. In the Scope field, enter ncp/fw_sect_marker.

Secure Intra-Tenant Communications

To secure communication between clusters in the same tenancy, you must disallow any form of communication between Kubernetes clusters created by TKGI. Securing inter-cluster communications is achieved by provisioning security groups and DFW rules.

Note: You must perform the global procedures, the first three steps described below, before you deploy a Kubernetes cluster to the target tenant Tier-0 router.

Step 1: Create NSGroup for All Tanzu Kubernetes Grid Integrated Edition Clusters

1. In NSX Manager, navigate to Inventory > Groups > Groups and Add new group.
2. Configure the new NSGroup as follows:
   1. In the Name field, enter All-TKGI-Clusters.
   2. In the Membership Criteria tab, add the following two criteria:
      1. For the first criterion, select Logical switch.
      2. For Scope > Equals, enter pks/clusters.
      3. For Scope > Equals, enter pks/floating_ip.
      4. For the second criterion, select Logical switch.
      5. For Scope > Equals, enter ncp/cluster.
         

Note: The pks/clusters, pks/floating_ip, or ncp/cluster values are the exact values you must enter when configuring Scope > Equals. They map to NSX-T objects.

After you configure the All-TKGI-Clusters NSGroup, the Membership Criteria tab looks as follows:

Step 2: Create DFW Section

Before you create distributed firewall rules, you must create a DFW section for the DFW rule set you define later.

To create a DFW section, follow the instructions in Create DFW Section.

Step 3: Create NSGroups

Before creating NSGroups, retrieve the UUID of the cluster that you want to secure. To retrieve the cluster UUID, run the tkgi cluster YOUR-CLUSTER-NAME command. For more information about the TKGI CLI, see TKGI CLI.

Create NSGroup for Cluster Nodes

1. In NSX Manager, navigate to Inventory > Groups > Groups and click Add new group.
2. Configure the new NSGroup as follows:
   1. In the Name field, enter the cluster UUID or cluster name and append -nodes to the end of the name to distinguish it. The cluster name must be unique.
   2. In the Membership Criteria tab, add the following criterion:
      1. Select Logical Switch.
      2. For Tag > Equals, enter tkgi-cluster-YOUR-CLUSTER-UUID.
      3. For Scope > Equals, enter pks/cluster.
      4. For Scope > Equals, enter pks/floating_ip. For this scope, leave the Tag field empty as shown in the image below.
         

After you configure the NSGroup for cluster nodes, the Membership Criteria tab looks as follows:

Create NSGroup for Cluster Pods

1. In NSX Manager, navigate to Inventory > Groups > Groups and click Add new group.
2. Configure the new NSGroup as follows:
   1. In the Name field, enter the cluster UUID or cluster name and append -pods to the end of the name to distinguish it. The cluster name must be unique.
   2. In the Membership Criteria tab, add the following criterion:
      1. Select Logical Port.
      2. For Tag > Equals, enter tkgi-cluster-YOUR-CLUSTER-UUID.
      3. For Scope > Equals, enter ncp/cluster.
         

After you configure the NSGroup for cluster pods, the Membership Criteria tab looks as follows:

Create NSGroup for Cluster Nodes and Pods

1. In NSX Manager, navigate to Inventory > Groups > Groups and click Add new group.
2. Configure the new NSGroup as follows:
   1. In the Name field, enter the cluster UUID or cluster name and append -nodes-pods to the end of the name to distinguish it. The cluster name must be unique.
   2. In the Membership Criteria tab, add the following two criteria:
      1. For the first criterion, select Logical Port.
      2. For Tag > Equals, enter tkgi-cluster-YOUR-CLUSTER-UUID.
      3. For Scope > Equals, enter ncp/cluster.
      4. For the second criterion, select Logical Switch.
      5. For Tag > Equals, enter tkgi-cluster-YOUR-CLUSTER-UUID.
      6. For Scope > Equals, enter pks/cluster.
         

After you configure the NSGroup for cluster nodes and pods, the Membership Criteria tab looks as follows:

Step 4: Create DFW Rules

Select the DFW section you created above and configure the following three DFW rules.

DFW Rule 1: Deny Everything Else

This is a global deny rule. Configure the rule as follows:

1. Click Add Rule.
2. In the Name field, enter a name for your DFW rule.
3. For Source, select the All-TKGI-Clusters NSGroup.
4. For Destination, select the All-TKGI-Clusters NSGroup.
5. For Service, select Any.
6. For Apply To, select the YOUR-CLUSTER-UUID-nodes-pods NSGroup.
7. For Action, select Drop.

DFW Rule 2: Prevent Pod to Node Communication

Configure this rule as follows:

1. Click Add Rule.
2. In the Name field, enter a name for your DFW rule.
3. For Source, select the YOUR-CLUSTER-UUID-pods NSGroup.
4. For Destination, select YOUR-CLUSTER-UUID-nodes NSGroup.
5. For Service, select Any.
6. For Apply To, select the YOUR-CLUSTER-UUID-nodes-pods NSGroup.
7. For Action, select Drop.

DFW Rule 3: Allow Node to Node and Nodes to Pods Communications

Configure this rule as follows:

1. Click Add Rule.
2. In the Name field, enter a name for your DFW rule.
3. For Source, select the YOUR-CLUSTER-UUID-nodes-pods NSGroup.
4. For Destination, select YOUR-CLUSTER-UUID-nodes-pods NSGroup.
5. For Service, select Any.
6. For Apply To, select YOUR-CLUSTER-UUID-nodes-pods NSGroup.
7. For Action, select Allow.

For example, see the three configured DFW rules below: