Migrate to the Cloud Scale on Demand VMware Network Insight Cloud

NSX Cloud – Choice of Agented or Agentless Modes of Operation

No organization is a single entity. Each one is made up of dozens of different lines of business, and each of these may want different modes of operation to meet their particular business or security objectives. Discover how NSX Enforced Mode and Cloud Enforced Mode deliver flexibility to operate the way you need with agented and agentless modes of operation.

This blog was originally published here.

 

VMware NSX through its NSX Cloud offering enables customers to implement a consistent networking and security framework for workloads hosted across on-premises data center (DC) and public clouds such as AWS and Azure.

Every cloud orchestration and management tool, immaterial of what use case it has set out to solve has one question to answer: If it is an agent-based solution or an agentless solution. More often than not, the answer to this question has direct implications for the ability of the cloud admin team to deploy and manage the solution.

But, do we really have to choose?! What if we can have both agented and agentless modes of operation?! That’s the question we asked ourselves with VMware NSX and here we are with NSX-T 2.5.

 

Meet the New NSX Cloud Modes of Operation

What is NSX Enforced Mode?

NSX Enforced Mode provides a “consistent” security and networking policy framework between your on-premises DC and public cloud environment. You can have a unified–corporate-wide-firewall-policy which will be enforced as an NSX Policy, by having an nsx footprint inside each virtual machine running in the cloud.

Why is it Required?

Well, NSX architecture has 3 layers:

  • Management-plane
  • Control-plane
  • Data-plane

Within the data center, the NSX data-plane is deployed at the hypervisor layer of each physical host. However, in a public cloud, you, as a customer, do not have access to deploy anything at the physical host level. Hence, for public cloud workloads, we are required to deploy the NSX data-plane as an agent, i.e., nsxtools. One can think of nsxtools to be similar to that of ‘vmtools’ within each workload VM running on-premises. Nsxtools allows us to enable the full feature set of NSX directly within each workload VM running in public cloud since it gives us a data-plane presence. Features such as NSX distributed Firewall (DFW), policy-based traffic routing, and many more are enabled because of nsxtools.

As we add more and more NSX goodness, all these features will be available for your public cloud workloads when you are in NSX Enforced Mode. Now, we also realize the operational challenges that deploying and managing an agent brings on, hence, we have automated a large portion of the nsxtools lifecycle management, right from deployment (auto-deploy through Azure VM Extensions etc.) and all the way into managing all upgrades directly through NSX.

 

Introducing Cloud Enforced Mode in NSX-T 2.5

For customers that cannot deploy nsxtools within their cloud VM workloads, but still need a consistent security/networking policy framework across on-premises  Data Center and public cloud, we now introduce the Cloud Enforced Mode in NSX-T 2.5.

Cloud Enforced Mode provides a “common” security and networking policy framework between your on-premises DC and public cloud environment. You can still continue to have a unified–corporate-wide-firewall-policy. Instead of being enforced as an NSX policy, it will be translated into the respective public cloud’s native security constructs. You do not need any footprint of NSX (aka nsxtools) in your public cloud workloads. As there is no footprint in the workload, policy enforcement is done directly by leveraging native cloud capabilities.

To put things into perspective, here is a snapshot of what your NSX deployment would look like:

  • NSX Manager and Cloud Service Manager comprise the management and control plane of NSX. They will be hosted in your on-premises DC.
  • You could have a DirectConnect, ExpressRoute, or site-to-site VPN connection from your on-premises DC to your public cloud environment.
  • In your transit VPC/VNet (a.k.a. service VPC/VNet or hub VPC/VNet), we deploy NSX Public Cloud Gateway (PCG). Think of PCG as an NSX edge footprint hosted in public cloud.
  • And finally, your data plane will be your workloads operating on either of the two modes.

 

How Does the Mapping Work in Cloud Enforced Mode?

Here are two snapshots showing the mapping of NSX Distributed Firewall(DFW) Policy to Native Security Groups in AWS and Azure.

Snapshot of NSX DFW policy translated to Native AWS Security Groups

 

 

Snapshot of NSX DFW policy translated to Native Azure Security Groups

 

 

Can We Have NSX Cloud Discover Public Cloud Native Services?

Yes, We Can. NSX Cloud provides single-pane-of-glass visibility across your on-premises and public cloud environment. In addition to providing EC2 and VM inventory information, NSX Cloud also discovers native cloud service endpoints. It currently discovers four AWS services and four Azure services and enables a user to program security rules subject to capabilities from the Public Cloud provider. More services will be discovered in the future releases of NSX Cloud.

What Are the Feature Differences Between the Two Modes?

With “NSX Enforced Mode”, you get to leverage all the features that NSX has to offer as a platform. With “Cloud Enforced Mode”, since we do not have access to the data-plane, and given the fact that we are using public cloud’s native networking and security constructs, we are bound by what is being offered by your public cloud vendor of choice. Hence features such as L7 security, Policy-Based Overlay, Packet Capture are only available in NSX Enforced Mode.

Can We Have Both the Modes?

Yes, We Can. The management boundary is at VPC/VNet level, i.e. you could have a set of VPCs/VNets operating in Cloud Enforced Mode and another set of them operating in NSX Enforced Mode within the same account/region/subscription. If you were to go with “Cloud Enforced Mode”, every workload inside a managed VPC/VNet is managed by NSX Cloud. If you were to go with “NSX Enforced Mode”, you get more granular control – granularity is at VM level, wherein VMs that are ‘tagged’ inside a managed VPC/VNet are managed by NSX Cloud.

What Happens If I have a Firewall Policy That Cannot Be Realized?

In Cloud Enforced Mode, you inherit the native networking and security constructs of your preferred public cloud vendor. Hence, it is possible that under certain circumstances, your intended firewall policies cannot be realized. NSX Cloud will flag these rules and notify you. You could then choose to either modify the firewall rule or switch to NSX Enforced Mode.

Final Thoughts

A pattern that we repeatedly see in our conversations with customers is that different line of business within the same organization wants different modes of operation.  These calls are largely driven by business needs, operational efficacy, and security mandates. Sometimes, there is also a learning curve as one tries to figure out what model works best for them.

With VMware NSX, we provide the flexibility to have both modes so that customers aren’t bound by a tool’s architecture as they start designing their hybrid cloud environment.

Resources

Here are some pointers if you would like to know more about VMware NSX and NSX Cloud.

NSX-T Resources

NSX Cloud Resources

Related Articles