In the last post of this series, I discussed how to create NSX Projects and apply RBAC and Quota policies to them. I also touched base briefly on the project’s security (DFW) aspect.

In this post, I will discuss the project’s security in greater detail. 

If you are not following along, you can read the earlier parts of this series from the below links:

1: NSX Multitenancy Introduction

2: Multitenancy Design Models

3: Creating NSX Projects

One of the key purposes of the Project feature is to allow security policy management to be delegated to the project admin to avoid the danger of rules being applied to the wrong virtual machines.

When an NSX project is created by the Enterprise Admin, the system generates default Distributed & Gateway firewall rules to regulate the default behavior of east-west and north-south traffic for the VMs in the NSX project.  The firewall rules in a project apply only to the VMs created in that project and don’t impact VMs created in other projects or the default space.… Read More

Welcome to part-3 of the NSX Multi-tenancy series. Parts 1 & 2 of this series were theoretical and mainly focused on multi-tenancy architecture and design models. This part focuses on hands-on, with topics such as creating NSX projects, applying RBAC policies, and creating networking constructs within the project. 

If you are not following along, you can read the earlier parts of this series from the below links:

1: NSX Multitenancy Introduction

2: Multitenancy Design Models

Environment Details

This is a full-fledged NSX deployed environment based on the design documented here; thus, I am not covering the implementation details again. 

The lab is deployed as per the below BOM 

I am using the multi-tenancy with shared provider tier-0 gateway design for this post, where tenants will share the tier-0 gateway and the edge clusters from the provider.… Read More

Welcome to part-2 of the NSX Multi-tenancy series. While part-1 focused on the NSX Multi-tenancy solution and its architecture, part 2 will walk you through the multi-tenancy design models.

After the Project is created and the RBAC policies have been applied, the project admin creates the tier-1 gateways and segments for their workloads. Since the tier-0 gateway and edge clusters cannot be created inside a project, the Enterprise Admin is responsible for sharing these objects from the default space with the projects.

Multi-tenancy Design Models

There are 2 design models available as of today for implementing multi-tenancy:

1. Multi-tenancy with shared Provider (T0 / VRF) gateway.
2. Multi-tenancy with dedicated Provider (T0 / VRF) gateway.

In both designs, the data plane is shared. Multi-tenancy with an isolated data plane is not yet supported. 

Based on the design models discussed above, tenants can leverage shared or dedicated edge clusters to create networking constructs in a project.… Read More

What is Multi-tenancy?

Multi-tenancy is an architecture in which a single software application instance serves multiple customers, each called a tenant. A multi-tenant architecture allows several instances of an application to function in a shared environment. This design works because each tenant is physically integrated but logically independent. This means that a single instance of the software will run on one server and then serve multiple tenants.

Multi-tenancy in VMware NSX

Although Multi-tenancy was first introduced in NSX 4.0.1, it has been available at the data plane layer for several years. VMware NSX uses multi-tiered routing model with logical separation between the different gateways (tier-0 & tier-1) to provide networking connectivity, and these gateways, when deployed as per a specific design, provide isolation to user apps from each other.

For e.g, features like VRF, that allows for having a separate routing domain per tenant, or deploying Tier-1 gateways per application/environment (dev/test/prod) to achieve segmentation.… Read More