NSX uses existing roles and introduces some new ones to support multi-tenancy.

Following are some of the roles used in the context of multi-tenancy:

  • Roles that have access to the / space which thereby gives them access to all the configuration under /infra as well as /org:
    • Enterprise Admin: The provider administrator is responsible for preparing the infrastructure and is a super user who can access configurations within and outside Projects.
    • Auditor: Users in this role have read-only access to system settings and configuration but have full access to the troubleshooting tools.
  • Roles introduced in NSX 4.0.1.1 for multi-tenancy that have access only to configuration under /orgs:
    • Org Admin (Tech Preview; not for production deployments): The Org Admin role is currently available in tech preview mode to manage Projects within the Org. However, this role does not have access to the /infra objects that are required to create Projects. Use the Enterprise Admin role for Project creation.
    • Project Admin: The Project Admin manages a project and has full access to configuration within that project.
Assign the Project Admin role by making the following API call: 
POST /policy/api/v1/aaa/role-bindings/
Sample request:
URL: 
POST https://{{nsx-manager-ip}}/policy/api/v1/aaa/role-bindings/
Body: 
{
    “name”: “[email protected]”,
    “type”: “remote_user”,
    “roles_for_paths”: [
        {
            “path”: “/orgs/default/projects/project-1”,
            “roles”: [
                {
                    “role”: “project_admin”
                }
            ]
        }
    ],
    “resource_type”: “RoleBinding”,
    “identity_source_type”: “LDAP”,
    “read_roles_for_paths”: true
}
You can also assign the following existing roles to a specific project by providing the Project path:
  • Network Admin: The Network Admin role, when assigned to a project path, manages the networks and services at that project level.
  • Network Operator: Users with this role, when assigned to a project path, have read-only access to networking configuration at that project level.
  • Security Admin: The Security Admin role, when assigned to a project path, manages the security policies at that project level.
  • Security Operator: Users with this role, when assigned to a project path, have read-only access to security configuration at that project level.
Sample request for assigning a role to a local user for a specific Project:
URL: 
POST https://{{nsx-manager-ip}}/policy/api/v1/aaa/role-bindings/<RoleBinding ID>
Body: 
{
    “name”: “[email protected]”,
    “type”: “local_user”,
    “roles_for_paths”: [
        {
            “path”: “/orgs/default/projects/project-1”,
            “roles”: [
                {
                    “role”: “project_admin”
                }
            ]
        }
    ],
    “resource_type”: “RoleBinding”,
    “read_roles_for_paths”: true
}

To ensure only the Project Admin role is assigned to the local user, delete the Auditor role.

DELETE https://{{nsx}}/policy/api/v1/aaa/role-bindings/<RoleBinding ID>

Authentication

NSX multi-tenancy supports users configured on multiple types of identity sources. Following are the supported types of identity sources and their configuration parameters:
  • Local Users (admin, audit, guestuser1, guestuser2)
    “type”: “local_user”,
  • VIDM (VMware Identity Manager)
    “type”: “remote_user”,
“identity_source_type”: “VIDM”,
  • LDAP (Lightweight Directory Access Protocol)
    “type”: “remote_user”,
“identity_source_type”: “LDAP”,
  • Principal Identity (via certificate or JWT token)

    Roles can only be assigned using the principal identity API.