VMware NSX Service Composer: Advanced Security & Micro-segmentation

In a prior blog, Firewalling & Micro-segmentation with VMware NSX, I discussed some of the basics of firewalls and micro-segmentation with VMware NSX. In this blog, I’ll introduce how security groups via NSX Service Composer can be used with VMware NSX to further enhance the micro-segmentation and security capabilities.

Security groups can easily be defined via the NSX Service Composer and allow 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. Policies can be configured based on the built-in VMware NSX features or by those offered by 3rd party solutions.

The really cool aspect of this is it allows membership to the security group to be defined dynamically, so firewall/security services can be provisioned to applications in real time. For instance, one can simply apply a rule stating all VM’s that start with the word Web in their name should have the policy via the security group applied to them. So, in short, security policies can be dynamically assigned to groups of VMs via security groups. Additionally, since membership to the security group is defined dynamically, the policy is also applied to new VMs as they are automatically added to the group based on prior defined match conditions. How cool is that?

In a nutshell, NSX Service Composer follows a simple four step workflow:

1. Defining security groups and respective membership
2. Provisioning services to be applied
3. Applying services to defined groups
4. Automating application services by defining conditional rules

The lab setup is based on the NSX design explained in my prior blog, Dell Networking and VMware NSX: Bridging Logical & Physical Networks. The physical infrastructure consists of all Dell hardware: Dell blade & rack PowerEdge servers (R620s, M620s), Dell network switches (S6000s, S4810s, MXLs) and Dell iSCSI EqualLogic storage. VMware NSX is deployed on a complete end-to-end converged infrastructure; you can read the full Dell + VMware NSX Reference Architecture here. The logical network design is shown below.The logical network design is shown below.

VMware NSX Logical Network Lab Diagram

There are five logical switches: Bridged-App Tier, Web Tier, App Tier, DB Tier, and Transit Network. I’ve actually replicated this logical environment twice for a total of three tenants and fifteen logical switches, but the focus for this lab is only on the Tenant 1 environment.

Below, it’s confirmed that the Web Tier logical switch has two VMs named WebVM and WebVM1.

Confirming 'Web Tier' logical switch has two VMs named 'WebVM' and 'WebVM1'

Using Service Composer, only a default security group exists as shown in the screenshot of the Canvas view below. The security group container defines how the container and it’s respective members are being protected. I’ll define a new security group to include all VMs within the Tenant 1 environment that start with the word Web; this will uniquely identify all the Tenant 1 web server VMs.

Default security group container in NSX Service Composer

Step 1: Click the New Security Group button marked with the green + symbol.

NSX Service Composer: Naming a new security group

Step 2: Create the rule for dynamic membership into the security group; in this case, any VM that has a name that starts with Web.

NSX Service Composer: Creating the rule for dynamic membership into the security rule

Step 3: Determine if there is any other objects to include; in this case, no.

NSX Service Composer: Determining if there are any other objects to include

Step 4: Determine if there are any other objects to exclude; in this case, we will exclude the VMs that may match on the Web Tier logical switches for Tenant 2 and Tenant 3. To keep things brief, I’m just excluding the respective Tenant 2 and Tenant 3 logical switches; in reality, it would make more sense to also use a security group for the objects I want to exclude as it would provide a more robust and dynamic conditional, capturing objects that match even in future created logical switches.

The interesting thing here is, it is possible, if desired, to create a security group that spans multiple tenants! This can be incredibly useful in saving time when one wants to replicate some security service/rules across tenants.

NSX Service Composer: Determining if there are any other objects to exclude

Step 5: Review and confirm the configuration for the security group.

NSX Service Composer: Reviewing and confirming the configuration for the security group

As you can see below, the security group has been created and two VMs have been automatically identified and added to the security group as shown by the number 2 in the bottom left of the respective container. Any additional VMs that are created later will also be added to the security group if they match the defined security group conditions.

NSX Service Composer: 'Tenant1 Web Servers' security group created

By clicking the Security Groups tab, it can clearly be seen that two VMs have been added as part of the Tenant1 Web Servers security group.

NSX Service Composer: Confirming number of members of security group 'Tenant1 Web Servers'

Now, I’ll define another security group in the same manner for all Tenant 1 VMs that have a name that starts with the word DB. This will uniquely identify all Tenant 1 database server VMs. The final result is shown below; three security groups now exist.

NSX Service Composer: Defined security groups

Note, the tan little scroll icon on the top right of each security group container. It shows that no security policies are currently applied to either one of the security groups just created. Next, I’ll create a security policy to deny the Tenant 1 web server VMs access to the Tenant 1 database server VMs.

By clicking the Security Policies tab and adding a security policy as shown below, one can see different types of security services that can be added to the security group; there are several 3rd party vendors that provide these additional types of security services, and service composer can be used to integrate these additional 3rd party security services into the NSX environment.

Service chaining can be accomplished in this manner where a logical pipeline within the vNIC context is formed and advanced security policies are applied. For example, one may want to add antivirus capabilities with Symantec’s NSX Data Center security products.

Palo Alto Networks also offers an advanced firewall for VMware NSX; one benefit is it allows for central management of distributed virtual and physical firewalls with Palo Alto’s Panorama product.

A complete list of VMware NSX partners can be found here.

NSX Service Composer: Creating a security policy with different security type

Below, I create a simple security policy with only firewall rules applied.

First, click the Create Security Policy icon shown with the green + and name it as desired.

NSX Service Composer: Naming a new security policy

Next, click through to the Firewall Rules section and configure a firewall rule as shown below.

NSX Service Composer: Setting a firewall rule leveraging security groups

NSX Service Composer: Configured firewall rule leveraging security groups

Finally, click through and click the Finish button to see the below final result.

NSX Service Composer: Configured security policy

Now, I’ll apply this security policy to the Tenant 1 Web Servers security group created earlier. By clicking the tan small scroll icon on the top right of the respective container, and clicking the second icon button from the left, the security policy just created can be applied to the security group.

NSX Service Composer: No applied security policies

Below, I select the Tenant 1 Security Policy created earlier. This will prevent the dynamically identified members in our Tenant 1 Web Servers security group from accessing the Tenant 1 database server VMs identified by the Tenant 1 DB Servers security group.

NSX Service Composer: Applying security policy to security group

Now, as shown below, I can see the number 1 next to the security profile and firewall icons within the container. Pretty cool stuff!

NSX Service Composer: Configured security groups

I can quickly confirm the security policy is implemented correctly by seeing if one of the Tenant 1 web server VMs can ping the Tenant 1 database server VM. As shown below, the validation is successful, as the VMs are unable to communicate with each other.

Validation Passes: Tenant 1 web server VM cannot ping Tenant 1 database server VM

The other thing that should be mentioned is that security groups can also be used as objects when defining rules in the standard distributed firewall menu outside of the service composer as shown below. VMware NSX provides a tremendous amount of flexibility in how security and what types of security is applied within a virtualized environment.

Distributed firewall rule leveraging security groups