In part 1 of this post I described how to download and run a docker container that can be used to talk to the RESTful API of NSX-T manager. While the same container can also be used to talk to NSX-v, vCenter and SDDC manager, I will focus on NSX-T for now.

During a couple of projects, I was tasked with automating things in NSX-T or even satisfy customer requirements that can not be satisfied with the NSX-T GUI. So most scripts that I will describe in this and the following parts have been developed due to customer requests.

In case you want to try the scripts, you should follow part 1 of this post which can be found here:

 

Backup and restore of individual DFW policies

While it’s possible to export and restore the complete DFW (distributed firewall) configuration, some customers might have additional requirements like:

• Backup and Restore of individual DFW policies
• Regularly backup all DFW policies using a cron job

Two scripts are available in the container that can satisfy such requirements:

backup-policies

backup-policies -h
usage: backup-policies [options]

Options:
-h : Display help
-d <backup directory> : directory to save the backup to

This script will create a subdirectory in the directory specified by the -d option (or the current directory if not specified) in the format DFW-backup-day.month.year-hour.minute.second. In this directory, the script will create one JSON file per DFW policy.

As adviced in part 1 of this post, it’s good to have a volume mount in the container using -v ~/data:data in the docker run command. Then you can run the script using 

backup-policies -d /data

which will create a backup of all DFW policies to your host file system. Some of my customers are using it as a cron job on the host system (with public key authentication for ssh) so they can revert a policy to a previous state whenever needed.

restore-policy

restore-policy -h
usage: restore-policy [options]

Options:
-h : Display help
-f <filename> : restore from this file
-d : delete rules that have been added

This script will restore an individual policy from the specified file. In case rules have been modified or deleted since the backup was taken they will be restored. In case rules have been added, they don’t get deleted automatically, but you get messages like

Rule with ID "rule_added_by_mistake" has been added since the backup
run this command with -d to cleanup

Play with it

If you want to see how these scripts behave, follow these instructions. Caution: Be advised to not do this in a production environment. If you don’t have a test environment, you should at least create all rules in disabled mode.

1. Create a firewall policy
2. Add two rules. Make sure to disable the rules so you don’t interfere with the current configuration

The policy should look similar to this:

You can easily see the rule names by doing the following:

Go into the NSX-T UI and click the three dots at the left of your policy. Then click Copy Path to Clipboard. you can paste the text into the CLI of your container, it will look similar to this:

/infra/domains/default/security-policies/blog-demo

You need to preceed this path by /policy/api/v1. Then run the following command:

GET /policy/api/v1/infra/domains/default/security-policies/blog-demo | jq '.rules[].display_name'

and you will get:
"allow https to web"
"allow-ssh-to-DNS- Servers"

Now run backup-policies using the /data directory to store the JSON files:

backup-policies -d /data

The script will display the name of the directory used in the firyst line of output.

Now add one rule, delete one rule and and rename one rule, the result should look similar to this:

GET /policy/api/v1/infra/domains/default/security-policies/blog-demo | jq '.rules[].display_name'
"New Rule added"
"RENAMED: allow https to web"

The rule "allow-ssh-to-DNS- Servers" has bee deleted.

You can now restore the policy using

restore-policy -f /data/DFW-backup-10.01.2023-14.01.38/blog-demo.json

(use the directory that was created when you backup up the policy)

Let’s see the result now:

GET /policy/api/v1/infra/domains/default/security-policies/blog-demo | jq '.rules[].display_name'
"New Rule added"
"allow https to web"
"allow-ssh-to-DNS- Servers"

So the renamed rule has it’s original name (and settings) again, the deleted rule is back, but the rule that has been added after the backup did not get deleted. In case you also want to delete new rules that have been added after the backup, you need to add the -d option to restore-policy:

restore-policy -d /data/DFW-backup-10.01.2023-14.01.38/blog-demo.json

Now the result looks like this:

GET /policy/api/v1/infra/domains/default/security-policies/blog-demo | jq '.rules[].display_name'
"allow https to web"
"allow-ssh-to-DNS- Servers"

The new rule has been deleted.