Automate NSX Micro-Segmentation with vRA 7 – Part 2

In Part 1 of this series, we did a conceptual walk-through of 3 basic NSX + vRA7 Micro-Segmentation approaches. We compared the pro’s and con’s of each approach, and talked about the situations in which you would be most likely to employ each one. In this article, we’ll actually be doing the hands-on setup for each approach. Also, since this article focuses solely on Micro-Segmentation functionality (the NSX Distributed Firewall), we will not need to configure any Logical Switches, VXLANs, or Edges/routing.

My goal here is to give you a good, technical feel for each of the 3 previously-discussed Micro-Segmentation approaches, so that you have a solid foundation from which to build whatever Micro-Segmentation strategy you need for your particular organization’s scenarios.

Getting Started

First, you’ll need to setup a lab environment with vRA 7 and NSX. In my lab I was running vRA v7.0 and NSX v6.2. For help installing vRA and NSX in your lab, here are links to some good installation guides: vRA, NSX. Just a basic NSX setup will do – as I mentioned earlier, you won’t need any Logical Switches, VXLANs, or Edges/routing in order to use the NSX Distributed Firewall for Micro-Segmentation. Once you have both vRA and NSX installed, you’ll still need to add the NSX info into a couple places in vRA to get it talking to NSX. Here is a quick guide: Start Using NSX In your vRA Blueprints!

The next thing I did in my lab was to setup some general firewall rules to allow vRA-related communication. In the screenshot below, I created the “Core Services” section, which allows all the VMs being provisioned to communicate with the vRA appliance(s) and vRA IaaS server(s) over HTTPS. As a refresher, don’t forget that the way NSX processes rules is by starting at the top of the list, and as soon as it hits a rule-match, it applies that rule and then stops processing. So if a communication stream matches Rule #1 (HTTPS traffic to a vRA server), for example, NSX will apply rule #1 and then ignore all other rules.

I left the “Default Section Layer3” section with all the OOTB defaults in the screen below.

Rule #2, above, allows DNS lookups, which is required for the provisioned VMs to find vRA. Rule #3 allows me to connect to any Linux VM in my lab via SSH. Rather than define “All Linux Servers” in terms of an IP range or some other archaic method, I simply created an “All Linux Servers” Security Group that included a list of vCenter’s OS name strings.

Side note – in order for NSX to read the OS from the target VM during rule processing, the VM must have VMware Tools installed. Additionally, if I would have included any Windows Server VMs in my lab’s vRA catalog, then I probably would have also created a similar Security Group for Windows VMs, and corresponding firewall rules for RDP, Active Directory, etc.

1. Traditional Security Tiers

As I mentioned in Part 1, the first place I started when I began pulling NSX constructs into my vRA7 blueprints was to recreate the traditional 3-tier (web, app, DB) security architecture with which most of us are familiar. And because we’re using NSX, Micro-Segmentation gives us the added benefit of being able to block all communication between VMs inside each tier, even if they are on the same subnet.

Here are the steps to implement this approach

In NSX, create a new Security Group to represent each tier. To keep things a little simpler in my lab, I just created Security Groups for 2 tiers: “Web Tier” and “DB Tier” (no “app tier”).In order for our new NSX Security Groups to show up in vRA, we’ll either need to wait for vRA’s daily Data Collection, or manually initiate a Data Collection.To initiate a Data Collection, navigate to any Compute Resource in vRA, mouse over it, and click Data Collection. In Data Collection, scroll down to the bottom, and in the “Network and Security Inventory” section, click “Request now.”
.

In NSX, create firewall rules for each Security Group.As you can see, I created two sections of firewall rules – one for my Web Tier, and one for my DB Tier. I allowed all web traffic into the Web Tier, but only allowed outgoing MySQL traffic to the DB Tier. For the DB Tier, I allowed all incoming MySQL traffic from the Web Tier, and blocked everything else. Rules #8 and #12 are the rules I mentioned that block all intra-tier VM communication, even if they are on the same subnet!
.

In vRA, edit your blueprint and drag-and-drop the corresponding Security Group(s) onto the canvas.In this example, I created a blueprint for a web server. First, I dragged an “Existing Security Group” object onto the canvas and configured it for the “Web Tier” Security Group. Second, I clicked on the VM in my blueprint, apache-web. Third, with the apache-web VM highlighted, I clicked the Security tab. Forth, I checked the box to link the “Web Tier” Security Group to the apache-web VM.I then repeated this process to link my other Web and DB blueprints to their respective security tiers.

2. App Isolation Checkbox

Instead of figuring out all the ports over which the various app tiers need to communicate with each other, and then defining tiers for that communication like we did in the previous approach, this approach simply allows all the VMs within a multi-machine blueprint to communicate with each other, while simultaneously blocking non-web external communication.

Here are the steps to implement this approach

In vRA, create a multi-machine blueprint so that vRA knows about all the VMs for that app during provisioning.

In NSX, create a single Security Group and corresponding Allow firewall rule for incoming traffic only (ex: Allow incoming HTTP/HTTPS). There is a screenshot of the firewall rules further down, in the section called “Looking behind the curtain.”

In vRA, run a Data Collection for “Network and Security Inventory” so that vRA knows about the new Security Group (like we did in the previous example).

In vRA, edit your blueprint and drag-and-drop the Security Group for your incoming traffic, Web, onto the canvas. Link it to the web VM.

In the blueprint Properties, check the “App Isolation” checkbox.

Looking behind the curtain

Now let’s take a closer look at the firewall rules for this example. You’ll notice there are firewall rules that I created (Web section), as well as the App Isolation firewall rules that vRA created automatically during provisioning.

I’ve left the “Core Services” and “Default Section Layer3” sections unchanged from the previous example.

vRA automatically created a “VCAC App Isolation Policy” section (rules 5-7) toward the bottom of the rules list, just above the “Default Section Layer3” section. It will add additional Security Groups and rules to this section each time an blueprint with “App Isolation” is provisioned.

As you can see, the rules in the “VCAC App Isolation Policy” section allow intra-group communication, but block all external communication. Since vRA automatically put this section toward the bottom of the list, the “Web” section that I manually created beforehand is higher on the list (#4), and therefore allows web traffic into the blueprint’s web VM(s). Also notice how much simpler the “Web” section is, compared with the “Web Tier” section of the previous example (1 rule vs. 5).

3. On-Demand Groups and Firewall Rules for each App

This approach leverages the On-Demand Security Groups that we were introduced to in the previous approach, and expands on their use to give us even more granular control of each app’s security. Similar to how the blueprint’s App Isolation checkbox created an On-Demand Security Group to put a box around all of its VMs during provisioning, using multiple On-Demand Security Groups lets us put boxes around not only the perimeter of a blueprint, but also around groups of VMs inside the blueprint.

Here’s a rundown of the Micro-Segmentation features we’ll leverage for this approach:

On-Demand Security Groups

Use them to create groups of VMs within a multi-machine blueprint.

These groups correspond to the type of traffic involved, such as Web traffic, App traffic, and DB traffic.

Groups will typically include both the source and destination of a particular type of traffic. For example, a “DB Traffic” Security Group would include both the app VMs (source) and DB VMs (destination).

Security Policies

These are templates for firewall rules. When vRA creates an On-Demand Security Group within NSX, it will also create firewall rules for those groups using Security Policies. So you can think of Security Policies as the “On-Demand” firewall rules to go with our On-Demand Security Groups.

For example, if vRA creates a “DB traffic” On-Demand Security Group during provisioning, it could then use a “DB traffic” Security Policy to create the associated firewall rules to allow MySQL or SQL Server traffic within that group.

Default Rule: Block Any/Any/Any

Changing NSX’s Default Rule (the last rule, at the bottom of the Firewall rules list) from Allow to Block does 2 things:

Minimize the number of rules we need – since the Default is to Block, we can concentrate on just making Allow rules in our Security Policies.

Maximize security – any traffic we didn’t create a rule for will be blocked.

Here are the steps to implement this approach

In NSX, change the Default Rule from Allow to Block.

In NSX, create a Security Policy for each type of traffic (ex: Web, App, DB). These should contain mostly Allow rules, since the default rule is now Block. For App and DB traffic security groups, the Security Policy will likely contain a single rule. Here is the DB Security Policy from my lab, which just allows intra-group MySQL traffic:Web traffic is a little more complex than App or DB, since it needs to allow incoming traffic from outside the multi-machine blueprint, as well as preventing Web servers from communicating with each other. You can ignore rule #4 – I was temporarily allowing pings during some testing.

In vRA, create a multi-machine blueprint so that vRA knows about all the VMs for the app during provisioning.

In vRA, edit your blueprint and drag-and-drop an On-Demand Security Group onto the canvas for each type of traffic (ex: Web, App, DB). Link each Security Group to the source and destination VMs – for example, DB_Traffic is linked to both the Web VM (source) and the DB VM (destination).Next, click on each On-Demand Security Group and link it with the corresponding Security Policy.

Looking behind the curtain

Once vRA has provisioned an instance of your multi-machine blueprint, you should be able to see the On-Demand Security Groups it created in NSX. It will create additional groups each time the blueprint is provisioned.

You can also see the corresponding firewall rules that vRA created, on-demand.

Note that we didn’t need to use the App Isolation checkbox for this approach. Our Security Policies and On-Demand Groups provided granular enough security that the additional On-Demand Security Group and rules wouldn’t have increased security.

Up Next…

Hopefully you didn’t run into too much trouble setting these examples up in your lab. If you did though, in Part 3 we’ll do some troubleshooting, including how I fixed some of the noob mistakes I ran into when I was setting up my lab.