The VMware NSX network virtualization platform allows us to build sophisticated networking and security constructs in software. NSX has a rich RESTful API which allows one to build highly flexible and automated environments. In this blog, we’re going to focus on operations and automation; we’ll demonstrate one example of automation around security policies/rules that can be done with NSX.

VMware NSX allows for micro-segmentation with a distributed firewall service (DFW). The DFW is a kernel-level module and allows for enhanced segmentation and security across a virtualized environment. One of the common questions we get asked is, “how do I decide what rules to build?” NSX allows for multiple options to create rules such as the use of NSX flow-monitoring or analyzing traffic patterns via logging to create the rules.

We’ll demonstrate how the VMware NSX DFW can be monitored with the popular Splunk platform. Further, we’ll demonstrate, along with using Splunk for monitoring traffic passing through the DFW, how the NSX REST API can be leveraged to automate workflows and creation of DFW rules.

Figure 1: VMware NSX DFW Central Configuration

Figure 1: VMware NSX DFW Central Configuration

The VMware NSX App for Splunk is an application for the Splunk monitoring platform. It’s provided as a ‘.tgz’ file and can be installed by directly uploading the file via Splunk GUI web app. A minimum Splunk version of 6.1.x is required.

Figure 2: Installing VMware NSX App for Splunk

Figure 2: Installing VMware NSX App for Splunk

Figure 3: Splunk DFW Overview View

Figure 3: Splunk DFW Overview View

The scenario demoed in the video further below shows the following:

  1. Initially, a user has two clients/tenants, Vendor 1 and Vendor 2, communicating to different nodes and these nodes are unknown.
  2. The source is always known as either Vendor 1 or Vendor 2, because the VMs have been applied a security tag of Vendor 1 or Vendor 2 upon boot-up.
  3. The destination is not known, so initially, all Vendor 1 and Vendor 2 traffic is allowed, and, as traffic passes, it’s logged and passed to Splunk. Besides a few DFW rules for system/mgmt traffic, all other traffic is blocked.
  4. Python and NSX REST API are leveraged to use the information from Splunk to automatically create more granular DFW rules for Vendor 1 and Vendor 2, and, once complete, the general DFW firewall rules allowing all traffic for Vendor 1 and Vendor 2 are deleted, leaving behind the granular Vendor 1 and Vendor 2 security rules.

It is important to note that this is just a demonstration to show some of the possibilities around automation. In practice, you wouldn’t want to automatically create DFW rules based on what’s already being allowed without some sort of manual intervention or review, however, this demonstration shows that capabilities and what’s possible.

A more realistic scenario would be to send the Splunk data to a custom application, where the user can review and approve/deny the creation of the DFW rules. Such a workflow would look like that shown below in Figure 4.

Figure 4: Workflow for Creating DFW Rules via Splunk data and NSX REST API

Figure 4: Workflow for Creating DFW Rules via Splunk data and NSX REST API

The above video demonstrates the creation of DFW rules based on Splunk data and leveraging Python and the NSX REST API.

For more information on VMware NSX, NSX REST API, and Splunk, see the below links. The VMware NSX App for Splunk is available through VMware. NSX Product Page   Spunk Product Page   NSX 6.0. API Guide   NSX 6.1 API Guide   NSX 6.2 API Guide

Humair