Defining DFW Section Markers

This topic describes how VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) administrators can define network profiles to create markers for NSX-T distributed firewall (DFW).

Note: The NSX-T Policy API features a tiered policy model using categories and does not support prioritizing operational rules using the procedure below.

Overview

When a TKGI administrator creates a Network Profile or a Kubernetes developer creates a Kubernetes Network Policy, NCP translates their configuration into a distributed firewall rule.

The first DFW rules have precedence over later DFW rules. When using the default DFW configuration, a TKGI administrator cannot define a Network Profile with precedence over existing DFW rules, including rules created from a developer’s Kubernetes Network Policy configuration.

To define a Network Profile with precedence over existing DFW rules, configure a DFW Firewall Section Marker.

To configure a DFW Firewall Section Marker:

• Create a Top Firewall Section Marker
• Create a Bottom Firewall Section Marker

For more information about DFW Firewall Section Marker rules, see About DFW Section Markers below.

Note: The NSX-T Policy API feature does not support DFW Firewall Section Marker configuration because it uses a category-based tiered policy model. NCP inserts Network Policy rules into the Application tier, the last and lowest tier, which is always preceded by other tiers, such as Infrastructure and Environment.

About DFW Section Markers

Distributed firewall rules are either Allow or Deny/Drop rules:

• DFW Allow rules are placed before Deny/Drop rules and take higher precedence than Deny rules.
• When there are multiple DFW Allow or Deny/Drop rules, precedence is defined by the order the rules were created:
  • The first Allow rules have precedence over later Allow rules.
  • The first Deny rules have precedence over later Deny rules.

Because the first DFW rules have precedence over later DFW rules, existing DFW rules, including rules created from a Kubernetes developer’s Network Policy configuration, have precedence over the rules defined afterward by a TKGI administrator using Network Profiles.

The VMware NSX-T Data Center supports organizing DFW rules into sections and TKGI supports creating a Top Firewall Firewall Section Marker and a Bottom Firewall Section Marker within DFW rules. DFW rules placed within the Top Firewall Section or Bottom Firewall Section have precedence over the other NCP-created DFW rules.

With the Top and Bottom Firewall Sections, an administrator can position operational rules to have precedence over developer-created DFW rules.

Note: NSX-T applies DFW rules on ESXi transport nodes to control east-west traffic. Edge firewall (EFW) rules run on Edge transport nodes and control north-south traffic.

Create a Top Firewall Section Marker

Using the top_firewall_section_marker, the operational rules can be created in the top section, NCP will create any rules when Kubernetes network policies are created always below this top section marker. Thus, the operational rules created will not be over-ridden by developers.

{
 "name": "Example network profile",
 "description": "Network profile to enable DFW section marking",
 "parameters": {
   "cni_configurations":
   {
      "type":"nsxt",
      "parameters": {
        "top_firewall_section_marker":"section-id",
        "bottom_firewall_section_marker":"section-id"        
      }
    }
  }
}

Create a Bottom Firewall Section Marker

Drop/deny rules operate in the bottom section. You can define a bottom_firewall_section_marker so that drop/deny rules created by NCP do not displace existing rules.

{
 "name": "Example network profile",
 "description": "Network profile to enable DFW section marking",
 "parameters": {
   "cni_configurations":
   {
      "type":"nsxt",
      "parameters": {
        "top_firewall_section_marker":"section-id",
        "bottom_firewall_section_marker":"section-id"        
      }
    }
  }
}