For Manager-to-Policy migration, NSX admin might need to take actions based on how the distributed firewall (DFW) sections affect the Vanilla Kubernetes or TKGi clusters and/or TAS foundations.
If no DFW section is created by NSX admin, you can skip the information below.
DFW sections do not affect any cluster/foundation
- 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.
- In TAS, migrate the DFW sections/rules as a shared resource before/after migration of foundation(s). Note that if DFW rules have source and destination as ANY then such DFW sections must be migrated to the "default" NSX Policy domain.
DFW section affects only one cluster/foundation
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. |
Kubernetes 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. TAS Migrate the same DFW that was created in Manager mode that exists above the cluster's top marker as a shared resource before the foundation's migration is performed. Do the same operations for sections/rules that are below the bottom marker after the foundation'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 foundations are migrated. |
| Top and Bottom Section Markers | NSX Admin Actions |
|---|---|
| NCP is using top and bottom section markers NSX admin-created section is inside top and bottom section markers. |
Kubernetes If the admin-created 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 admin-created 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. TAS If the admin-created section can be moved above the top section marker, migrate the same DFW as a shared resource before the foundation's migration. If the admin-created section can be moved below the bottom section marker, migrate the same DFW as a shared resource after the foundation's migration. Kubernetes and TAS If none of the above is possible, the scenario is not supported. |
| Top and Bottom Section Markers | NSX Admin Actions |
|---|---|
| NCP is not using top and bottom section markers In this case, NCP creates DFW sections in Manager mode at the top or bottom. |
Kubernetes If the admin-created 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 admin-created 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. TAS If the admin-created section can be moved above the NCP-created top section, migrate the same DFW as a shared resource before the foundation's migration. If the admin-created section can be moved below the NCP-created bottom section, migrate the same DFW as a shared resource after the foundation's migration. |
DFW section affects more than one cluster/foundation
| Top and Bottom Section Markers | NSX Admin Actions |
|---|---|
| NCP is using top and bottom section markers All clusters/foundations have the same top and bottom section markers. NSX admin-created sections are outside the top and bottom section markers. |
Kubernetes 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. TAS Migrate the same DFW that was created in Manager mode that exists above the top marker as a shared resource during the migration of the first foundation. Do the same operations for sections/rules that are below the bottom marker after all the foundations are migrated. |
| Top and Bottom Section Markers | NSX Admin Actions |
|---|---|
| NCP is using top and bottom section markers All clusters/foundations have the same top and bottom section markers. NSX admin-created sections are inside the top and bottom section markers. |
Kubernetes If the admin-created 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 admin-created 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. TAS If the admin-created sections can be moved above the top section marker, migrate the same DFWs as shared resources before migrating any of the foundations that are impacted by the sections. They can be migrated using the Opsmanager of any of the foundations. If the admin-created sections can be moved below the bottom section marker, migrate the same DFW as a shared resource after migrating all the foundations that are impacted by the sections. They can be migrated using the Opsmanager of any of the foundations. Kubernetes and TAS If none of the above is possible, the scenario is not supported. |
| Top and Bottom Section Markers | NSX Admin Actions |
|---|---|
| NCP is using top and bottom section markers. The clusters/foundations have different top and bottom section markers. NSX admin-created sections are outside the top and bottom section markers. |
Kubernetes 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. TAS Migrate the same DFW that was created in Manager mode that exists above the top marker as a shared resource during the migration of the foundation. Do the same operations for sections/rules that are below the bottom marker after all the foundations are migrated. |
| Top and Bottom Section Markers | NSX Admin Actions |
|---|---|
| NCP is using top and bottom sectionmarkers. The clusters/foundations have different top and bottom section markers. NSX admin-created sections are inside the top and bottom section markers. |
Kubernetes 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. TAS If possible, move the admin-created sections above the top section markers of all the clusters that the sections impact. Then migrate the same DFWs as shared resources before migrating any of the foundations that are impacted by the sections. They can be migrated using the Opsmanager of any of the foundations. If possible, move the admin-created sections below the bottom section markers of all the clusters that the sections impact. Then migrate the same DFWs as shared resources after migrating all of the foundations that are impacted by the sections. They can be migrated using the Opsmanager of any of the foundations. Kubernetes and TAS
If possible, divide a section into smaller sections such that:
If none of the above is possible, the scenario is not supported. |
| Top and Bottom Section Markers | NSX Admin Actions |
|---|---|
| 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. Similarly, they must specify all the dependent NSX resources in the Opsmanager in TAS.
- If the DFW is consuming an NSX resource that is created by NCP/TKGI/TAS and this DFW needs to be migrated before the NCP/TKGi/TAS created NSX resource is migrated, you must create similar NSX resource manually in Policy.
- If this cannot be done, this scenario is not supported. After the cluster/foundation is migrated, all NCP, TKGI, and TAS 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/TAS NSX resources in DFW after the cluster/foundation 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 or migrate all Security Policies/DFWs in Policy API so that they have sequence_number outside the range the NCP uses. For example, when creating/migrating 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. Alternatively, you can migrate or create the sections under different category. The choices in decreasing order of priority are "Emergency", "Infrastructure", "Environment", and "Application".
About DFW sections
Before migration, when creating a DFW rule in policy mode, you must not use the display name top_firewall_section_marker.
top-firewall-section-k8scl-two k8scl-two cluster DFW section top-firewall-section-k8scl-one k8scl-one cluster DFW section bottom-marker-section-k8scl-one bottom-marker-section-k8scl-two
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 section allow [sequence 10] bottom-marker-section-k8scl-one [sequence 100] bottom-marker-section-k8scl-two [sequence 101]
