Automate NSX Micro-Segmentation with vRA 7 – Part 1

I’ve been working with vRealize Automation (vRA) for a few years now, and I’ve seen folks do some pretty impressive things with it. At this point, I think I’ve either seen or heard of just about every integration one could do – IPAM systems, CMDB’s, ServiceNow, application installs, you name it… And the coolest thing about all of these integrations was that they took the previously manual tasks of multiple teams, each of whom had separate SLAs ranging from a few days to a few weeks, and automated those tasks down to just a few minutes. Now that’s progress!

But despite this impressive progress, there still seems to be one last gremlin in our provisioning machine, if you will. You’ll find it lurking around near the end of our process… after all the VMs have spun up, after all the install scripts have run, perhaps even after my cost center has been billed. Before I can use any of my shiny new infrastructure, there is still one very manual step left to do: firewall rules. UGH!

Forgive me, but I am probably my own worst enemy here. My request forms have all the wrong lingo, I don’t utter the right magic words, and I certainly haven’t appeased any angry firewall deities. But then again, why should I have to? After all, this is the era of automation! And I’m a vRA guy!!

It just so happens that I’ve been playing with vRA 7.0 a ton lately, which I’ve found comes with all the built-in NSX integration needed to be able drag-and-drop any of its Micro-Segmentation features onto one’s blueprints. It’s literally that easy now. And speaking from my own experience as an automator, I can say that having the power of all of these features so readily available is a pretty awesome feeling.

Of course I’d be remiss if I didn’t also point out that this plethora of newfound options can be pretty intimidating when one is getting started. My own mental transition from traditional IP-based firewall thinking, to the larger world of NSX’s Micro-Segmentation was a pretty confusing one. After beating my head against all of these new options and features for a while, what finally helped me wrap my head around it all was to put it into the context of 3 basic approaches.

In this article, Part 1 of this series, I’ll walk you through understanding these 3 basic vRA7+NSX Micro-Segmentation approaches:

Since every organization is probably going to have its own unique requirements and scenarios for Micro-Segmentation, the 3 approaches illustrated here aren’t meant to exactly cover every situation out there. They will, however, provide a good frame of reference as you figure out the right strategy for your particular organization.

In Part 2 of this series, we’ll dive into the hands-on, technical details of how to setup each approach.

In Part 3, we’ll go over a bit of NSX troubleshooting, which may come in handy as you’re figuring out your firewall rules.

1. Traditional Security Tiers

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 [painfully?] familiar.

Here are the steps to implement this approach:

In NSX, create a new Security Group to represent each tier. This is just a simple group, similar to what you might create to group computer objects in Active Directory or something – no IP ranges or IP numbers needed here.

In NSX, create all your firewall rules for this group. This includes all the traditional allow/block rules you’re used to, plus an interesting new Micro-Segmentation twist, since rules are not bound to layer 3 (I’ll get to that in a moment).

In vRA, edit your blueprint and drag-and-drop the corresponding Security Group onto the canvas. For example, edit your Apache blueprint and drag-and-drop your “Web Tier” Security Group onto it. Each time vRA provisions a blueprint, it will add the VM(s) to this group.

Interestingly, Micro-Segmentation brings with it an unbelievably cool new aspect to this tiered architecture. I’m talking about the ability to block all communication between VMs inside each tier, even if they are on the same subnet. This is the twist I mentioned – let that sink in for a moment… With Micro-segmentation, we can actually add a single rule to block all traffic within a tier, even on the same subnet. Now I’m sure that all of this bolding and underlining will seem trite if you’re reading this article a few years from now… but right now, as I write this, that capability is INSANE. And really cool.

So to sum up, we create a Security Group in NSX for each tier (web, app, DB), create firewall rules around each Security Group, and then include the Security Groups in their corresponding vRA blueprints.

Pros for this approach

Familiar tiered architecture.

Micro-Segmentation can block all intra-tier communication.

Ideal for securing single-VM blueprints, as opposed to multi-machine blueprints. Since single-VM blueprints don’t have an awareness of their related VMs at request-time, the tiered approach allows you to automatically apply appropriate security even without that awareness.

Cons for this approach

Inter-tier rules are from one whole tier to another – for example, any VM in the web tier will be able to talk to any VM in the app tier, regardless of whether they are part of the same app. That said, this is an accepted limitation of the traditional security tier approach, and it does work well for securing single-VM blueprints. However, for multi-machine blueprints which contain all the required VMs for an app, the other approaches can provide a slightly higher level of security.

2. “App Isolation” Checkbox

When implementing firewall security with the traditional tiered approach we just discussed, one of the first big challenges we typically face is to figure out all of the TCP and UDP ports over which the various tiers will need to communicate with each other. This is a major pain, and often involves a lot of trial and error. The “App Isolation” checkbox, on the other hand, let’s you completely sidestep that hurdle. Instead, App Isolation allows all the VMs within a provisioned multi-machine blueprint to communicate with each other, while simultaneously blocking all external communication other than the designated incoming traffic type (ex: incoming web traffic to the blueprint’s web VMs). It’s also important to point out that each provisioned instance of a multi-machine blueprint is completely separate from the other instances.

This approach lets us sidestep the effort and complexity of the traditional tiered approach by putting a box around all the VMs of a particular blueprint. Not only does that allow us to skip figuring out all of the communication ports, but since each app becomes self-contained it also avoids exposure to inter-tier security breaches like we mentioned in the Cons of the previous approach.

In order to achieve this benefit, vRA needs to know about all of the VMs for a given app at provisioning-time – this means that all of the VMs for a particular app must be defined as a multi-machine blueprint. Then, inside the multi-machine blueprint, we simply check the App Isolation checkbox. That’s it! Once checked, vRA will automatically create an On-Demand Security Group (i.e. the “box”) and its corresponding firewall rules each time the blueprint is provisioned. And when you de-provision instances of the blueprint, vRA will automatically clean-up all the Security Groups and rules that it had previously created. How nice is that?

Here are the steps to implement this approach:

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

In NSX, create a single Security Group and corresponding firewall rule(s) for incoming traffic only (ex: Web) – we do not need to create Security Groups and firewall rules for multiple tiers.

In vRA, edit your blueprint and drag-and-drop the “Web” Security Group onto the canvas.

In the blueprint Properties, check the App Isolation checkbox. The next time vRA provisions this blueprint, it will automatically create an On-Demand Security group and corresponding firewall rules, specific to the newly-provisioned VMs.

So to sum up, this approach has less Security Groups, less firewall rules, better east/west security, and all for one low price: a checkbox!

Pros for this approach

This is the Easy Button for isolating all the VMs of a multi-machine blueprint. No need to figure out all the ports these VMs will need for communication with each other.

Limits a hacker’s east/west movement to just the VMs within that app. No exposure to inter-tier security breaches.

Cons for this approach

Not applicable to single-VM blueprints.

Doesn’t Micro-Segment between the VMs within a multi-machine blueprint. All machines within a multi-machine blueprint will be able to communicate with each other.

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

I am a huge fan of the first 2 approaches. To recap, both approaches offer vastly-improved protections over traditional firewalls for limiting a hacker’s east/west movement through the data center. The tiered approach offers intra-tier Micro-Segmentation regardless of subnets – a previously unheard of feat for the traditional firewall. And vRA’s App Isolation checkbox limits east/west movement to just the handful of VMs within its multi-machine blueprint – an equally impressive Micro-Segmentation feat, made possible by automation. I love both of these approaches. And while they’re easy and a great fit for most scenarios, there will still be times when we need to turn our security up to 11.

And that’s where this third approach comes in. This approach leverages the On-Demand Security Groups to which we were introduced in the previous approach, and expands on their use to give us even more granular control of each app’s security. By using multiple On-Demand Security Groups, this approach 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

Instead of checking the App Isolation checkbox, for this approach we will drag-and-drop multiple On-Demand Security Groups onto our multi-machine blueprint. vRA will create unique instances of these Security Groups each time the blueprint is provisioned.

Security Policies

These are templates for firewall rules. When vRA creates an On-Demand Security Group within NSX, it can also create firewall rules for those groups with 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:

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

Minimizes the number of rules we need – since the Default is to Block, we can concentrate on just making rules for Allows, and not bother with individual Block rules.

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). This should be mostly Allow rules, since the default rule is now Block.

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 On-Demand Security Group with the corresponding Security Policy.

To sum up, this option leverages the best of both automation and Micro-Segmentation to maximize security. vRA automatically creates Security Groups and firewall rules specific to those groups, for each application, as that application (i.e. multi-machine blueprint) is provisioned. And just like we saw with the App Isolation checkbox, when a multi-machine blueprint is de-provisioned, vRA will automatically clean-up all the Security Groups and firewall rules that it had previously created.

Pros for this approach

Leverages the best of automation and Micro-Segmentation for maximum granularity of security.

Regardless of the Cons below, this approach is still far less work than manually managing traditional firewall rules – especially considering there isn’t a single IP# or subnet involved, and vRA’s de-provisioning process will clean up all groups and rules that it previously created during provisioning. Not even the best manual de-provisioning processes for traditional firewalls can approach that level of hygiene.

Cons for this approach

Like the App Isolation checkbox, it’s not applicable to single-VM blueprints.

More things to manage in NSX than the previous 2 approaches. We’ll need to create Security Policies for each type of traffic, and vRA will add/update Security Groups and firewall rules each time a blueprint is provisioned.

Weigh Your Options

While I would love to simply point you to “the best” vRA Micro-Segmentation approach, each organization’s needs are unique, and each approach has its place. After reading this article, if the right approach for your organization isn’t jumping out at you, then go ahead and try them all – in Part 2 of this series we’ll see the hands-on setup steps for each approach.

Have fun automating and best of luck as you weigh your vRA Micro-Segmentation options!