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:

Creation of a Security Group with Dynamic Membership
Creation of a Security Policy
Activating Security Policy against Security Group
Creating vApp that meets dynamic membership criteria

Creation of a Security Group with Dynamic Membership

Navigate to Menu -> Networking and Security -> Service Composer
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 pool RP2

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

Creation of a Security Policy

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

Now, we are ready to apply our newly created policy to our group. Click the Apply button while your newly created policy is selected –
From the pop-up window, we will select our Standard vApp Rule group as a Selected Object –
Success – now we can see it has been applied –
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!