vRA and NSX – Part 3, Security Groups and Policies

Automation, NSX, Tech200, VMware, vRA3 Comments

Introduction

Recapping Part 2 of this series: We staged a number of NSX Logical Switches to be consumed by vRA machines as External Networks. vRA collects and identifies these networks as traditional [vSphere] Network Paths and allows them to be wired for consumption in the Converged Blueprint (CBP) designer as needed (or using custom properties, but that’s beyond this post). Logical Switches can be created for a consumption-only model, automatically created per Deployment when using On-Demand services, or some combination of these.

Moving on…

Similar to it’s relationship with NSX Logical Switches, vRA provides both consumption-based and dynamic security services to deliver a number of use cases leveraging NSX Security Groups and Security Policies.

A Security Group defines — and logically groups — the objects you want to protect (e.g. virtual machines) and the policies that protect them (via a security policy). Group membership can be static or dynamic (e.g. based on logical naming, containers, tags, or as members of other security groups). Pre-created security groups are collected by vRA endpoint inventory and consumed as Existing Security Groups (SG) within the Converged Blueprint designer. These security groups may ultimately contain a combination of unmanaged vSphere VMs and vRA-managed machines.

vra7-327vRA also supports On-Demand Security Groups (ODSG) within CBP, which requires the use of an existing Security Policy.…