Security Compliance – Pre-configure your vApp firewall rules inside vCloud Director using NSX DFW (Part 2 of 2)

This is a joint blog series with Daniel Paluszek .

We will be discussing  how to achieve security compliance inside vCloud Director’s  future workloads  by pre-configuring native NSX DFW rules.

The use-case came from a new cloud provider that wants to deploy a specific vApp when they onboard a new tenant (or organization). This specific vApp will need to have NSX Distributed Firewall rules in place – the vApp will be the same for every tenant and will need to be secured accordingly and hence achieve compliance.

 

Daniel discussed a great method of creating an NSX security group with Dynamic Membership and that uses VM name as the dynamic construct.The caveat in that is the Provider/Tenant MUST create the vApps with names that match the dynamic membership created natively in NSX.

 

My method would be based on using the Resource Pool ORG-ID  instead of the VM name as the construct used in my dynamic membership criteria with the Caveat that the Provider will have to add each ORG that needs such compliance to this security group.

Tenants can pick any name for their workloads vApps/VMs and still comply with the Firewall rules that are pre-enforced.

 

 

 

Overall Steps:

  1. Creation of a Security Group with Dynamic Membership
  2. Creation of a Security Policy
  3. Activating Security Policy against Security Group
  4. Creating vApp that meets dynamic membership criteria

 

Creation of a Security Group with Dynamic Membership

  1. Navigate to Menu -> Networking and Security -> Service Composer
  2. The first thing we are going to do is create a Security Group that will associate the dynamic membership based on entity criteria.

 


3. We want to apply this group to any VM inside the Org vDC. For that, we will be using Resource Pool Org-ID entity in the dynamic membership criteria.

ORG-IDs are generated for each Org vDC inside vCD. We can be import them as a VC object inside Dynamic Security Group Membership by using the “Resource Pool” as an entity . Hence, the Org vDC should pre-exist in order to pre-configure the native Firewall rules to achieve the compliance needed or we can simply add the newly created ones to the same security group on day 2.

 

Note that you will have to include every Org vDC you create/created that will need this kind of security compliance. 

 

resource poolRP2

 

4. Click Finish, and we are off to the next step.

 

Creation of a Security Policy

  1. Let’s click on the Security Policies tab inside of Service Composer and create a new Security Policy –

2.  give it a name – We are using Standard vApp DFW Rules. 

3. From here, we can click on Firewall Rules and create our rules. In our example, We are going to let HTTPS traffic in and block everything else. Typically, for micro-seg rules, we would create granular rules to secure all types of traffic. We are using these just as an example.

4. Creating DFW policies is fairly straightforward in the Service Composer –

Activating Security Policy against Security Group

  1. Now, we are ready to apply our newly created policy to our group. Click the Apply button while your newly created policy is selected – 
  2. From the pop-up window, we will select our Standard vApp Rule group as a Selected Object – 
  3. Success – now we can see it has been applied – 
  4. From the DFW view, we can see a new section created with associated DFW rules – 

 

 

No need to go through specifics of creating the vAPP that meets criteria as all vAPPs/VMs that are part of the pre-provisioned Org ID will automatically have the security compliance. However, take note that you will need to add each ORG-VDC’s resource pool into that policy to achieve compliance.

 

While this is not the only path of securing Provider-managed VM’s for a tenant. Check out Daniel’s bog post for his approach!

Comparing Centralized Firewalls to NSX Distributed Firewall DFW – The apples to oranges comparison

Solution Architects and often Security Engineers design Data Centers in a way that they can achieve the highest level of security with the highest performance possible . Often Firewalls are installed and configured to protect workloads from unauthorized access and comply with security policies. VMware introduced the NSX distributed firewall concept which changed the centralized mindset and raised the firewall component to a completely different level.

Although comparing the centralized to distributed firewalls Architecture and capabilities is like comparing apples to oranges, Architects and Network Admins would often request such a comparison to try visualize the new mindset VMware NSX DFW brought into the game.

In the next series of blogs I will show you how NSX DFW compare to the Traditional Centralized Firewalls (The apple to orange comparison). I will also share with you the best practices in achieving Line rate performance/throughput when using NSX DFW along with the results of the performance testings.

So how do Centralized and Distributed Firewalls compare?

Traditionally, Firewalls were centralized and are typically physical boxes that process the packets and take the “allow/drop” decisions based on pre-configured rules. Traffic will be typically hair-pinned to those Firewall boxes when being processed.

VMware NSX Distributed Firewall or often called DFW, introduced a new concept by Distributing the Firewall capability across all compute hypervisors without the need of making the traffic exit to another hop for the allow/drop traffic decision processing .

Traditional FWs will often need the packets sourced/destined to be filtered via the firewall box itself. Hence for large data centers, Firewall throughput is considered a key concern with respect to bottlenecks in the data processing. Scaling a centralized Firewall would often be challenging  whenever the datacenter traffic is exceeding the box’s limit. Network/Security Admins will need to purchase additional firewalls to cascade with the existing ones or often a rip and replace would be needed to accommodate the new demanding throughput needs. (yes

NSX DFW changes the concept of Centralized Firewall and introduced a new perception in the architectural design of Firewalls. With NSX DFW, the Security team can protect the workload at the Virtual Machine’s vNic level. By rules being processed at the vNic, decisions of allowing or dropping packets sourced from the DFW protected VMs is taken even before the packet exits the hypervisor the VM lives on.

Picture1

Traditional FW technologies are fixed based on initial purchase of technology (i.e. 40Gbps FW)

Compared to…

NSX which scales based on the amount of ESXi hosts which already exist in your environment running the VM workloads

Therefore, when we talk about scaling –

  • Traditional FW technologies will require a rip/replace or physical upgrade to mitigate any performance bottlenecks/hairpinning along with potential architecture redesign
  • Compared to VMware NSX which linearly adds performance as we add ESXi hosts to scale VM workloads… not to mention that the ESXI hosts already exist in your Data center (lower CAPEX)

 

as we addNSX performance scales

What is the most powerful differentiator? 

One of the most powerful features of NSX DFW in my opinion is the ability to create firewall rules based on static and dynamic membership criteria. Security groups construct is introduced which is an extremely efficient tool  to implement security policies or firewall rules based on those security groups defined. Security Groups can be leveraged to either create Static or Dynamic Inclusion based rules.

Static inclusion provides the capability to manually include particular objects into the security groups such as Specific Cluster, Logical Switch, vAPP, Data Center , IP Sets, Active Directory group, Mac Sets, Security tag, vNic, VM, Resource Pool and DVS Port Group.

5

Dynamic Inclusion would include Computer OS name, Computer Name, VM name, Security tag and Entity.

RDecker-3

For instance you can create a firewall rule that will allow HTTPS access to all VMs that have the word “web” in their VM name. Or perhaps create firewall rules based on Security tags where a tag can be associated with a specific tenant workloads in the Service Provider world.

 

Ofcourse, The FW rules configured move with the VM as it vMotions across NSX prepared hosts!

 

In Summary:

 

 

1

Traditional FW Technologies  

VMware NSX DFW

 

CLI-Centric FW Model Distributed at hypervisor level
Hair-pinning Mitigation of hair-pinning due to kernel-decision processing vs the centralized model
Static Configuration Dynamic, API based Configuration
IP Address-Based Rules Static and Dynamic Firewall constructs which includes VM Name, VC Objects and Identity-based Rules
Fixed Throughput per Appliance

(i.e. 40Gbps)

Line Rate ~ 20 Gbps per host (with 2 * 10 Gbps pNics).

~ 80 GBps per host (with 2 * 40 Gbps Nic Cards and MTU 8900).

Lack of visibility with encapsulated traffic Full Visibility to encapsulated traffic

 

 

 

In my next blogs, I will show you the testings made to the NSX DFW throughput and what are the best practices to achieve LINE-RATE performance.

 

 

 Big thank you to my peer Daniel Paluszek for motivating me to start blogging and for giving me feedback on this post. You can follow his amazing blog here