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:

    • 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.

    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.

• 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).

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.

To change a manager's or role's permissions, send a PATCH request to the /managers/{id}/ or the /roles/{id}/ endpoint.