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:
- Identify workload traffic
- 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.
- 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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 |
#Script: create_security_groups.py # #Description: Script reads input from a CSV file and creates Security Groups with dynamic inclusion #criteria. Used with NSX 6.2.2 and Python 2.7.11. For additional information, see the following article: #http://blogs.vmware.com/networkvirtualization/2016/04/nsx-automating-security-group.html # #Copyright © 2016 VMware, Inc. All Rights Reserved. #This script is provided as-is under GPLv2 license and with no guarantee, warranty, or support. # #See the below posted applicable license and notice. #GPL Projects COPYING File (GPLv2): http://blogs.vmware.com/networkvirtualization/gpl-projects-copying-gplv2 #GPL Projects NOTICE (GPLv2): http://blogs.vmware.com/networkvirtualization/gpl-projects-notice-gplv2 import csv #library used for reading and parsing data from CSV file import requests #library used for making REST API calls #ignore specific warnings from requests.packages.urllib3.exceptions import InsecureRequestWarning requests.packages.urllib3.disable_warnings(InsecureRequestWarning) #initialize variables with needed info for input file and to make NSX REST API call nsx_username = "nsxadmin" nsx_password = "notMyPassword!" nsx_url = "https://10.100.1.72/api/2.0/services/securitygroup/bulk/globalroot-0" csv_filename = "security_groups.csv" myheaders={'content-type':'application/xml'} try: csv_file = open(cv_filename) #open CSV file for reading except FileNotFoundError as e: print "Input CSV file not found!" try: csv_data = csv.reader(csv_file) #get reader object to iterate over lines in CSV file except IOError as e: print "Error reading CSV file!" for security_group in cv_data: #loop through parsed lines read in from CSV file #print security_group[0] #uncomment for debugging - contains Security Group name #print security_group[1] #uncomment for debugging - contains Security Group word to match in VM name #create XML payload with Security Group data read in from CSV file payload =''' <securitygroup> <objectId>securitygroup-1</objectId> <objectTypeName>SecurityGroup</objectTypeName> <vsmUuid>422B2F08-25CF-AE4D-D78E-9450BA33618F</vsmUuid> <nodeId>d4fa9b9f-7973-4971-9ae6-c8f7e693ab30</nodeId> <revision>1</revision> <type> <typeName>SecurityGroup</typeName> </type> <name>''' + security_group[0] + '''</name> <description> </description> <scope> <id>globalroot-0</id> <objectTypeName>GlobalRoot</objectTypeName> <name>Global</name> </scope> <clientHandle> </clientHandle> <extendedAttributes/> <isUniversal>false</isUniversal> <universalRevision>0</universalRevision> <inheritanceAllowed>false</inheritanceAllowed> <dynamicMemberDefinition> <dynamicSet> <operator>OR</operator> <dynamicCriteria> <operator>OR</operator> <key>VM.NAME</key> <criteria>contains</criteria> <value>''' + security_group[1] + '''</value> <isValid>true</isValid> </dynamicCriteria> </dynamicSet> </dynamicMemberDefinition> </securitygroup>''' #print payload #uncomment this for debugging - payload for REST API request call #call NSX REST API to create Security Group with XML payload just created try: response = requests.post(nsx_url, data=payload, headers=myheaders, auth=(nsx_username,nsx_password), verify=False) except requests.exceptions.ConnectionError as e: print "Connection error!" print response.text |
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
Comments
0 Comments have been added so far