DataWorks provides a comprehensive permission management system for service management and service module usage. DataWorks provides global and workspace-level roles that you can use to manage permissions on global and workspace-level service modules. This topic describes how DataWorks uses role-based access control (RBAC) to manage permissions on service modules.
Note Service management permissions in DataWorks are the permissions that are required to perform operations in the DataWorks console. For example, you must be granted service management permissions if you want to create, disable, or delete a workspace on the Workspaces page, create or configure an exclusive resource group on the Resource Groups page, and configure an alert contact on the Alert Contacts page. DataWorks uses RAM policies to manage service management permissions. For more information, see Manage permissions on the DataWorks services and the entities in the DataWorks console by using RAM policies.
Global and workspace-level service modules
After you log on to the DataWorks console and go to the page of a DataWorks service module, click the 
icon in the upper-left corner of the page. All service modules of DataWorks that are shown in the following figure are displayed. 
You can click a service module to go to the page of the service module. On the page of a service module, you can determine whether the service module is a workspace-level or global service module in the following way:
icon in the upper-left corner of the page. All service modules of DataWorks that are shown in the following figure are displayed. You can click a service module to go to the page of the service module. On the page of a service module, you can determine whether the service module is a workspace-level or global service module in the following way:- If the workspace name is displayed in the top navigation bar, the service module is a workspace-level service module, such as DataStudio.
- If the workspace name is not displayed in the top navigation bar, the service module is a global service module, such as Data Map.
Note For more information about how to differentiate a workspace-level service module from a global service module, see Appendix: Distinguish between workspace-level service modules and global service modules.
Global and workspace-level roles
The permissions on service modules in DataWorks are managed based on RBAC. DataWorks provides global and workspace-level roles that you can use to manage permissions on global and workspace-level service modules. After you assign a role to a user, which can be a RAM user or a RAM role, the user has the required permissions on specific service modules.
Key terms:
- User: A user can be a RAM user or a RAM role.
- Role: A role can be a workspace-level or global role.
- Permissions: consist of the permissions on workspace-level and global service modules.
DataWorks provides built-in global and workspace-level roles. You can assign these built-in roles to users to allow the users to have the required permissions on specific service modules. You can also create custom global or workspace-level roles based on your business requirements.
Note
- Among all types of roles, only the tenant administrator role, which is a global role, has permissions on all the service modules.
- The tenant member role is automatically assigned to all RAM users that belong to an Alibaba Cloud account.
- A custom global role has a higher permission priority than the tenant member role.
For example, RAM User A that belongs to an Alibaba Cloud account is automatically assigned the tenant member role, and can access Data Map. If the tenant administrator creates a custom global role that does not have the permissions on Data Map, and assigns the custom global role to RAM User A, RAM User A cannot access Data Map.
Permissions of global roles
DataWorks provides the following global roles: tenant administrator, tenant member, tenant security administrator, data directory administrator, metadata collection administrator, and data governance administrator. The following table describes the permissions of the global roles.
| Role | Permission | Authorized by | Description |
|---|---|---|---|
| Tenant administrator | Permissions on all DataWorks service modules, excluding the permissions to perform operations in the DataWorks console | Tenant owner (Alibaba Cloud account), RAM user to which the AliyunDataWorksFullAccess policy is attached, user that has the AdministratorAccess permission, and RAM user that is assigned the tenant administrator role. The RAM user that is assigned the tenant administrator role can assign the tenant administrator role to other RAM users. | This role has full permissions in DataWorks and can perform operations on all DataWorks service modules. |
| Tenant member | Same permissions as the Development role:
| No authorization is required. All RAM users that belong to an Alibaba Cloud account are automatically assigned the tenant member role. | All RAM users and RAM roles that belong to an Alibaba Cloud account are automatically assigned the tenant member role. |
| Tenant security administrator | All permissions on Security Center, Approval Center, and Data Security Guard | The tenant administrator can assign the tenant security administrator role to a RAM user. | This role is used to manage the security configurations in a workspace. |
| Data governance administrator | Regular permissions and management permissions on Data Governance Center, excluding the permissions to activate a service, and create, enable, and disable a check item | The tenant administrator can assign the data governance administrator role to a user. | This role is used to manage Data Governance Center. |
| Data directory administrator | Regular permissions on Data Map and permissions to manage data directories in Data Map | The tenant administrator can assign the data directory administrator role to a user. | This role is used to manage data directories in Data Map. |
| Metadata collection administrator | Regular permissions on Data Map and metadata collection permissions | The tenant administrator can assign the metadata collection administrator role to a user. | This role is used to manage metadata collection in Data Map. |
Permissions of workspace-level roles
DataWorks provides a variety of built-in workspace-level roles, and allows you to create custom workspace-level roles based on your business requirements.
- Built-in workspace-level rolesDataWorks provides the following built-in workspace-level roles: Project Owner, Data Analyst, Workspace Manager, Development, O&M, Deploy, Visitor, Security Manager, and Model Developer.Note The owner of a workspace is an Alibaba Cloud account instead of a RAM user that belongs to the Alibaba Cloud account and creates the workspace. The Project Owner role cannot be assigned to other users. For more information about the permissions of built-in workspace-level roles on DataWorks service modules, see Permissions of built-in workspace-level roles.
- Custom workspace-level roles
DataWorks allows you to create a custom workspace-level role and grant the role the permissions on workspace-level service modules. For more information about how to create a custom workspace-level role, see Manage permissions on workspace-level services.
| Object | Built-in role | Custom role |
|---|---|---|
| DataWorks service modules | DataWorks predefines the permissions of each built-in workspace-level role on workspace-level service modules. For more information, see Permissions of built-in workspace-level roles. | When you create a custom workspace-level role, you must specify the permissions of the role on workspace-level service modules. |
| MaxCompute compute engine instance |
| If you map a custom workspace-level role to a MaxCompute role when you create the custom workspace-level role, the custom workspace-level role has the permissions of the mapped MaxCompute role. |
| E-MapReduce (EMR) compute engine instance | When you associate an EMR compute engine instance with a workspace, you can configure mappings between workspace members and Lightweight Directory Access Protocol (LDAP) accounts of an EMR cluster. This way, you can grant the permissions on the EMR compute engine instance to the workspace members. For more information, see Associate an EMR cluster with a DataWorks workspace as an EMR compute engine instance. | |
| Cloudera Distribution Hadoop (CDH) compute engine instance | When you associate a CDH compute engine instance with a workspace, you can configure mappings between workspace members and Linux or Kerberos accounts of a CDH cluster. This way, you can grant the permissions on the CDH compute engine instance to the workspace members. For more information, see Create and manage workspaces. | |
| Other compute engine instances | To use a compute engine instance in DataWorks, you must associate the compute engine instance with a DataWorks workspace. When you associate a compute engine instance with a DataWorks workspace, you must specify the scheduling access identity of the compute engine instance in the development environment and production environment. For example, you must specify the username and password for database access when you associate an AnalyticDB for PostgreSQL compute engine instance with a DataWorks workspace. Users that are assigned built-in or custom workspace-level roles use the specified scheduling access identity to run nodes on a compute engine instance. Permissions on a compute engine instance other than a MaxCompute compute engine instance are not directly granted to workspace-level roles. The permissions are determined based on the scheduling access identity that you specify when you associate the compute engine instance with your workspace. | |
Summary:
- DataWorks provides built-in workspace-level roles that have been mapped to roles of an associated compute engine instance. This way, the built-in workspace-level roles have the permissions of the mapped roles. This allows users that are assigned built-in workspace-level roles to perform specified operations on the associated compute engine instance.
- DataWorks supports custom workspace-level roles. When you create a custom workspace-level role, you can map the custom workspace-level role to a role of a compute engine instance. This way, the custom workspace-level role has specified permissions on the compute engine instance.
- Scenario 1: Assign a built-in workspace-level role to a userA RAM user is added to a DataWorks workspace by a user with the workspace administrator permissions and assigned the Development role, which is a built-in workspace-level role.Note For more information about how to add a workspace member and grant permissions to the workspace member, see Manage permissions on workspace-level services.
After the RAM user is added to the DataWorks workspace and is assigned the Development role, the RAM user has specified permissions on DataWorks service modules and the MaxCompute compute engine instance that is associated with the workspace. - DataWorks: After the Development role is assigned to the RAM user, the RAM user can develop and commit the code of a node in the workspace but cannot deploy the code of the node to the production environment. Only the Project Owner, Workspace Manager, and O&M roles have permissions to deploy the code of a node to the production environment.
- MaxCompute: After the Development role is assigned to the RAM user, the Role_Project_Dev role of the MaxCompute compute engine instance is assigned to the RAM user. The Role_Project_Dev role has specified permissions on the MaxCompute project that runs on the MaxCompute compute engine instance in the development environment and tables in the project. Note
- You can assign the Workspace Manager role to a RAM user so that the RAM user has various permissions on DataWorks. However, the RAM user still cannot access tables in the production environment.
- The RAM user refers to a RAM user that is not specified as the scheduling access identity of a MaxCompute project in the production environment.
- Scenario 2: Assign a custom workspace-level role to a userA RAM user is added to a DataWorks workspace by a user with the workspace administrator permissions and assigned a custom workspace-level role.
When you create the custom workspace-level role, you can specify whether this role is mapped to a role of the MaxCompute compute engine instance that is associated with the workspace. After the custom workspace-level role is assigned to the RAM user, the RAM user has specified permissions on DataWorks service modules and the MaxCompute compute engine instance. Note For more information about how to create a custom workspace-level role, see Manage permissions on workspace-level services. For more information about how to add a workspace member and grant permissions to the workspace member, see Manage permissions on workspace-level services.- DataWorks: After the custom workspace-level role is assigned to the RAM user, the RAM user has permissions on the DataWorks service modules on which the custom workspace-level role can perform operations.
- MaxCompute:
- If the custom workspace-level role is not mapped to a role of the MaxCompute compute engine instance, the RAM user does not have permissions on the MaxCompute compute engine instance. The RAM user cannot query objects in the MaxCompute project that runs on the MaxCompute compute engine instance by running commands.
- If the custom workspace-level role is mapped to a role of the MaxCompute compute engine instance, the RAM user has the permissions of the mapped MaxCompute role.
Note If a RAM user is specified as the scheduling access identity of a MaxCompute compute engine instance in the production environment, the RAM user can access tables in the MaxCompute project that runs on the MaxCompute compute engine instance after the RAM user is added to the workspace with which the MaxCompute compute engine instance is associated. Otherwise, the RAM user cannot access tables in the production development. If the RAM user wants to access tables in the production environment, the RAM user must apply for the permissions in Security Center. For more information about how to apply for permissions, see Request permissions on tables in Security Center (latest version). For more information about access identities of MaxCompute, see Create and manage workspaces.
Appendix: Mappings between DataWorks built-in workspace-level roles and MaxCompute roles
The following table describes the mappings between DataWorks built-in workspace-level roles and MaxCompute roles. The following table also describes the permissions of each role in the development and production environments.
| DataWorks built-in workspace-level role | MaxCompute role | Permission on data in the development environment of a DataWorks workspace and data in the MaxCompute project that runs on the MaxCompute compute engine instance that is associated with the workspace | Permission on data in the production environment of a DataWorks workspace and data in the MaxCompute project that runs on the MaxCompute compute engine instance that is associated with the workspace | Permission on a DataWorks workspace |
|---|---|---|---|---|
| Workspace Manager | Role_Project_Admin |
| No permissions by default. You must apply for the required permissions in Security Center. | The administrator of the workspace. Permissions to manage the basic properties, data sources, compute engine configurations, and members of the workspace and assign the Workspace Manager, Development, O&M, Deployment, or Visitor role to workspace members |
| Development | Role_Project_Dev |
| Permissions to create workflows, script files, resources, user-defined functions (UDFs), tables, and deployment tasks, and delete tables, but no permissions to perform deployment operations | |
| O&M | Role_Project_Pe | Permissions on the project and the functions, resources, instances, and jobs of the project, Read permissions on packages, and Read and Describe permissions on the tables of the project. Note The O&M role has the permissions on the MaxCompute compute engine instance but does not have the permissions to run nodes in the DataWorks console. | Deployment and online O&M permissions that are granted by the Workspace Manager role but no permissions to develop data | |
| Deploy | Role_Project_Deploy | No permissions by default. | Same permissions as the O&M role, except for online O&M permissions | |
| Data Analyst | Role_Project_Data_Analyst | No permissions by default. | Permissions only on DataAnalysis by default | |
| Visitor | Role_Project_Guest | No permissions by default. | Permissions to view data but no permissions to edit workflows or code | |
| Safety Manager | Role_Project_Security | No permissions by default. | Permissions to configure sensitivity rules and audit data risks in Data Security Guard | |
| Model Developer | Role_Project_Erd | No permissions by default. | This role has permissions to view models and modify parameter configurations in the Data Warehouse Planning, Data Standard, Dimensional Modeling, and Data Metric modules. This role has no permission to publish models. | |
| N/A | Project Owner | All permissions on the project. | This role has the same permissions as those in the development environment. | N/A |
| N/A | Super_Administrator | Management permissions on the project and all permissions on all types of resources in the project. | This role has the same permissions as those in the development environment. | N/A |
| N/A | Admin | When you create a project, the system creates an Admin role for this project and grants permissions to the role. The Admin role has the permissions to access all objects in the project, manage users or roles, and grant permissions to users or roles. Unlike the Project Owner role, the Admin role does not have permissions to perform the following operations: assign the Admin role to users, configure security policies for projects, modify the authentication models of projects, and modify the permissions of the Admin role. The Project Owner role can assign the Admin role to a user and authorize the user to manage security configurations. | This role has the same permissions as those in the development environment. | N/A |
Appendix: Distinguish between workspace-level service modules and global service modules
For a workspace-level service module, such as DataStudio, the workspace name is displayed in the top navigation bar. 
For a global service module, such as Data Map, the workspace name is not displayed in the top navigation bar. 