I was recently asked by a colleague if we have any existing collateral on VMware vCloud Director (vCD) that maps to the VMware Cloud Provider Program (VCPP) NSX levels that are currently available to partners. Well, there wasn’t, until now. 🙂

First, let’s talk about the NSX bundles inside of VCPP –

There are three levels identified within VCPP:

1. NSX-SP Base – this is is your fundamental level of NSX. It does include your normal Edge services, Edge Firewall, NAT, Load Balancing, Dynamic/Static Routing, IPSEC/SSL VPN+, and Distributed Routing and Switching. This is typically referred to as “vCNS” mode (callout to the vCD old days) but does use NSX.
2. NSX-SP Advanced – this includes Base, plus ECMP and Distributed Firewall functionality. Service Insertion, AD Integrated Firewall, etc. are all functions that the Provider can consume from the backend management.
3. NSX-SP Enterprise – this includes Advanced along with HW VTEP integration, cross-vCenter NSX functionality, along with the L2VPN (Remote Gateway) solution. The new addition here is vCD 9.5 Multi-Site and Cross-VDC capability.

To state the obvious – vCloud Usage Meter will take care of automatic metering based off of what NSX functionality is used, this has been available since version 3.6. Check out this post that discusses how Usage Meter detects NSX (and vROPs) usage.

Last of all, the “Convert to Advanced Gateway” inside of vCloud Director for organization Edges DOES NOT mean you will be using NSX Advanced right away! This is just a change in how vCD presents the Edge UI (with Advanced, it’ll show the H5) along with the API rights available. I demonstrate this in the above post too.

So let’s talk about the NSX levels and how they can pertain to vCD rights and role. I worked up the following roles in my vCD environment:

1. NSX SP-Base Rights
2. NSX SP-Advanced Rights
3. NSX SP-Enterprise Rights

So what does one gain when using these rights? Well, they are now aligned to the VCPP NSX bundles and can be utilized as a starting to monetize NSX inside of a vCD environment.

Now, in my experience, these specific vCD permissions will apply to the VCPP NSX levels as stated above. The big thing I found in my testing is ECMP can be toggled with Static Routing, so I set this as “View Only” for any routing capability for SP-Base.

If you are using vCD 9.5, one could also create a rights bundle that is published to an organization along with utilizing Global Roles to make this *much* easier.

The steps for this would be: Creation of Rights Bundle(s) -> Publish to org(s) -> Creation of Global Roles -> Publish to org(s) -> Apply role to user(s)

Alright, here are the three exports for these rights required. This is not comprehensive for all vCloud permissions required, but gives you an idea of what to append to your existing role (which could be easily done via REST API). Note that the exports below show my vCD instance (vcd-01a.corp.local) along with the org UUID, so replace this if you are doing a POST.

NSX SP-Base:

NSX SP-Advanced:

Finally, NSX-SP Enterprise:

I hope this helps others on aligning to the VCPP NSX levels and how to establish NSX capabilities inside of a vCD environment.

Thanks!

-Daniel

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