NSX-V 6.3: Cross-VC NSX Security Enhancements

NSX-V 6.2 introduced the Cross-NSX feature to allow for NSX logical networking and security across multiple vCenter domains. The ability to apply consistent networking and security across vCenter domains provides for mulitple use cases for Cross-VC NSX: workload mobility, resource pooling, multi-site security, ease of automation across sites, and disaster avoidance/recovery. With the recent release of NSX-V 6.3, several enhancements have been added to the Cross-VC NSX feature to provide for additional capabilities and overall robustness of the solution. In this blog post I’ll discuss the new Cross-VC NSX security enhancements in NSX-V 6.3. For additional information on Cross-VC NSX check-out my prior Cross-VC NSX blog posts.

The security enhancements for Cross-VC NSX can be grouped into two categories:

General Enhancements (Apply Across both Active/Active and Active/Standby deployment models)
Enhancements for Active/Standby Use Case

Active/Active and Active/Standby above refers to if the application is active at both sites or if it is active at one site and standby at another site (ex: disaster recovery). Enhancements for both of these respective categories are discussed in more detail below.

1.) General Enhancements (Apply Across both Active/Active and Active/Standby deployment models)

Figure 1: Cross-VC NSX Active/Standby and Active/Active Deployment Model

– Multiple Universal Sections for Universal Distributed Firewall (UDFW)

Prior to NSX 6.3, only one universal section was possible for UDFW; NSX 6.3 allows for multiple universal sections.

Figure 2: Multiple Universal Sections for UDFW

Multiple universal sections gives us efficiency in terms of the following:

If rules are modified/edited within a universal section, only UDFW rules for that section are synced to the Secondary NSX Managers

Rules can easily be organized per tenant/application

In addition to the above, with NSX-V 6.3, universal sections are always above local sections, even on the Primary NSX Manager. Prior, this was only the case on Secondary NSX Managers. On the Primary NSX Manager, it was still possible to move the local sections above the universal sections. For consistency, all universal sections must now be above the local sections. This makes sense from a security perspective where the local site security policies should never override the global security policies set by the global security admin.

– Enhancements to ApplyTo (Universal Security Groups can be used)

The ApplyTo feature is a critical feature used to efficiently apply security policies to only the VMs/workloads that require the policy; this feature helps in terms of performance and scalability. ApplyTo also works with UDFW, however, prior to NSX-V 6.3, UDFW could only use Universal Logical Switch with ApplyTo. In summary, this ApplyTo behavior had two affects:

The most granular a universal security policy could be applied was at the Universal Logical Switch level, meaning all VMs/workloads on the Universal Logical switch would get the security policy applied to its vNIC

If a user wanted to deploy just security/micro-segmentation without deploying network virtualization, the user was not able to leverage ApplyTo since it only worked with Universal Logical Switch

With NSX-V 6.3, ApplyTo can now leverage Universal Security Groups (USGs) with new dynamic matching criteria of VM Name or static matching criteria of Universal Security Tag; this allows for more granular application of universal security policies at the VM level. Additionally, users can now leverage ApplyTo even in cases where network virtualization is not being utilized, for example, a deployment leveraging NSX just for the benefits of Cross-VC NSX multi-site security.

Figure 3: Leveraging Universal Security Group with ApplyTo in UDFW

2.) Enhancements for Active/Standby Use Case

Figure 4: Cross-VC NSX Active/Standby Deployment Model

– Universal Security Tags

Starting NSX-V 6.3, Cross-VC NSX supports Universal Security Tags. When a Universal Security Tag is created on the Primary NSX Manager, it’s automatically synced to the Secondary NSX Manager(s) as shown below.

Figure 5: Universal Security Tag Creation and Sync

As mentioned prior, these enhancements are more applicable to Active/Standby use cases such as disaster recovery (DR). So when a VM is vMotioned or recovered at a secondary site, the Secondary NSX Manager needs some method of attaching the correct security tag to the correct VM. The Unique ID Selection Criteria setting under Installation–>Management–>Actions on the Primary NSX Manager is used to achieve this as shown in Figure 6 below.

For the Unique ID Selection Criteria, Virtual Machine Instance UUID is typically sufficient for cases such as disaster recovery with VMware’s Site Recovery Manager (SRM) and vMotion. Virtual Machine Instance UUID is guaranteed to be unique for each VM within a specific vCenter; it’s not guaranteed to be unique across different vCenters, but it’s rare for there to be overlap since each Virtual Machine Instance UUID is also based on a unique vCenter ID. vSphere Replication and vMotion will both maintain the Virtual Machine Instance UUID of the VM at the recovery/secondary site. The user has the option to use different or multiple selection criteria based on their environment. If each VM in the environment has a unique VM name, VM name can also be used for the unique selection criteria to ensure the correct security tags are attached to the correct VMs.

Figure 6: Setting Unique Selection Criteria

Figure 7 below shows the flow in terms of utilizing Universal Security Tags for Active/Standby deployments.

Figure 7: Flow for Utilizing Universal Security Tags in Active/Standby Deployments

– Universal Security Group with New Matching Criteria

In NSX-V 6.3, UDFW rules can now leverage Universal Security Groups with new matching criteria of:

VM Name (dynamic)

Universal Security Tag (static)

Since UDFW rules can now use Universal Security Groups based on VM Name and Universal Security Tag, security policies can be more fluid and not rely on IP addresses.

Figure 8: Using VM Name Matching Criteria in Universal Security Group

Figure 9: Using Universal Security Tag Matching Criteria in Universal Security Group

Figure 10 below shows, Universal Security Groups with matching criteria of Universal Security Tags being used in a UDFW rule.

Figure 10: Leveraging Universal Security Group with Universal Security Tag in UDFW Rule

As mentioned prior, it’s important to note enhancements listed here are applicable primarily for Active/Standby use cases such as DR. The reason for this is the local NSX Manager does not have visibility into the inventory of the other NSX Managers’ vCenters. Thus, when a security rule is utilized with the Universal Security Groups leveraging the new supported matching criteria of VM Name or Universal Security Tag in the source/destination fields, since the translation of the security group happens locally, only the VMs/workloads in the local vCenter will be found as members of the security group.

Thus, when leveraging Universal Security Groups with the new supported matching criteria, the entire application must be at the same site as shown below in Figure 11. For example, if the application is spanning across sites and there is Cross-VC traffic flows, the security policy for the application will not provide the desired results.