NSX-T move security policy after V2T migration

Submitted by Robin van Altena on Wed, 09/29/2021 - 16:50
Follow your favourite author

Leave us your email address and be the first to receive a notification when Robin posts a new blog.

NSX-T move security policy after V2T migration
Wed 29 Sep, 2021
During a NSX V2T migration using the migration coordinator, all Security Policies are created in NSX-T in the ‘Application Category’ with “:: NSX Service Composer – Firewall” added to the name. At least if the Security Policies have been migrated from the NSX-V Security Composer. Currently there is no option in NSX-T to move a Security Policy from one category to another. So, the question is: ”What the best way is to move (or at least copy) an entire Security Policy including the rules to another category?”

This blog is part of a series about optimalisations that can be done after the Distributed Firewall has been migrated from NSX-V to NSX-T. Most of the optimisations are based on the DFW only migration option. Please have a look at that blog to see the steps that were used for the V2T migration.

One of the optimisations is to move or copy a Security Policy from one category in NSX-T to another. Since there is no option in the NSX-T management GUI to move a Security Policy between categories, I had a look at the options using the NSX-T API. The complete list of NSX-T API calls can be found at code.vmware.com.

For this blog I want to copy or move the QUARANTINE policy from the Application category to the Emergency category. And as a precaution, please test this in a lab environment before using this method in a Production environment.

Retrieve the Security Policy

The first step is to retrieve the complete list of Security Policies to find the ID of the Security Policy we wish to copy or move. This can be done with the following API call:

GET https://<NSX Manager ip>/policy/api/v1/infra/domains/default/security-policies

In the output of this API call the ID for the Security Policy can be found. In this example I’m using Postman.

API call for Security Policy ID

The next step is to retrieve the settings for the specific policy, this can be done with the following API call:

GET https://<NSX Manager>/policy/api/v1/infra/domains/default/security-policies/<Policy ID>

For this use-case the API call will look like:

GET https://<NSX Manager>/policy/api/v1/infra/domains/default/security-policies/16c71b04-15ce-4882-b7bc-cf08f8ec901c

The output or response form this API call will detail the Security Policy including all the firewall rules in the Security Policy. The part that we want to change is the category setting, this can be found at the bottom of the output.

API call for specific Security Policy to list the category

Move the Security Policy

My first try was to simply change the category from Application into Emergency and use the PATCH option to push the information back into NSX-T. The result of this PATCH API call gives a hint why a GUI option to move the Security Policy isn’t available.

Result of PATCH API call to move a Security Policy

So, if a Security policy can’t be moved from one category to another, the next option is to copy the Security Policy to another category and (optionally) delete the Security Policy in the original category.

Copy the Security Policy

Because the complete information for the Security Policy can be retrieved with an API call, we can use that same information to create a new JSON to copy the Security Policy. The structure of the JSON file for the Security Policy looks like this:

    "rules": [
                                             <Information about the Firewall rule 1>
                                             <Information about the Firewall rule 2>
                                             <Information about the Firewall rule 3>
               <Information about the Security policy>

To be able to use the JSON file to create a new Security Policy I removed all the unique information from the JSON file. For each firewall rule entry, I removed the:

  • "id"
  • "path"
  • "relative_path"
  • "parent_path"
  • "unique_id"
  • "rule_id"
  • All the information starting with an underscore, like "_create_user" and "_create_time"

Make sure that if you remove the last entry "_revision" to also remove the comma behind "is_default". Otherwise, the JSON file will no longer be valid.

For the Security Policy I removed the same entries, except for rule_id. For some of the entries I wasn’t sure if they needed to be removed, like

  • "sequence_number"
  • "internal_sequence_number"

But the PUT API call at least works with these entries in the JSON file and they are changed by NSX-T on creation of the Security Policy. Then I changed the category from Application to Emergency.

Because all the references to the Security Groups and Services are already in the JSON file, we do not need to change anything there.

Creating the Security Policy

The next step is to put the information back into NSX-T. This can be done using the same API call, but this time with the PUT method:

GET https://<NSX Manager>/policy/api/v1/infra/domains/default/security-policies/QUARANTINE

The last part of the API call will become the ID for the Security Policy in NSX-T. This value needs to be unique in NSX-T.

If all went well the result of the API call should be Status 200 OK and the Security Policy is available in the Emergency category.

Security Policy viewed using Postman

My next step will be to create a script for this, but that will be fuel for another post.


Questions, Remarks & Comments

If you have any questions and need more clarification, we are more than happy to dig deeper. Any comments are also appreciated. You can either post it online or send it directly to the author, it’s your choice.
Let us know  

Questions, Remarks & Comments

Message Robin directly, in order to receive a quick response.

More about RedLogic