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 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
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.
- 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.
In Manager mode, NCP will create DFW
sections inside top_firewall_section_marker and bottom_firewall_section_marker.
Clusters/foundations may use a different top_firewall_section_marker and/or
bottom_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 section bottom-marker-section-k8scl-one bottom-marker-section-k8scl-two
In Policy Mode, NCP does not support top
and bottom firewall section markers because the enforcement order (i.e. section
priority) is governed by its sequence number. This means that the users should not
create DFW sections between ranges 10 and 99, both inclusive. If a DFW section has
sequence number less than 10, this section has a higher priority than all
cluster/foundation sections created by NCP. 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 section allow [sequence 10] bottom-marker-section-k8scl-one [sequence 100] bottom-marker-section-k8scl-two [sequence 101]