--- title: "User Permissions for Cluster, Tenant and Resource Access" slug: "cluster-api-clone-user-permissions-for-cluster-tenant-and-resource-access" description: "Learn how VAST Management System RBAC governs cluster admin and tenant admin access, roles, LDAP/AD, SAML, and VMS REST API permissions." updated: 2026-10-26T17:30:53Z published: 2026-10-26T17:30:53Z canonical: "docs.vastdata.com/cluster-api-clone-user-permissions-for-cluster-tenant-and-resource-access" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt > Use this file to discover all available pages before exploring further. # User Permissions for Cluster, Tenant and Resource Access VAST Cluster has a role-based access control (RBAC) system for VAST Management System (VMS) users (*managers*) and permissions. This RBAC system determines user permissions to access various VMS REST API resources. A user type distinction also allows admin users with tenant-specific login access on clusters with multiple tenants, as well as regular cluster admin users with login access to the cluster VMS. ## VMS Login Access Login access depends on user type. Each *manager* has a user type. Two user types are valid for accessing the VMS API: - Cluster admin. These users can log into the cluster VMS web UI URL and the VMS CLI and authenticate to the VMS REST API. - Tenant admin. These users can log into a specific VMS web UI URL for a tenant. They can also authenticate to the REST API to manage resources specific to the tenant. ## VMS Permissions Permissions are divided by type (*create*, *view*, *edit*, and *delete*) and can be assigned per *realm*. Each realm is a category of resources you can create, view, edit, and delete. There are built-in realms and custom realms. Custom realms can be tenant-specific. You can assign permissions to security groups called *roles* and to *managers*. A role can be either: - Enabled for multiple tenants, which can be a specified restricted set, and assignable to cluster admins, or - Enabled for one tenant and assignable to tenant admins. ## Provisioning Login Access and Permissions You can provision VMS user access as follows: - You can configure *Managers* in VMS itself. These users can be assigned a user type and specific VMS permissions directly, and they can be assigned *roles*. Managers inherit all permissions assigned to all roles that they are assigned. You can use the `/managers/` endpoint to create or modify managers and assign them to roles. - Users that belong to an LDAP or Active Directory provider can be provisioned through groups as follows: - Use the `super_admin_groups` property in the body parameter of a POST or PATCH request to the `/ldaps/` or `/activedirectory/` endpoint to configure a given LDAP or Active Directory configuration to grant cluster admin type access to any groups on the provider. - For tenant admin access, you can configure a single group on a provider to have tenant admin login access by specifying the group name in the `tenant_admins_group_name` property in a POST or PATCH request to the `/tenants/` endpoint to create or update a tenant. The group name should be defined on an Active Directory or LDAP provider configured on the cluster and connected to the tenant. You can have multiple providers on the cluster, one of which of each type can be attached to any given tenant. This is controlled using the `ldap_provider_id` or `ad_provider_id` property in the body parameter in a `/tenants/` request. - To assign permissions to access and manage resources, use roles. Use the following properties in the body parameter of POST or PATCH requests to the `/roles/` endpoint: Control which user type and tenants the role applies to as follows: Map provider groups to roles using the `ldap_groups` property; specify groups on the relevant connected provider per role to group members. To assign multiple roles per tenant to distinct user groups, use one all-inclusive group for tenant admin access and multiple additional groups as needed for the various roles. - To configure a role for tenant admins, use the `tenant_id` property in the body parameter to specify the specific tenant. - To configure a role for cluster admins, use the `tenant_ids` property in the body parameter to specify all tenants for which you want the role to have permissions. - Users configured on a SAML identity provider for SSO login to the VMS web UI. You can configure a SAML identity provider on the cluster using the `/vms/{id}/saml_config/` endpoint. - To enable a SAML identity provider on a tenant, specify the provider name using the `identity_provider_name` property in the body parameter of a `/tenants/` request. - Use custom attributes on the provider so that the following are returned in the SAML assertion response for VMS user creation: - `email`. A unique identifier to create or update a user, - `username`. The name of the user - `roles`. The user's roles as they appear in the VMS. If this attribute is missing from the assertion, the user only receives `read_only` permission. For example, if you define a role in VMS called `SamlUser` with specific permissions, and your `IDP roles = SamlUser`, all users that are assigned to this role by your IdP will receive this role in VMS with all the permissions you granted for it. - `user_type`. Assigns user type: `SUPER_ADMIN` for cluster admin access or `TENANT_ADMIN` for tenant admin login access. - `tenant_name` . Required if `user_type`=`TENANT_ADMIN`, the name of the tenant to which the user should have access. There is a predefined manager *admin* with a predefined role *admin*. It is not possible to delete all VMS users defined with the *admin* role. At least one VMS admin user always remains, so that it's possible to access VMS without LDAP connectivity if needed. LDAP users can log into VMS with their Active Directory/LDAP username and password. Successful login requires connectivity with the Active Directory/LDAP server. Users are granted permissions based on roles associated with groups to which they belong. ## Listing and Changing Permissions You can send a GET request to the `/permissions/` endpoint to return a list of VMS permissions. The response is an array of permissions. Each permission specifies a permission type, a realm, and the resources that belong to the realm. For example, this permission allows create permission on the resources listed as "resources": ``` { "id": 4, "name": "Create Logical", "codename": "create_logical", "realm": "logical", "permission_type": "create", "resources": [ "task", "versionhistory", "vippool", "vip", "viewpolicy", "view", "dns", "s3lifecyclerule", "snapshotpolicy", "snapshot", "quota", "quotaentityinfo", "userquota", "qospolicy", "qosobject", "replicationtarget", "nativereplicationremotetarget", "replicationpolicy", "protectionpolicy", "protectedpath", "replicationgroup", "replicationstream", "replicationrestorepoint", "globalpolicy", "exposedpath", "globalpath", "globalsnapstream" ] }, ``` To see which permissions a given manager has, send a GET request to the `/managers/{id}/` endpoint, where the {id} is the manager's ID. To get a list of managers and their IDs, send a GET request to the `/managers/` endpoint. See [List Managers (VMS Users)](/api-5-5/apidocs/list-managers-vms-users). To see which permissions a role has, send a GET request to the `/roles/{id}/` endpoint, where the {id} is the role's ID. To get a list of roles and their IDs, send a GET request to the `/roles/` endpoint. See [List Roles](/api-5-5/apidocs/list-roles). To change a manager's or role's permissions, send a PATCH request to the `/managers/{id}/` or the `/roles/{id}/` endpoint.