So what is a security policy, and why do we need them? At its heart, the security component of VMware Cloud on AWS is NSX-T. If you’re familiar with NSX concepts, then you’re going to be at home here! If not, read on.
The Management Gateway (MGW) and Compute Gateway (CGW) are what’s known in NSX-T as T1 routers. You can think of these in a similar way to the Distributed Logical Router in NSX-V. These two routers are then connected up to the T0 router, which provides connectivity in and out of the SDDC. As always, a picture paints a thousand words.
Virtual Machines connect to Network Segments, which are roughly analogous to a VLAN. Unlike a traditional VLAN, however we can use policies to enforce microsegmentation through the Distributed Firewall (DFW). In a traditional VLAN or subnet, every machine in the same subnetwork can communicate with every other because you enforce security at the default gateway of the network (typically a firewall). We show this in the below diagram.
To define which VMs should be able to communicate with which other VMs and over which ports and protocols we define these rules in the VMware Cloud on AWS console. These rules are the VMware Cloud on AWS security policies.
Building a Security Policy
If you’ve ever managed a firewall some (maybe all!) of the following may be familiar. A security policy comprises of a source, a destination, a service, an action and whether or not you want to log the activity. To help you build your rules most efficiently, you can utilize Security Groups to define your sources, destination and services. These Security Groups can contain IP addresses, VM Instance, VM name and Security Tags. Before we get started, let’s have a target state. Here we show 2 multi-tier apps that we’re going to deploy. Notice that each tier resides in the same subnet for both apps. I wouldn’t recommend this approach in a traditional datacenter, because if one of the Multi-Tier Apps had a machine compromised they could be used to attack the other app. Using microsegmentation this isn’t an issue, because we firewall every virtual NIC.
Create Security Groups
First things first, we need to build some groups. Login to the VMware Cloud on AWS console and select your SDDC, then click Networking & Security, browse down to Inventory>Groups in the left hand column. Select Workload Groups, then click Add Group.
Create the groups you need – for my example I’m going to create the following groups.
Finance-Web
Finance-App
Finance-DB
Sharepoint-Web
Sharepoint-App
Sharepoint-DB
Web-Servers
There are multiple ways to determine what causes a virtual machine to be a member of these groups. We do this by selecting the VMs in question, based on IP address or by selecting up to 5 “Membership Criteria”. I’ll show you how.
Give the group a name, under Member Type select Membership Criteria, then click the blue Set Membership Criteria link under Members.
Enter the criteria that you wish to use. Here, I’m just going to use a tag, but you could use a combination of up to 5 criteria.
Click Save, then Save again. Now all VMs that receive the tag Finance-Web will be a member of the Finance-Web security group. We can use this group as a source or a destination rather than using IP addresses or needing to specify every VM in the ruleset. Capabilities like this can be super helpful when working with dynamic workloads. Below we can see all of the groups created using the same method.
Building The Ruleset
In terms of Services, the VMware Cloud on AWS console comes with a whole bunch predefined. We define a Service as the ports and protocols required to service a function. It might be a single port (for example: SMB uses TCP 445 as a destination). It could be many ports (for example the VMware ESXi Log Dump Collector runs on UDP 6500 and TCP 8000). Alternatively it could be a specific service type (for example IGMP). You can see the defined services by clicking Inventory > Services in the Networking and Security tab of your SDDC.
If you need to define a new custom service you can do so by clicking Add New Service and running through the wizard. Let’s set some rules based on the groups that we created earlier. Under the Networking & Security tab browse to Security > Distributed Firewall.
Click Add New Section to create a new rule section for the first multi-tier app. Name the section, then add your first rule. Here, we’re going to add a rule to allow members of the Finance-Web group to communicate with members of the Finance-App group over TCP 5480. We’re also going to log this traffic into Log Intelligence.
I’ll go through and build out the rest of these rules in line with the application desired state detailed above. Below we can see the full ruleset.
Note that at this point these rules are not in use – we need to publish them. To do this scroll up in the DFW section and click Publish.
Congratulations – We’ve now deployed our first security policies! As you can see, it’s super easy to build flexible policies to secure your environment. We assess VMware Cloud on AWS security policy rules from the top down. If you’re troubleshooting a rule that should be applied lower down the ruleset it’s always worth ruling out a rule above it that conflicts. You should also know that if you create rules based on IP address then a guest administrator could easily login to their VM and change the IP address. The impact of this would be to potentially cause a rule to no longer take effect. That’s the reason I’m such a fan of tags!
And on that note, we’re pretty much done with all of the technical content in this series. I’ll be back next week with a content wrap-up, but I’d like to thank you for following along with this set of blogposts. If this has piqued your interest then check out the links below!
Congratulations – We’ve now deployed our first security policies! As you can see, it’s super easy to build flexible policies to secure your environment. We assess VMware Cloud on AWS security policy rules from the top down. If you’re troubleshooting a rule that should be applied lower down the ruleset it’s always worth ruling out a rule above it that conflicts. You should also know that if you create rules based on IP address then a guest administrator could easily login to their VM and change the IP address. The impact of this would be to potentially cause a rule to no longer take effect. That’s the reason I’m such a fan of tags!
