Dealing with DFW Sections Created by NSX Admin

For Manager-to-Policy migration, NSX admin might need to take actions based on how the distributed firewall (DFW) sections affect the Kubernetes clusters.

If no DFW section is created by NSX admin, you can skip the information below.

DFW sections do not affect any Kubernetes cluster.

NSX admin can do one of the following:

Use the Policy API to create the same DFW that was created in Manager mode.
Use the NSX UI to migrate everything after all the Kubernetes clusters are migrated.

DFW section affects only one Kubernetes cluster.

There can be multiple sections and multiple rules in a section.


Top and Bottom Section Markers	NSX Admin Actions
NCP is using top and bottom section markers NSX admin-created section is outside top and bottom section markers.	Use the Policy API to create the same DFW that was created in Manager mode that exists above the cluster's top marker. This must be done before the cluster's migration is performed. Do the same operations for sections/rules that are below the bottom marker after the cluster's migration is completed. Make sure that low-priority sections (the ones which in Manager mode are below the bottom marker) are migrated to Policy after all the clusters are migrated.
NCP is using top and bottom section markers NSX admin-created section is inside top and bottom section markers.	If the section can be moved above the top section marker, use the Policy API to create the same DFW that was created in Manager mode before the cluster's migration. If the section can be moved below the bottom section marker, use the Policy API to create the same DFW that was created in Manager mode after the cluster's migration is complete. If none of the above is possible, the scenario is not supported.
NCP is not using top and bottom section markers In this case, NCP creates DFW sections in Manager mode at the top or bottom.	If the section can be moved above the NCP-created top section, use the Policy API to create the same DFW that was created in Manager mode before the cluster's migration. If the section can be moved below the NCP-created bottom section, use the Policy API to create the same DFW that was created in Manager mode after the cluster's migration is complete.

DFW section affects more than one Kubernetes cluster.


Top and Bottom Section Markers	NSX Admin Actions
NCP is using top and bottom section markers. All clusters have the same top and bottom section markers. NSX admin-created sections are outside the top and bottom section markers.	Use the Policy API to create the same DFW that was created in Manager mode that exists above the top marker before migrating the clusters. Do the same operations for sections/rules that are below the bottom marker after all the clusters are migrated..
NCP is using top and bottom section markers. All clusters have the same top and bottom section markers. NSX admin-created sections are inside the top and bottom section markers.	If the sections can be moved above the top section marker, use the Policy API to create the same DFW that was created in Manager mode before migrating the clusters that are impacted by the sections. If the sections can be moved below the bottom section marker, use the Policy API to create the same DFW that was created in Manager mode after migrating the clusters that are impacted by the sections. If none of the above is possible, the scenario is not supported.
NCP is using top and bottom section markers. The clusters have different top and bottom section markers. NSX admin-created sections are outside the top and bottom section markers.	Use the Policy API to create the same DFW that was created in Manager mode that exists above the top marker before migrating the clusters. Do the same operations for sections/rules that are below the bottom marker after all the clusters are migration is completed.
NCP is using top and bottom section markers. The clusters have different top and bottom section markers. NSX admin-created sections are inside the top and bottom section markers.	If possible, move the section above the top section marker of all the clusters that the section impacts. Then use the Policy API to create the same DFW that was created in Manager mode before migrating the clusters that are impacted by the section. If possible, move the section below the bottom section marker of all the clusters that the section impacts. Then use the Policy API to create the same DFW that was created in Manager mode after migrating the clusters that are impacted by the section. If possible, divide a section into smaller sections such that: Each section affects only one cluster. You will have a scenario described in the table "DFW Section Affects Only One Kubernetes Cluster" above. Each section affects multiple clusters but the section is outside the top and bottom section markers of the affected clusters. You will have the scenario described in the row above. If none of the above is possible, the scenario is not supported.
NCP is not using top and bottom section markers. In this case, NCP creates DFW sections in Manager mode at the very top or bottom.	This scenario is similar to the scenario described in the row above except that the top section marker is replaced by the NCP-created top section and the bottom section marker is replaced by the NCP-created bottom section.

Notes

When creating a DFW in Policy mode, NSX admin must first create NSX resources that the DFW needs. Examples of such resources are NSGroups, IPSets, and so on.
If the DFW is consuming an NSX resource that is created by NCP/TKGI, you must create similar NSX resource manually in Policy.
- If this cannot be done, this scenario is not supported. After the cluster is migrated, all NCP and TKGI resources will be available to create the Security Policy and rules.
- If this can be done, the admin should edit the Security Policy and use NCP/TKGI NSX resources in DFW after the cluster is migrated.
NCP creates Security Policies under the Environment and Application categories. The sequence_number used for them are:
- Environment: 1
- Application: 10, 50, 90, 99
You must create and ensure that all Security Policies in Policy API have sequence_number outside the range the NCP uses. For example, when creating a Policy under Application category which is above a top section marker, it can have a sequence_number between 0 to 9 (inclusive). The sequence_number is not unique to a Security Policy (see Patch security policy. For instance, all high-priority rules in MP can be mapped to sequence number 9.

About DFW sections

Before migration, when creating a DFW rule in policy mode, you must not use the display name top_firewall_section_marker.

In Manager mode, NCP will create DFW section inside top_firewall_section_marker and bottom_firewall_section_marker. Clusters may use a different top_firewall_section_marker. You may have sections such as the following:

top-firewall-section-k8scl-two
  k8scl-two cluster DFW section
top-firewall-section-k8scl-one
  k8scl-one cluster DFW setcion
bottom-marker-section-k8scl-one 
bottom-marker-section-k8scl-two

In Policy Mode, NCP does not support top_firewall_section_marker. You must use section sequence to set the priority of a section. NCP creates a section with sequence number 10. That means users cannot create a DFW section between two sections created by NCP. If a top_firewal_section has sequence number less than 10, that means this section has a higher priority than all cluster sections. For example:

top-firewall-section-k8scl-two           [sequence 8]
top-firewall-section-k8scl-one           [sequence 9]
  k8scl-two cluster DFW section allow    [sequence 10]
  k8scl-one cluster DFW setcion allow    [sequence 10]
bottom-marker-section-k8scl-one 
bottom-marker-section-k8scl-two