Leave us your email address and be the first to receive a notification when Robin posts a new blog.
In a previous blog, I was able to copy an entire Security Policy from one category to another. To copy the Security Policy, I used API calls to retrieve the information about the Security Policy. Then I needed to modify the information and send it back to NSX-T using another API call. With some trial and errors, I was able to do this in a lab environment. But manually modifying an JSON file isn’t a best practice to do this for multiple Security Policies in a Production environment. Thus, the next step is to create a script for this. As you can see in the picture above, I’m using PowerCLI with the NSX-T Policy Service.
Of course, you can also do this with API calls directly from Powershell. But for multiple reasons I wanted to do this with the NSX-T Policy Service module. One of the reasons is that I have an internal 'battle' with a colleague to see which method works better, the NSX-T Policy Service or the REST-API method. But as always it usually is personal preference.
About a year ago I wrote a blog article about the NSX-T Policy Service. It explains the basics about the NSX-T Policy Service. So, for this blog I will get straight to the point. As described in the previous blog the steps to copy the Security Policy are:
- Connect to the NSX-T manager
- Retrieve the Security Policy configuration
- Modify the Security Policy configuration
- Write the new the Security Policy to NSX-T
My starting position is that I already have a connection to my NSX-T manager.
Retrieving the Security Policy configuration
Like the previous blog I want to move or copy the Quarantine Security Policy to the Emergency Category.
After the connection towards the NSX-T manager has been made, the first step is to retrieve the configuration for the Security Policy. In the GUI the name is visible, but we need the ‘id’ to retrieve the entire configuration. So, first we need to retrieve a list of all the Security Policies. We can do this with the following commands:
$SecDomain = "default"
$SecPolicyData = Get-NsxtPolicyService -Name com.vmware.nsx_policy.infra.domains.security_policies
$SecPolicyList = $SecPolicyData.list($SecDomain)
The first line states the domain in which we will be working, in most cases the default domain. The second line sets up the Security Policies in NSX-T Policy Service. And the third line retrieves all the Security Policies in the default domain. Remember that you can view the object of information for the list with “$SecPolicyList | Get-Member”
The next step is to get the ‘id’ for the Security Policy we wish to copy.
$SecPolicyName = 'QUARANTINE :: NSX Service Composer - Firewall'
$SecPolicy = $SecPolicyList.results | Where-Object {$_.display_name -Like $SecPolicyName}
Here the first line lists our Security Policy, and the second line filters the results from the list of Security Policies. At this point we can retrieve the ‘id’ for the Security Policy with “$SecPolicy.id”. With the ‘id’ for the Security Policy we can retrieve the entire configuration or specification for this Security Policy.
$SecPolicySpec = $SecPolicyData.get($SecDomain,$SecPolicy.id)
Modify the Security Policy configuration
Now that we know the details for the Security Policy, we can begin to modify the Security Policy as desired. There are at least two things that I would like to change. The category and the name, which has the information set by the migration coordinator.
$SecPolicySpec.category = 'Emergency'
$SecPolicySpec.display_name = 'QUARANTINE'
The first line sets the category, and the second line changes the display name. Again, the complete list of items that can be changed can be found with “$SecPolicySpec | Get-Member”.
Write the new the Security Policy to NSX-T
The last step is to push this information back to the NSX-T managers. For this we need to give the Security Policy a unique identifier. This doesn’t have to be a UUID, it needs to be unique. Since I haven’t found a method of asking the NSX-T manager for a UUID, I mostly use the display name.
$SecPolicyData.patch($SecDomain, 'QUARANTINE', $SecPolicySpec)
After this command has been run the Security Policy can also be found in the Emergency category.
Putting it all together, the script will look like this:
$SecPolicyName = 'QUARANTINE :: NSX Service Composer - Firewall'
$SecDomain = "default"
$SecPolicyData = Get-NsxtPolicyService -Name com.vmware.nsx_policy.infra.domains.security_policies
$SecPolicyList = $SecPolicyData.list($SecDomain)
$SecPolicy = $SecPolicyList.results | Where-Object {$_.display_name -Like $SecPolicyName}
$SecPolicySpec = $SecPolicyData.get($SecDomain,$SecPolicy.id)
$SecPolicySpec.category = 'Emergency'
$SecPolicySpec.display_name = 'QUARANTINE'
$SecPolicyData.patch($SecDomain, 'QUARANTINE', $SecPolicySpec)
My suggestion would be to first check this Security Policy before removing the original. But if the script has been tested properly you can use the following command to delete the original security policy:
$SecPolicyData.delete($SecDomain,$SecPolicy.id)
I hope you find this blog helpful. And if there are any questions or remarks please send them to me so we can improve the community together.
LinkedIn
Twitter
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.