DataWorks provides a comprehensive permission management system for product management and service usage. DataWorks provides global-level and workspace-level roles that you can use to manage permissions on global-level and workspace-level services. This topic describes how DataWorks uses the role-based access control (RBAC) model to manage permissions on services.
Product management permissions in DataWorks are the permissions that are required for users to perform operations in the DataWorks console. For example, you must be granted product 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 product management permissions. For more information, see Manage permissions on the DataWorks product and the entities in the DataWorks console by using RAM policies.
Global-level and workspace-level services
After you log on to the DataWorks console and go to the page of a DataWorks service, click the 
icon in the upper-left corner of the page. All services of DataWorks that are shown in the following figure are displayed. 
You can click a service to go to the page of the service. On the page of a service, you can determine whether the service is a workspace-level or global-level service in the following way:
If the workspace name is displayed in the top navigation bar, the service is a workspace-level service, such as DataStudio.
If the workspace name is not displayed in the top navigation bar, the service is a global-level service, such as Data Map.
For information about how to differentiate a workspace-level service from a global-level service, see the Appendix: Distinguish between workspace-level services and global-level services section in this topic.
Global-level and workspace-level roles
The permissions on services in DataWorks are managed based on the RBAC model. DataWorks provides global-level and workspace-level roles that you can use to manage permissions on global-level and workspace-level services. 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 services.
Key terms:
Users: include RAM users and RAM roles.
Roles: include workspace-level and global-level roles.
Permissions: include permissions on workspace-level and global-level services.
DataWorks provides built-in global-level and workspace-level roles. You can assign these built-in roles to users to grant the users permissions on specific services. You can also create custom global-level or workspace-level roles based on your business requirements. The following figure shows the relationship among users, roles, and permissions.
Among all types of roles, only the tenant administrator role, which is a global-level role, has permissions on all services.
The tenant member role is automatically assigned to all RAM users that belong to an Alibaba Cloud account.
A custom global-level 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-level role that does not have permissions on Data Map and assigns the custom global-level role to RAM User A, RAM User A cannot access Data Map.
Permissions of global-level roles
DataWorks provides the following global-level 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-level roles.
Role | Permission | Authorized by | Description |
Tenant administrator | Permissions on all DataWorks services, 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 services. |
Tenant member | Same permissions as the Develop 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 or 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 roles
DataWorks provides the following built-in workspace-level roles: Workspace Owner, Data Analyst, Workspace Administrator, Develop, O&M, Deploy, Visitor, Security Administrator, and Model Designer.
NoteThe 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 Workspace Owner role cannot be assigned to other users. For more information about the permissions of built-in workspace-level roles on workspace-level services, 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 services. For information about how to create a custom workspace-level role, see Manage permissions on workspace-level services.
Permissions of workspace-level roles take effect for the following two types of objects: DataWorks services and compute engines. Permissions on a compute engine include the permissions to add, delete, modify, and query an item such as table or resource in the compute engine. The following table describes the permissions of built-in and custom workspace-level roles on these two types of objects.
Object | Built-in role | Custom role |
DataWorks services | DataWorks predefines the permissions of each built-in workspace-level role on workspace-level services. 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 services. |
MaxCompute compute engine |
| 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 | When you register an EMR cluster to a DataWorks workspace, you can configure mappings between workspace members and Lightweight Directory Access Protocol (LDAP) accounts of the EMR cluster to allow the workspace members to have the permissions of the mapped LDAP accounts on the related EMR compute engine. For more information, see Register an EMR cluster to DataWorks. | |
Cloudera's Distribution including Apache Hadoop (CDH) compute engine | When you register a CDH cluster to a DataWorks workspace, you can configure mappings between workspace members and Linux or Kerberos accounts of the CDH cluster to allow the workspace members to have the permissions of the mapped Linux or Kerberos accounts on the related CDH compute engine. For more information, see Create and manage workspaces. | |
Other types of compute engines | To use a compute engine in DataWorks, you must add the related data source. When you add data sources to a DataWorks workspace in standard mode, you must specify the scheduling access identity for the related compute engines in the development environment and production environment. For example, if you want to access an AnalyticDB for PostgreSQL database, you must specify the username and password that are used to access the AnalyticDB for PostgreSQL database when you add an AnalyticDB for PostgreSQL data source to a DataWorks workspace. Users that are assigned built-in or custom workspace-level roles use the scheduling access identity that is specified when you add a data source to run tasks on the related compute engine. Permissions on a compute engine other than a MaxCompute compute engine are not directly granted to workspace-level roles. The permissions are determined based on the scheduling access identity that is specified when you add the data source. | |
Summary:
DataWorks provides built-in workspace-level roles that have been mapped to roles of the data source that you added to a workspace. 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 related compute engine.
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. This way, the custom workspace-level role has specified permissions on the compute engine.
After you assign a workspace-level role to a user, the user has permissions on both DataWorks services and compute engines. In the following example, MaxCompute is used to describe how permissions are granted to users that are assigned built-in and custom workspace-level roles.
Scenario 1: Assign a built-in workspace-level role to a user
A RAM user is added to a DataWorks workspace as a member by a user that is assigned the Workspace Administrator role, and the RAM user is assigned the Develop role, which is a built-in workspace-level role.
NoteFor 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 as a member and is assigned the Develop role, the RAM user has specified permissions on DataWorks services and the MaxCompute compute engine for which the related MaxCompute data source is added to the workspace. DataWorks: After the Develop 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 Workspace Owner, Workspace Administrator, and O&M roles have permissions to deploy the code of a node to the production environment.
MaxCompute: After the Develop role is assigned to the RAM user, the Role_Project_Dev role of the MaxCompute compute engine 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 in the development environment and tables in the project.
NoteYou can assign the Workspace Administrator role to a RAM user to grant the RAM user 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 an identity used to access a MaxCompute project in the production environment.
Scenario 2: Assign a custom workspace-level role to a user
A RAM user is added to a DataWorks workspace as a member by a user that is assigned the Workspace Administrator role, and the RAM user is assigned a custom workspace-level role.
When you create a custom workspace-level role, you can specify whether this role is mapped to a role of the MaxCompute compute engine for which the related MaxCompute data source is added to the workspace. After the custom workspace-level role is assigned to the RAM user, the RAM user has specified permissions on DataWorks services and the MaxCompute compute engine. NoteFor 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 is granted permissions on the DataWorks services 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, the RAM user does not have permissions on the MaxCompute compute engine. The RAM user cannot run commands to query objects in the MaxCompute project that runs on the MaxCompute compute engine.
If the custom workspace-level role is mapped to a role of the MaxCompute compute engine, the RAM user has the permissions of the mapped MaxCompute role.
NoteIf a RAM user is specified as the scheduling access identity of a MaxCompute compute engine in the production environment, the RAM user can perform operations on or access tables in the MaxCompute compute engine. In other scenarios, a RAM user cannot perform operations on or access tables in the MaxCompute compute engine in the production environment even after the RAM user is added to the workspace as a member. If you want the RAM user to perform operations on or access tables in the MaxCompute compute engine in the production environment, the RAM user must apply for the required permissions in Security Center. For more information about how to apply for permissions, see the Request permissions on tables in Security Center (latest version) section in the "Request permissions on tables" topic. For information about the identities that can be used to access a MaxCompute compute engine, 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 workspace member role | MaxCompute role | Permission on data in the DataWorks development environment and the related MaxCompute project | Permission on data in the DataWorks production environment and the related MaxCompute project | Description of permissions in DataWorks |
Workspace Administrator | Role_Project_Admin |
| No permissions by default. You must apply for the required permissions in Security Center. | A user with the Workspace Administrator role is the administrator of a workspace. The administrator has permissions to manage the basic properties, data sources, compute engine configurations, and members of the workspace and can assign the Workspace Administrator, Develop, O&M, Deploy, or Visitor role to workspace members. |
Develop | Role_Project_Dev |
| A user with the Develop role has permissions to create workflows, script files, resources, user-defined functions (UDFs), tables, and deployment tasks, and delete tables, but does not have permissions to perform deployment operations. | |
O&M | Role_Project_Pe | This role has all permissions on the project and the functions, resources, instances, and jobs in the project, the Read permissions on the packages in the project, and the Read and Describe permissions on the tables in the project. Note The O&M role has permissions on the MaxCompute compute engine, but does not have permissions to run nodes in the DataWorks console. | A user with the O&M role has deployment and online O&M permissions that are granted by the Workspace Administrator role, but does not have permissions to perform data development operations. | |
Deploy | Role_Project_Deploy | No permissions by default. | A user with the Deploy role has similar permissions to the O&M role, except for online O&M permissions. | |
Data Analyst | Role_Project_Data_Analyst | No permissions by default. | By default, a user with the Data Analyst role has permissions only on DataAnalysis. | |
Visitor | Role_Project_Guest | No permissions by default. | A user with the Visitor role has permissions to view data, but does not have permissions to modify workflows or code. | |
Security Administrator | Role_Project_Security | No permissions by default. | A user with the Security Administrator role can be used only in Data Security Guard and has permissions to configure sensitive data identification rules and audit data risks in Data Security Guard. | |
Model Designer | Role_Project_Erd | No permissions by default. | A user with the Model Designer role has permissions to view models and modify parameter configurations in Data Warehouse Planning, Data Standard, Dimensional Modeling, and Data Metric, but does not have permissions to publish models. | |
N/A | Project Owner | This identity is the owner of the project and has all permissions on the project. | This role has the same permissions in the production environment as in the development environment. | N/A |
N/A | Super_Administrator | This role is the super administrator of the project and has management permissions on the project and all permissions on all types of resources in the project. | This role has the same permissions in the production environment as 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 the role permissions to access all objects in the project, manage users or roles, and grant permissions to users or roles. In contrast to 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 the project, modify the authentication model for the project, 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 in the production environment as in the development environment. | N/A |
Appendix: Distinguish between workspace-level services and global-level services
For a workspace-level service, such as DataStudio, the workspace name is displayed in the top navigation bar.
For a global-level service, such as Data Map, the workspace name is not displayed in the top navigation bar.