Multi-tenancy provides a means to isolate security and networking configuration across tenants on a single NSX deployment. To support multi-tenancy, NSX 4.0.1.1 introduces Orgs and Projects.

The NSX Policy data model is hierarchical and has two system-created branches:

  • /infra which is managed by the infrastructure administrator.
  • /orgs/default which holds the multi-tenancy constructs.
Note: Setting up multi-tenancy for your NSX deployment is optional and its implementation has no impact on your existing NSX configuration.

The following diagram illustrates the data model for multi-tenancy.

Data Model

Orgs

An NSX deployment has one default Org. You cannot create, modify, or delete the Org. The Org object is created by the system at startup. All tier-0 gateways and Edge clusters in the system are accessible by the Org.

The Org object is created by the system with the following identifier:

/orgs/default

Projects

Under the Org, you can create a Project for each tenant that you want to manage from your NSX environment. Projects are created under /orgs/default to support independent sets of configuration for each tenant:

  • Projects offer the Policy hierarchical model in a specific isolated context. Project configurations are set up under /orgs/default/projects/<project-id>/infra.
  • You cannot create tier-0 gateways and edge clusters under a Project. The Enterprise Admin can share tier-0 gateways and edge clusters from the /infra space with the Org which is then available to the Projects under the Org.
  • Projects have access to some of the objects and configurations that have been shared from the /infra space.
  • You can create rules that apply to VMs in a Project, from the infra space. To create these rules from the infra space either leverage the Project Default Groups, or create groups with dynamic memberships or VM static membership.
  • Besides rule creation from the infra space, configuration of other Project resources from the infra space is not supported. For example, you cannot create groups under Org using static members from Projects other than VMs /Project Default Groups. Configuring tier-1 gateways belonging to a project from the infra space is not supported. Project resources must be configured from within the Project.

You can make the following API call to create a Project under the Org:

PATCH /policy/api/v1/orgs/default/projects/<project-id>

When creating a Project, specify the tier-0 gateway and the edge cluster that the Project will use. Use this tier-0 gateway for all configurations within that Project. The edge cluster allocated to the Project must belong to the default transport zone. This transport zone is where the Project networks are created.

Sample request:

URL:

PATCH https:/{{nsx-manager-ip}}/policy/api/v1/orgs/default/projects/Project-Dev

Body:

{
    "site_infos": [
        {
            "edge_cluster_paths": [
                "/infra/sites/default/enforcement-points/default/edge-clusters/ca1b2a4f-057d-42da-b3b8-cf218b1c1a51"
            ],
            "site_path": "/infra/sites/default"
        }
    ],
    "tier_0s": [
        "/infra/tier-0s/Tier0GatewayTest"
    ]
}

When you create a Project some default objects like a default domain, security policies, and default groups are created. You can choose to create multiple Projects, as per your requirements.

Once a project is created you can make API calls to complete networking configurations for DHCP, tier-1 gateways, and segments among others.

Note: To enable the Project Admin to connect segments or tier-1 gateways to a tier-0 gateway or a tier-0 VRF, assign an additional custom role to the user with the Project Admin role. The custom role that you assign must have read access to the system tier-0 gateway. This enables the Project Admin to view all the tier-0 gateways in the system. See Create or Manage Custom Roles for details on creating a custom role.

When creating the custom role, select Networking and reset all permissions to None. On the Set Permissions dialog box, select Networking > Connectivity and set Tier-0 Gateways permissions to read-only.

Resource Quotas

You can define quotas for resources in a Project by using constraints. Quotas enable you to define a maximum limit on specific resources for a given Project. System default limits apply if no constraints are defined.

Make the following API call to define constraints for a Project: 
PATCH /policy/api/v1/infra/constraints/<contraint-id>
Sample request:
URL: 
PATCH https://{{nsx-manager-ip}}/policy/api/v1/infra/constraints/c-1
Body: 
{
    "display_name": "TestConstraint",
    "constraint_expression": {
        "resource_type": "EntityInstanceCountConstraintExpression",
        "count": 10,
        "operator": "<="
    },
    "target": {
        "path_prefix": "/orgs/default/projects/project-1",
        "target_resource_type": "Group"
    }
}