Author: Thomas Vigneron, VMware
From Data-plane Multi-tenancy to a Complete Multi-tenancy Framework
We are delighted to announce Projects in NSX, a new feature that enables granular resource management for multiple tenants within NSX deployments.
Projects takes multi-tenancy support in NSX to the next level by delivering flexible resource allocation and management. Enterprise Admins can segment the platform into Projects, assigning different spaces to different tenants while maintaining full visibility and control. This extension to the NSX consumption model allows NSX users to consume their own objects, see alarms related to their own configurations and test connectivity between their workloads with Traceflow.
This post provides an overview of new multi-tenancy features in NSX, explaining how they have evolved from traditional data-plane multi-tenancy (which remains supported) to the new multi-tenancy framework based on Projects (which admins can optionally leverage).
Data-plane Multi-tenancy – Routing
Before discussing the new multi-tenancy features that Projects introduces, let’s go over how multi-tenancy has traditionally been available at the data-plane layer.
NSX supports a multi-tiered routing model with logical separation between the different gateways within the NSX infrastructure, giving complete control and flexibility over services and policies. This model enables simple and stable interconnection in the data center as well as automation of complex, potentially isolated application environments.
The Tier-0 Gateway provides a gateway service between the logical and physical network. It is traditionally set up with dynamic routing and/or services.
The Tier-1 Gateway provides a tenant or an application router with a range of services (NAT, GFW, DNS forwarder, etc.). NSX manages their connection and route distribution to the Tier-0 Gateway.
Extended Networking Capabilities
There are multiple ways to extend this model for additional segmentation.
In the image below, you can see multiple Tier-0s in the same NSX Deployment
- Tenant A can be mapped to Tier-0 A and underlying Tier-1s
- Tenant B can be mapped to Tier-0 B and underlying Tier-1s
This configuration would be used to propagate networking segmentation from the data center in NSX, but it requires a different set of Edge Nodes for different environments.
With the introduction of Tier-0 VRF, this requirement is no longer necessary. Tier-0 VRF Gateways are hosted on a Parent Tier-0 Gateway on the Edge Node. As the image below shows, we can implement the following configuration:
- Tenant A can be mapped to Tier-0 VRF A and underlying Tier-1s
- Tenant B can be mapped to Tier-0 VRF B and underlying Tier-1s
The use cases for Tier-0 VRF are further extended with the introduction of EVPN, which simplifies North-South configuration at scale by removing the need to have per-VRF routing configurations.
You can check out this blog on multi-tenancy data-center with NSX EVPN to learn more.
Data-plane Multi-tenancy – Distributed Security
NSX also offers distributed security, allowing for the isolation of workloads (VMs or containers) and control of the traffic between them. Because security is handled within the vNIC, isolation remains possible no matter the networking architecture. You get the same security protections regardless of whether the VMs are on the same host or the same subnet.
This powerful capability allows you to group workloads and create rulesets based on a variety of attributes, from OS to line of business characteristics.
This also means that a single rule pushed from NSX can be applied to all workloads in the environment, which increases the value of being able to manage plane multi-tenancy. Delegation can quickly become inefficient and complex without segmentation.
Cloud Management Platforms
The model shown below allows a provider to set up the Tier-0 Gateway, define how it connects to the network, and expose the creation of Tier-1s through a Cloud Management Platform (such as Aria Automation, OpenStack or vCloud Director).
Tenancy is achieved from a data-plane perspective through NSX and from a management plane perspective through a Cloud Management Platform, which isolates the different environment configurations.
Why Introduce a Multi-tenancy Framework in NSX?
In the models previously discussed, you can see how NSX allows users to apply the desired data-plane segmentation. However, prior to the release of NSX 4.1, tenants were not explicitly defined in NSX. This logic was completed by either the NSX Administrator or the Cloud Management Platform.
What if a security team wanted to delegate management of firewall rules, requiring role-based access to NSX? What if the same users on that team wanted to see only the alarms relevant to their environment? Or if they wanted to collect only their assigned firewall logs within their tenant?
These are just some theoretical scenarios that highlight the challenges teams face; from a management and monitoring perspective, there exists a clear need for multi-tenant constructs in NSX.
Introducing Projects
Multi-tenancy in NSX 4.1 is made possible by the introduction of Projects in the platform.
The Enterprise Admin (Provider) can segment the platform into defined Projects. These Projects delegate users to different spaces and tenants with their own objects, configurations, VMs, and monitoring (based on alarms and logs).
Projects exist alongside the traditional data model, are optional to use, and do not break compatibility with existing setups in any way. The Enterprise Admin can still access all features outside of the Project (from system setup to firewall rules) but can use Projects to define tenants for logical consumption, if desired.
Provider View: Creating and Managing Projects
From NSX 4.1.0 onwards, Projects are available front and center in the NSX UI within the drop-down menu at the top of the screen. When accessing the platform, the Enterprise Administrator will be logged into the Default space indicated by the drop-down menu.
In the Default space, Enterprise Admins can have a consolidated view of all Projects or switch to view a specific Project. They can also create multiple tenants with different Projects (Project 1, Project 2, etc.). To do so, they must allocate:
- At least one Tier-0 or Tier-0 VRF (Multiple supported)
- At least one Edge Cluster (Multiple supported)
- The User(s) allocated to the Project
- A short log ID to be labeled on logs pertaining to the Project (limited to security logs in NSX 4.1.0)
It is important to note that Tier-0/Tier-0 VRF and Edge Clusters can be shared across Projects if desired by the Enterprise Admin.
Once assigned, Project Users for Project 1 can directly access NSX within the scope defined for them. They can also create configurations deployed on the allocated Edge clusters, which can connect to the allocated Tier-0 or Tier-0 VRF.
The Enterprise Admin can also assign configuration of the Project to simplify consumption or limit the number of objects created through Quotas. The image below shows an example of assigned Quotas.
The Enterprise Admin can create firewall rules system-wide that will apply to all VMs across all environments. Those rules are configured from the Default space and are unable to be modified within tenants.
Tenant View: Projects Consumption
Once the Projects have been set up, access can be delegated to the tenant. The Enterprise Admin can assign a generic role of Project Admin or use something more targeted such as Security Admin of Project 1 or Network Operation of Project 1. The tenant can consume NSX via the UI or API.
Upon logging in, users will land directly in their assigned Project and see only configurations, alarms, VMs and so on that are relevant to their Project.
Configuration will be restricted to logical objects. Tenants cannot manage the platform setup (installation, upgrades, etc.) because these features are kept under Enterprise Admin management. Other features that remain under Enterprise Admin management and are not exposed to the tenant include Tier-0 configuration and Exclusion lists.
List of features made available under Projects.
Networking in Project
For exposed features, the consumption under Projects is the same as it would be outside the Project. Creation of Tier-1s, segments, and other configuration follows the same model, and they use the allocated Tier-0(s)/Tier-0 VRF(s) and Edge Cluster(s). Information on allocated resources (Quota) is available in the Project tab.
For exposed features the consumption under Project is the same as outside the Project.
Security in Project
One of the primary goals of the Project feature is to be able to delegate security policy management and avoid the risk of rules being applied to the wrong VMs.
When a Project is created, a group representing the Project is also created, alongside some default rules allowing for communication inside the Project.
The Project Admin can manage their own rules by changing the default rules, creating new rules and so on. These rules will only apply to VMs connected to the segment for their Project. All the other VMs (not connected to Project segments) won’t be visible from the Project and won’t be impacted by rules configured within the Project.
It is now possible to give access to NSX Distributed Firewall while removing the risk that a user could create a rule impacting the entire system.
As mentioned, rules defined by the Enterprise Admin in the Default space can apply to those VMs within a Project and will take precedence. This allows the Enterprise Admin to set up the environment to create global rules that apply to all workloads, or to specific Projects. These global rules cannot be modified by Project users.
Logs from Distributed Firewall and Gateway Firewall will be labeled with the Project information so that they can be identified and separated by the tenant.
Conclusion
Multi-tenancy within NSX has been available at the data plane layer for several years, but the introduction of Projects supercharges the operational efficiency of this capability. Enterprise Admins now benefit from much broader and more flexible controls over multi-tenant configurations when configuring role-based access controls, Quotas, Shares and much more. At the same time, tenants can manage their own resources and configurations more efficiently via capabilities like tenant-aware logs and alarms.
Again, Projects is an optional feature; you can continue to manage multi-tenancy at the data plane layer alone if desired and doing so may make sense for simpler use cases where your primary goal is to achieve logical separation between gateways. But for more complex use cases, Projects adds substantial flexibility that makes it easier than ever to create and manage multi-tenant deployments.
Top comments (0)