Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites [Video]


I also posted this blog about the security benefits of a multi-site Cross-VC NSX solution on the VMware NSX Network Virtualization Blog. The full blog post is provided below and can also be seen on the VMware NSX Network Virtualization Blog site.


Several posts have been written prior on multi-site with Cross-VC NSX describing the fundamentals, use cases, deployment models, and flexibility Cross-VC NSX provides. In this post, we focus on the security benefits of a multi-site Cross-VC NSX solution.


Prior Cross-VC NSX Blogs:
Cross-VC NSX: Multi-site Deployments with Ease and Flexibility
NSX-V: Multi-site Options and Cross-VC NSX Design Guide
Enhanced Disaster Recovery with Cross-VC NSX and SRM
Cross-VC NSX for Multi-site Solutions


So, why multi-site with Cross-VC NSX? The following five reasons should be enough for you to seriously consider Cross-VC NSX as a solution for your multi-site needs:


1.) Centralized Management
Centralized management of security policies across multiple vCenter domains/sites. You have one central location to configure security policies and only write the security policy once, which is then applied across all vCenter domains/sites.

Figure 1 Central Management of Security Policies Across Sites from Primary NSX Manager

Figure 1 Central Management of Security Policies Across Sites from Primary NSX Manager


2.) Consistent Security Across vCenter Domains/Sites
Consistent security policies across vCenter domains/sites provided automatically by Cross-VC NSX enables enhanced workload mobility. Security policies are configured on the primary NSX Manager and automatically synced to the secondary NSX Managers providing for uniform security across all sites.

Figure 2 Consistent Security Across Sites with Universal Distributed Firewall

Figure 2 Consistent Security Across Sites with Universal Distributed Firewall


3.) Security Policies Follow the Workload(s)
Cross-VC NSX enables enhanced workload mobility by making it possible to extend logical networks across multiple vCenter domains/sites. In addition, Cross-VC NSX ensures the security policies follow the workload as it is vMotioned or migrated across vCenter domains/sites.

Figure 3 Security Policies Follow Workloads Across vCenter Domains and Sites

Figure 3 Security Policies Follow Workloads Across vCenter Domains and Sites


4.) Ease of Security Automation Across vCenter Domains/Sites
Security policies can be configured via GUI on the primary NSX Manager and are then automatically synced to the secondary NSX Managers. However, NSX Rest API calls can also be utilized. One NSX REST API call to the primary NSX Manager applies the same security policy across all vCenter domains/sites. As such, the respective API calls can be included in advanced workflows to provide for ease of security automation across vCenter domains/sites.

Figure 4 One NSX REST API Call to Primary NSX Manager to Create Security Policy Allows for Ease of Security Automation

Figure 4 One NSX REST API Call to Primary NSX Manager to Create Security Policy Allows for Ease of Security Automation


5.) Enhanced Disaster Recovery Use Case
Consistent networking and security across sites prevents the need for manual security replication across sites for disaster recovery scenarios. Also, universal logical networking across sites allows for the application IP address to remain the same preventing the need to update security policies.

Figure 5 Applications Recover with Same IP Address and Security Policies

Figure 5 Applications Recover with Same IP Address and Security Policies


Bottom-line is Cross-VC NSX allows for consistent security and micro-segmentation across vCenter boundaries with the Universal Distributed Firewall (UDFW) and Universal Distributed Firewall Rules.

Consistent Security and Micro-segmentation Across Sites via Universal Distributed Firewall

Consistent Security and Micro-segmentation Across Sites via Universal Distributed Firewall


Additionally, the Universal section of the DFW supports the below network and security grouping objects. Grouping objects are used to identify endpoints.


Universal Grouping Objects

  • Universal Security Groups
  • Universal IP Sets
  • Universal MAC Sets
  • Universal Services
  • Universal Service Groups


The demo video at the bottom of this post demonstrates consistent security and micro-segmentation across sites using the UDFW. As shown below in Figure 7, Cross-VC NSX is deployed across two sites. Universal Logical Switches (ULS) exist across both sites for Web, App, and DB tiers of a 3-tier application.


Initially, all the VMs and entire application is at site 1, and a VM on the Web ULS is communicating to a VM on the DB ULS.

Figure 7 Web VM on Web ULS Communicating With DB VM on DB ULS

Figure 7 Web VM on Web ULS Communicating With DB VM on DB ULS


However, VMs on the Web tier should never directly communicate with VMs on the DB tier, and, instead should go through the App tier. As such, a UDFW rule containing Universal Security Groups which contain Universal IP Sets is used to prevent communication between the Web and DB tiers. The UDFW rules are shown below in Figure 8.

Figure 8 UDFW Rules Preventing Communication Between Web and DB Tiers

Figure 8 UDFW Rules Preventing Communication Between Web and DB Tiers


The result of this UDFW configuration, as shown below in Figure 9, is that the Web VM on the Web ULS and the DB VM on the DB ULS can no longer communicate directly, which is the desired result.

Figure 9 Web VM on Web ULS Can No Longer Communicate to DB VM on DB ULS Due to Configured UDFW Rule

Figure 9 Web VM on Web ULS Can No Longer Communicate to DB VM on DB ULS Due to Configured UDFW Rule


As the Web VM or part of the application moves to site 1 as shown below, the security policies for the respective workload follow and consistent security across sites is maintained.

Figure 10 Web VM Moves to Site 2 and Respective Security Policies Follow

Figure 10 Web VM Moves to Site 2 and Respective Security Policies Follow


As the DB VM, or even if the entire application moves to site 2, the application security policies follow the respective workload(s) and consistent security across sites is maintained. This is shown below in Figure 11.

Figure 11 DB VM Moves to Site 2 and Respective Security Policies Follow

Figure 11 DB VM Moves to Site 2 and Respective Security Policies Follow


In the embedded demo video from the VMware NSX YouTube channel at the bottom of this post, I step through and demonstrate consistent security and micro-segmentation across sites using the UDFW as explained above. I also used this demo at VMworld 2016 in the following session: Multisite Networking and Security with Cross-vCenter NSX: Part 2 [NET7861R]; the recording can be watched online once made available.


In a follow-up post to this, I’ll demonstrate how we can leverage third party security services in a Cross-VC NSX environment. A demo of this specific scenario was also shown in the above mentioned VMworld session and will be discussed in detail in the next follow-up post.


In summary, with a Cross-VC NSX multi-site solution, users automatically get central management of security policies, consistent security and micro-segmentation, and ability for ease of advanced security automation across multiple vCenter domains and sites. In addition, the security policies follow the workload(s) across vCenter domains and sites. Also, third party security services can also be leveraged in a Cross-VC NSX environment for additional L7 application-level security as will be demonstrated in the next follow-up post.


Demo: Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites



Twitt

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Leave a Reply

*


six − 5 =