vRA and NSX – Using Baseline Security Groups

vRA and NSX came together back when vRA (a.k.a. vCAC) 6.0 was released, just as VMware was transitioning from vCNS to NSX. In vRA 6.x, inventory-collected security groups must be selected (checked) per Reservation prior to being available for consumption by a multi-machine blueprint (and only MMBP’s support NSX in vRA 6.x). As I’ve highlighted several times before, the latest release of vRealize Automation (7.x) delivers deeper integrations with NSX and unified service authoring capabilities to make delivering application-centric networks the new norm. See this post for how vRA and NSX are better together…I won’t repeat those details here.

With vRA 7’s deeper integration and broader use cases, one hugely powerful feature is the ability to incorporate one or more NSX Security Groups — either Pre-Existing or On-Demand — into your service design using the new Converged Blueprint Designer (CBP). You simply drag-and-drop the security group right on to the unified canvas and bind it to the desired machine components…

As a result, the provisioned machines are automatically added to the security group (Existing Security Group) or a new security group is dynamically created and bound to an existing security policy at request (On-Demand Security Group). And, of course, this is all undone at machine decommissioning. But while the CBP is most often featured when demonstrating NSX integration, there actually are other methods for injecting the goodness of NSX into day-to-day machine provisioning.

Baseline Security Groups

While all the benefits of CBP’s capability have been covered in much detail, there is an important use case that often goes unmentioned — setting a baseline security group that is automatically bound to all machines in a particular Reservation. In other words, it’s a security group that always applies regardless of whether or not it is dragged on to the canvas…a baseline of sorts.

As an example use case, let’s assume you are provisioning machines into a Reservation representing resources in a DMZ. While admins have been granted the ability to consume existing or on-demand security groups within their app designs, a basic set of policies may be required for all machines provisioned into that DMZ. And while this can be done on the back-end, this method provides more control, granularity and per-reservation enforcement.

Baseline security groups are added per-reservation in vRA and currently apply only to vSphere reservations…

Once the desired security is selected, all machines provisioned into that reservation will be automatically covered. This can be verified by checking group membership of a provisioned machine in the vSphere Web Client or checking the security group itself in NSX Service Composer…

   Security Group Membership in vSphere Web Client

   Security Group Membership in Service Composer

Any number of security groups can be added to the reservation and they will all be appended as a baseline at provisioning time — even if the blueprint isn’t explicitly configured for NSX. Just be sure best practices are followed when creating security groups to keep things manageable and prevent unnecessary troubleshooting.

Enjoy!

+++++
virtualjad