Posted by Many asked so here it is. A how to guide on leveraging Tags and Security Groups to apply Firewall Policies/Rules to groups of VMs. My main goal for this article is to simplify a complicated 2.4 Admin Guide, which does not spell out how to do this in step by step options. The Admin Guide still requires bouncing around different sections with some NSX-T knowledge to figure it out. Here is a simplified version of all that.
If you would like assistance in the below or have general questions about Cloud solutions, VMware, and more, feel free to visit the following URL and I will be able to work directly with you:
https://bit.ly/3qcNxsN
Conventional security ass-u-me that everything on the inside of your network can be trusted. Zero trust logic is the opposite, trust nothing and verify everything. Zero trust addresses the sophisticated of attacks and threats from the inside that expose a perimeter security approach. Benefit of Micro-Segmentation is the ability to logically divides a Datacenter into distinct security segments down to the individual workload VM Level. Leveraging Distributed Firewalls it monitors the state of active connections an uses this information to determine which packets transverse the VM vNIC.
My preferred method is to make sure your naming convention is uniform in your environment and just leverage Security Groups setup via VM Name. However, if you don’t have a uniform naming convention then Tags will be the easiest alternative.
For the sake of this article I will remain in NSX-T only. This will make tagging every VM a manual per-VM & per-tag approach. Yes, this is the only thing I do not like about the process so far. Since vCenter is decoupled from NSX-T the tags you have applied in vCenter are not populated into NSX-T, which would make our lives a lot easier. Without another solution like vRA & vRA BluePrints you will be stuck doing a lot of manual work. Since I don’t assume everyone has the entire Vmware Suites, we will stay within NSX-T for this article.
***Side note: I highly highly highly recommend getting the vRealize Suite. Not just to get vRA to help automate the creation of Tags but also to get Lifecycle Manager & Operations. Also, I highly recommend getting Network Insight.
Terminology & definitions:
Tags:
A virtual machine is not directly managed by NSX however, NSX allows attachment of tags to a virtual machine. This tagging enables tag based grouping of objects (IE, you can apply a Tag called Kronos for all your Kronos Tags). You can add tags to objects to make searching much easier, which is why NSX Manager uses tags to group VMs
Security Groups:
Security Groups enables you to assign resources, such as virtual machines and network adapters, for distributed firewall protection. In addition to Tags you can also use a grouping of VMs to orchestrate policy. They can be based on VM attributed such as VM name, OS, IP, Ports, etc. For instance, you have VMs in your environment that must be under PCI compliance. Newly created VMs that also have this requirement can automatically inherit the appropriate policies.
Security Policies:
Each firewall rule contains policies that act as instructions that determine whether a packet should be allow or blocked, which protocols it is allowed to use, which ports it is allowed to use, etc. Policies can be stateful or stateless.
Sounds simple enough right? It even comes with an easy 3 step process to apply “Micro-Segmentation” in your environment.
Step 1.
Evaluate your environment. Take an application running in your environment and all their associated VMs. Then you must determine what network traffic and access is required for that application to work in your environment while being as secure as possible.
Step2.
Create policies to restrict traffic flow. The moment you do this you lower the attack surface by only allowing the application access to resources it needs to function.
Step 3.
Create a Group for that application and align the policies created for that application. The goal here is to easily group VMs together and enforce their intended state and behavior.
We have these easy definitions and even an easy 3 step process to define the scope of our Tags/Policies/Groups. Now let’s see it in action. You may need to click around in NSX Manager a tad bit.
Step by Step Process:
Advanced Networking & Security>Inventory>Virtual Machines
This is where you will find all the virtual machines running in your NSX-T environment. Select the VM you want to create a tag for. Our example is for a Tier 1 Web server running in our environment.
**you can only select one at a time.
Click Manage
We are going to take this as a DMZ VM that lives in Non-Prod.
You can easily select the VM & click on the 1 in the far right to see the Tag that is applied to this VM.
Now it is time to create our Group
I’m creating a Group called Non-Production-DMZ for all our DMZ traffic living in Non-Prod that exists inside our Production Datacenter.
Inventory>Groups>Add Group
Now that we’ve added a tag manually to our VM in this example, let us create a Group to associate the VM with.
Give the Group a name: Non-Production-DMZ
Select a Domain: Production
Set Members: Opens a new screen to set criteria for our members.
There are many options to choose from here but since we want this group to leverage tags we are going with Virtual Machine>Tag>Equals>Non-Production-DMZ>Apply
Save
Once your save click view members to see if our T1-Web-03 VM is now a member of this group
Now that we have our VM tagged and it is now in a Security Group associated with its workload type. How about we create and apply firewall policies to this group?
Security>East West Security>Distributed Firewall>Add Policy
First we must create a new firewall policy and then create rules associated with that policy.
Just click on the name New Policy and it will allow you to edit. Then click on default next to Domain and it will allow you to select the Production Domain that our Security Group is associated with.
To keep things simple I name the policy after the Group I want to associate it with.
Click the 3xdots next to the policy name and select add rule
You will now be prompted to provide the following information:
Name it
Select a source
Select a destination
Select services
Select profiles
Applied to
Action
Since we want DMZ traffic to communicate with DMZ traffic I am making this rule simple Allow-DMZ-to-DMZ
As the source we are selecting our Group we created earlier and selecting apply. This part of the rule is stating where the traffic will originate from.
Then we set the destination as the same Group since we want to enable the ability to communicate with other DMZ VMs. This part of the rule is stating where the traffic will go to.
Switch to Groups instead of DFW. Select the Group we created earlier. Then apply.
For this new Policy & Rule to take effect we must Publish it.
Summary:
You should now have a VM called Web-03 that has a Tag applied which makes it a member to a Security Group. That Security Group should have a new Policy/Rule applied to it that affects all VMs in your Security Group. I kept this very simple for my easy how to guide but you could end up creating 100 rules for your policy to tailor how you want the traffic to be allowed or not allowed. Also, you can go through and Tag all of your DMZ VMs and have a Security Group with dozens of DMZ VMs that these Policies/Rules are applied too.
Before you ask, yes it is a painful process. However, if you don’t have a solid naming convention in your environment then my preferred method of creating Security Groups leveraging VM names will not work. Tags are a great way to get around not having a uniform naming convention in your environment. Leveraging vRA will make this manual process a lot easier.
With Micro-Segmentation and having the ability to put a stateful firewall on the vNIC of each VM allows you to better secure your environment and quarantine a VM should it be exposed without affecting other VMs in your environment. The ability to group VMs together in a security group allows for a consistent secure environment based on the applications. Tags allow you to ensure similar VMs supporting a particular application are kept in the appreciate Security Group with the proper rule sets maintained.
What I enjoy most? I can now have Workload 1 and Workload 2 living side by side but with Distributed Firewall Rules the two shall never communicate adhering to governance.
Happy hunting and customizing different security groups with different policies/rules. I hope these guideline helps you on your journey.