Automating Security Group and Policy Creation with NSX REST API

As we’ve seen in many of the prior posts, VMware NSX is a powerful platform decoupling networking services from physical infrastructure. NSX effectively enables logical networking and security within a virtualized environment; this brings many of the same benefits we’re familiar with gaining from server virtualization such as flexibility, faster provisioning, better utilization of hardware, cost savings, decreased downtime, etc. One of the major benefits of the software approach that NSX brings is the ability to automate easily via REST API. In this post, we’ll take a look at a simple yet realistic use case focused around security where automation can help. 

Imagine creating a security posture and having to 1.) identify workloads and 2.) identify what security policies need to be applied to respective identified workloads.

With NSX, a user can create what is known as Security Groups. Security Groups can easily be defined via the NSX Service Composer or via the Grouping Objects section (NSX Managers->[Select NSX Manager]->Manage->Grouping Objects->Security Groups) and allows for a unique model in consuming network and security services. Objects such as virtual machines (VMs) across which similar policies will be applied can be defined in a Security Group, and a consistent policy can then easily be mapped across all respective objects. Further, the objects can be dynamically included within these Security Groups. Security policies leveraging these Security Groups can then be configured based on the built-in VMware NSX features or by those offered by 3rd party solutions.

Figure 1 displays the logical diagram of the setup used in this demonstration.

Figure 1: Example NSX Logical Network

Figure 2 displays a screenshot from NSX 6.2.2 where it shows a Web Security Group already created with one dynamically identified VM that’s included as part of the Security Group; this correlates to the diagram above in Figure 1. It should be noted here that the Web Security Group is only being used locally on a local logical switch. The screenshot below shows the NSX Manager role as Primary because the deployment is part of a Cross-VC NSX deployment, but in this case only local objects and no universal objects are being used. To learn more about Cross-VC NSX and universal objects, see the prior post, Cross-VC NSX for Multi-site Solutions.

The Security Groups and policies we are discussing are for local objects within one vCenter domain. We will discuss security across multiple vCenter domains and universal security rules later in this post as there are some specific caveats in this respective scenario.

Figure 2: NSX Security Groups as Seen via Service Composer

Figure 3 below shows the dynamic membership criteria that an object must meet to be part of the Web Security Group. In this case the VM just has to contain the word Web in the VM Name.

Figure 3: Dynamic Membership Criteria for Inclusion Into ‘Web’ Security Group

Currently, from Figure 1, it can be seen that the Web Security Group has been created yet the Security Group is not yet utilized in any security rules/policies. The procedural steps for creating the security posture in this case are:

1. Identify workload traffic

2. Create Security Groups to dynamically include workloads that should be included as part of the Security Group. This will help determine what security policies should be applied to the specific workloads based on requirements.

3. Create security policies leveraging created Security Groups

Let’s apply this scenario to a larger scale; depending on specific environment and workloads, there can potentially be many Security Groups and respective security policies that need to be created. Let’s assume the end user has 100+ Security Groups that need to be created. It can become tedious if one has to create so many Security Groups manually. One method of automation can be to leverage the NSX REST API and a bit of code. In this case we’ll demonstrate with Python, however, any programming language can be used, and, most languages have a REST library making things super easy.

For our example, first, we create a CSV file with one Security Group per row. Each row has two fields; the first field is the Security Group name, and, the second field is the matching criteria, or, in this case, specifically the word to match in the VM name (meaning, if the VM name contains this word, the VM will meet the criteria to dynamically be added to respective Security Group). The fields per row are separated via a comma within a CSV file. Figure 4 below shows a screenshot of the file used as input to the python script in this example. Note, we demonstrate using just three Security Groups here based on our setup but many more as needed can be added and created with this batch-type Security Group creation script.

Figure 4: CSV File Containing Security Group Data and Used as Input to Python Script

By running the below python script, which reads in the CSV file as input and leverages the respective NSX REST API calls, all the Security Groups in the CSV file with the respective dynamic matching criteria are created.

The full python code is displayed in the scroll-box below and was run in this example with NSX 6.2.2. First, the needed python libraries are imported, python variables used for the script are set, and a reader object is created to iterate over the lines in the CSV file. The python requests library is leveraged for the NSX REST API call and the python csv library is leveraged for reading and parsing the CSV input file.

Next, the python script iterates through the CSV file data via loop reading the CSV data line by line and the respective NSX REST API to create the Security Group is called. The security_group python list variable contains two items, security_group[0], which contains the Security Group name, and, security_group[1], which contains the Security Group matching criteria for dynamic inclusion as discussed prior. For each iteration through the list, the NSX REST API call is made to create the respective Security Group.

Figure 7 below shows the results within NSX. As expected, based on the diagram in Figure 1, three Security Groups have been created each with one member VM. Note, the prior Web Security Group is still present which displays the same number of dynamically identified VMs as the Web Security Group created via python script, thus further validating the results.

Figure 7: Successful Results of Running Python Script to Create Security Groups

In this example, we created Security Groups to be leveraged by local security rules which should next be created and which can also be automated. These security rules can then leverage the auto-created Security Groups. A useful document for reference is the NSX REST API Guide.

In addition, with the Cross-VC NSX feature, introduced in NSX 6.2, it is also possible to create universal security rules that span across multiple vCenter domains and possibly multiple sites. To learn more about Cross-VC NSX see the prior post, Cross-VC NSX for Multi-site Solutions.

In such a scenario, one may have a deployment that looks similar to that shown in Figure 8. The same methodology as mentioned above can be leveraged with Cross-VC NSX for Security Groups used in universal security rules, however, vCenter and NSX objects such as VM name and logical switch are currently not supported with universal security rules. IP Sets and MAC Sets can be used for inclusion criteria when creating Security Groups for use with universal security rules.

Figure 8: Example Cross-VC NSX Deployment Leveraging Universal Objects

Figure 9 displays App, DB, and Web universal Security Groups leveraging IP Sets as seen on the NSX Manager at site 1.

Figure 9: Security Groups as Seen on the NSX Manager at Site 1

Looking at the NSX Manager at site 2 in Figure 10, the same Security Groups can be seen that were create via the Primary NSX Manager at site 1 as the Security Groups were created with Universal scope.

Figure 10: Security Groups as Seen on the NSX Manager at Site 2

By leveraging the Cross-VC NSX feature it’s possible to utilize the NSX REST API just on the Primary NSX Manager and create a unified security policy across all vCenter domain/sites as illustrated via Figure 11.

Figure 11: Universal Security Group and Universal Security Policy Creation via NSX REST API