This is a joint blog series with Wissam Mahmassani 

Today, we will be discussing pre-configured firewall rules for vApps inside of vCloud Director (vCD).

Recently, I received a request from a new 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.

While this is a Provider managed approach, this is a very simple way of “stamping” out vApps or other required virtual machines that need specific policies applied to them. Moreover, we would like an automatic way to pick up the associated DFW rules so it’s one less step for the Provider.

  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 VMs based on criteria.
  3. The easiest way to do this is by using a dynamic membership policy. We want to apply this group to any VM’s that meet a specific name. In my example, I’m going to be utilizing “mgmt-pod” as my criteria – 
  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. Let’s give it a name – I am using Standard vApp DFW Rules. 
  3. From here, we can click on Firewall Rules and create our rules. In my example, I am 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. I am 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 – 
    1. Solid note from Tom Fojta“Do not forget the order of DFW sections is important. If tenant’s DFW VDC section is above and he creates any-any-allow rule it will nullify provider rules. Tenant sections are created by default on top unless forced with API to be created at the bottom.”

Creating vApp that meets dynamic membership criteria

  1. Now from my Provider UI, I am going to go ahead and create my Management vApp for a new tenant. Again, the context is this would be managed by the Provider initially while we are inheriting the Security Group set forth above. 
  2. Once my vApp is up, I can verify that I am unable to access via ICMP which meets my criteria. We can see the Standard vApp Rule group was associated with the vApp and I am unable to ping it. 

While this is not the only path of securing Provider-managed VM’s for a tenant. Check out Wissam’s approach here by utilizing Resource Pools!


Spread the love

Posted by News Monkey