This topic describes how VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) administrators can define network profiles to create markers for NSX distributed firewall (DFW).
Note: The NSX Policy API features a tiered policy model using categories and does not support prioritizing operational rules using the procedure below.
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:
For more information about DFW Firewall Section Marker rules in Network Profiles, see About DFW Section Markers below.
Note: The NSX 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
.
Distributed firewall rules are either Allow
or Deny
/Drop
rules:
Allow
rules are placed before Deny
/Drop
rules and take higher precedence than Deny
rules.Allow
or Deny
/Drop
rules, precedence is defined by the order the rules were created:
Allow
rules have precedence over later Allow
rules.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 VMware NSX 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.
For more information about Distributed Firewalls in VMware NSX, see Firewall in Manager Mode or Distributed Firewall for Policy API environments, both in the VMware NSX Data Center for vSphere documentation.
Note: NSX 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.
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"
}
}
}
}
You cannot modify DFW rule configuration on an existing cluster.
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": {
"bottom_firewall_section_marker":"section-id"
}
}
}
}
You cannot modify DFW rule configuration on an existing cluster.