By Russell Pope
I was working with a customer recently who was looking to deploy a NSX distributed firewall. They loved the idea of ‘microsegmentation,’ but at the same time had some concerns around managing a lot of the firewall rules at scale. The big question was: “How do I avoid having to manage firewall rules for individual VMs? That seems like a lot of effort.”
After a bit of white boarding, I decided we should check out VMware NSX’s ‘Service Composer’ feature. I pulled it up in our lab (the Kovarus Proven Solutions Center) so we could see it in action. I figured it would be easier to understand once everyone could see how it gets set up.
We created a series of dynamic groups (called ‘Security Groups’ in NSX parlance) and attached some basic policies to them. One of the more useful features in the service composer is the ability to dynamically determine membership based on a wide variety of potential criteria.
So what does putting together a NSX distributed firewall look like?
When you click on Service Composer, it will take you to the Security Groups view. Here we can create new Security Groups or view information about existing ones. We’ll go ahead and create a new Security Group by clicking the ‘New Security Group’ button. This will launch a wizard where we can define the criteria for dynamic membership.
First, let’s name our group:
Now we can define our membership.
We can create as many conditions as we like and can either say ‘match any of these’ or ‘match all of these.’ You can match by the following criteria:
• Computer OS Name – The actual name of the guest operating system. For example: ‘Windows 2003 Server’
• VM Name – The name of the virtual machines in the vCenter inventory (for example, if it contains ‘web’)
• Computer Name – The actual hostname of the virtual machine in the guest OS
• Security Tag – A special tag that you can apply using NSX for vSphere (more on this later!)
• Entity – Base membership on some other entity that NSX for vSphere understands
We’ll look more closely at entity since this one has a LOT of options. For example, we can select a specific cluster, portgroup, Data Center, resource pool or a number of other criteria.
VM name, the computer OS name, computer name, security tag or you’ll see a value called ‘entity.’ For our example, I’m going to hit ‘entity’, select a security tag, and pick ‘dev-desktop’:
I did it this way so I could be specific. You could actually just select ‘Security Tag’ and ‘contains’ to get the same result but then you’d have to remember what the tag actually was.
When we hit ‘next’, it’s now going to ask what objects to include. This allows us to ensure that systems that don’t meet the previous criteria get added if we need them. For example, we might want to add specific VMs or other security groups to this one that we’re unable to tag for whatever reason. We’ll go ahead and hit ‘next’.
It will now ask what objects we want to exclude. This is where we can remove specific virtual machines, clusters, etc. from the security group. We’ll go ahead and finish the wizard.
So, now I’ve got this new security group but there’s nothing in it:
Now let’s go build some policies!
When you click the ‘new policy’ button, another wizard launches. It’s going to want you to name and describe the policy (you can have it inherit another policy). There’s an advanced option for ‘weight’ which allows you to determine which policy takes priority in the event there is overlap. Highest weight will win in this case.
We’ll skip over guest introspection services for now and go right to firewall rules. Here, we’ll just create a few basic test rules. We’ll allow RDP in and active directory out. For RDP in, we’re going to give it a name, set the action to allow and change the source to ‘Any.’ The destination we’re going to set to ‘Policy’s Security Groups.’ What this will do is say “anything this policy happens to be applied to, let’s allow it RDP in! We do this so we can re-use some of our more common rules.
We then need to set the service we want to allow in. For this case, we want AD:
We won’t worry too much about logging, but make sure to leave the state ‘enabled.’
At this point, we’ll go ahead and add the rule to let it talk out to AD. It’s a lot of the same steps; except for the ‘Destination,’ which we’re actually going to change to ‘Select Security Groups’ then pick our ‘infrastructure-services’ security group. I made this group earlier and it contains my AD servers for the lab.
For the ‘Service,’ I’m going to change it and hit the ‘Select services and service groups’ radio button. NSX for vSphere comes with a variety of pre-configured service groups which define a series of ports for various applications. I’m using the canned ‘Microsoft Active Directory’ service group here, but you can also build your own:
Now, I have a second firewall rule ready. I could create more for different applications or I could re-use existing ones.
I’m going to go ahead and finish the wizard (we’ll get into network introspection in another post!)
I can now apply this security policy to a security group:
I can select one or more security groups. I’ll just pick our ‘Development-Desktops’ group for now. What this means is that every firewall rule in that security policy will be applied to every virtual machine contained in that security group. If I go to the canvas view, I can see I have a new group called ‘Development-Desktops’ and it has one policy, two firewall rules, and no virtual machines applied to it:
Let’s go fix that! Go into your vCenter inventory and find a test VM or two (make sure you’re looking at ‘Security Tags’ and not ‘Tags’!):
From here, we can check the tag we want to apply:
Once the tag is applied, it should look like this:
You can apply more than one tag to virtual machines as well. We’re keeping it simple. You can also apply security tags from NSX manager, which may be handy if you want to do it in bulk and don’t feel like writing a script to do it. Go back to Network and Security→ NSX Managers and select your NSX manager instance. Click the security tag you want to add VMs to and hit the ‘Assign Security Tag’ button.
Select your virtual machines and hit ‘OK’:
Now, we have some virtual machines in our security group:
What’s really nice is that our firewall configuration still looks pretty clean:
So, instead of seeing 12 rules (because we have six VMs), we just see the two rules. If I build more developer desktops, I just need to apply that security tag to them and they’ll end up with the exact same rules applied. If I’m using an automation tool like vRealize Automation, then I can just add the tag as a part of my provisioning workflow.
It’s a little bit of upfront work but it’s going to pay off in the long term. If you’d like to do a workshop with us to go into more detail, please feel free to reach out to us to schedule a Kovarus Proven Solutions Center workshop!