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

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.

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 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!

-Daniel

7 thoughts on “Security Compliance – Pre-configure your vApp firewall rules inside vCloud Director using NSX DFW (Part 1 of 2)”

  1. Thanks for sharing this great article Daniel!

    I was thinking about a similar use case for the Service Compose but I was not happy with the situation that the rule are not visible in vCD DFW UI. Was this “problem” discussed?

  2. Hey Markus,

    Thanks for the comments!

    As for not being visible in the vCD DFW UI, keep in mind that is in the context of the orgID folder. This use case is Provider-managed and should be abstracted away from the tenant. If it was in the construct of the tenant (and UI), an org admin would be able to modify these rules which may not be acceptable to the Provider.

    I have taken this to Engineering as something to kick around – perhaps a separate interface for Provider-only managed DFW rules.

    Cheers!

    -Daniel

    1. A separate interface for Provider-only managed DFW Rules in OrgVDC context might be awsome!
      But I’m afraid that this is tricky to realize because of the missing link to the OrgVDC (like the section naming for the tenant rules).

  3. 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 section’s are created by default on top unless forced with API to be created at the bottom.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.