DataWorks provides an all-round permission management system for service management and service module usage. DataWorks provides global and workspace-level roles that you can use to manage the permissions on global and workspace-level service modules. This topic describes how DataWorks uses role-based access control (RABC) to manage the 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 need service management permissions to create, disable, or delete workspaces on the Workspaces page, create or configure exclusive resource groups on the Resource Groups page, and configure contacts on the Alert Contacts page. DataWorks uses RAM policies to manage service management permissions. For more information, see Permission control by fine-grained RAM policies.

Global and workspace-level service modules

After you log on to the DataWorks console and go to the page of a DataWorks workspace, you can click the Icon icon in the upper-left corner of the top navigation bar. All service modules of DataWorks are displayed, as shown in the following figure. Web UI of DataWorksYou 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. For example, DataStudio is a workspace-level service module.
  • If the workspace name is not displayed in the top navigation bar, the service module is a global service module. For example, Data Map is a global service module.
Note For more information about the differences between global and workspace-level service modules, see Appendix: Distinguish between workspace-level service modules and global service modules.

Global and workspace-level roles

The permission management system of DataWorks is built on the RBAC model. DataWorks provides global and workspace-level roles that you can use to manage the 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 permissions on the related service modules.

Key terms:
  • Users: consist of RAM users and RAM roles.
  • Roles: consist of workspace-level and global roles.
  • Permissions: consist of the permissions on workspace-level and global service modules.
DataWorks provides built-in global and workspace-level roles. You can use these built-in roles to grant permissions to users, or create custom global or workspace-level roles as needed. The following figure shows the relationship among users, roles, and permissions. RBAC model
Note
  • Only the tenant administrator role has the permissions on all the service modules.
  • By default, the tenant member role is assigned to all RAM users within an Alibaba Cloud account.
  • A custom global role has a higher permission priority than the tenant member role.

For example, RAM User A within an Alibaba Cloud account is assigned the tenant member role by default, 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 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 Alibaba Cloud account, RAM users to which the AliyunDataWorksFullAccess policy is attached, users that have the AdministratorAccess permission, and RAM users that are 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:
  • Read-only permissions on Data Security Guard
  • Regular permissions on Security Center, excluding all audit permissions
  • Regular permissions on Data Map, excluding the permissions of the data directory administrator and metadata collection administrator roles
  • Regular permissions on DataAnalysis
  • Regular permissions on Approval Center, excluding the permissions to manage approval policies
No authorization is required. By default, all RAM users within an Alibaba Cloud account are assigned the tenant member role. By default, all RAM users and RAM roles that belong to an Alibaba Cloud account are 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.

Permissions of workspace-level roles

DataWorks provides a variety of built-in workspace-level roles, and allows you to create custom workspace-level roles as needed.
  • Built-in workspace-level roles
    DataWorks provides the following built-in workspace-level roles: Project Owner, Workspace Manager, Development, O&M, Deploy, Visitor, Security Manager, and Model Developer.
    Note The owner of a workspace is an Alibaba Cloud account even if the workspace is created by a RAM user that belongs to the Alibaba Cloud account. 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 Step 2: Create and manage custom workspace-level roles (Optional).

Permissions of workspace-level roles apply to the following two types of objects: DataWorks service modules and compute engine instances. Permissions on compute engine instances include the permissions to add, delete, modify, and query resources such as tables in the compute engine instances. 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 service modules DataWorks predefines the permissions of each built-in workspace-level role on DataWorks 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 instances
  • MaxCompute compute engine instances in the development environment:

    By default, built-in workspace-level roles have specified permissions on MaxCompute compute engine instances in the development environment. Users that are assigned built-in workspace-level roles can access MaxCompute tables in the development environment.

    For more information about the permissions of built-in workspace-level roles on MaxCompute compute engine instances in the development environment, see Appendix: Mappings between DataWorks built-in workspace-level roles and MaxCompute roles.

  • MaxCompute compute engine instances in the production environment:

    The built-in workspace-level roles do not have permissions on MaxCompute compute engine instances in the production environment. To access MaxCompute tables in the production environment, users must apply for the permissions in Security Center. For more information, see Data access control.

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 instances When you associate an EMR compute engine instance with a workspace, you can configure mappings between workspace members and LDAP accounts of the EMR cluster. This way, you can grant the permissions on the EMR compute engine instance to workspace members. For more information, see Associate an EMR cluster with a DataWorks workspace.
Cloudera Distribution Hadoop (CDH) compute engine instances When you associate a CDH compute engine instance with a workspace, you can configure mappings between workspace members and Linux or Kerberos accounts of the CDH cluster. This way, you can grant the permissions on the CDH compute engine instance to workspace members. For more information, see Associate a CDH compute engine instance with a workspace.
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 set the 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 instance with a DataWorks workspace.

Users that are assigned built-in or custom workspace-level roles use the specified access identify to run tasks on the compute engine instance. Permissions on non-MaxCompute compute engine instances are not directly granted to workspace-level roles. Instead, workspace members obtain the permissions by using the specified access identity.

Summary:
  • DataWorks provides built-in workspace-level roles that have been mapped to roles of associated compute engine instances. This way, 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 associated compute engine instances.
  • 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.
After you assign a workspace-level role to a user, the user has permissions on both DataWorks service modules and compute engine instances. 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 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 Step 3: Add and manage workspace members.
    Assign a built-in workspace-level roleAfter the RAM user is added to the DataWorks workspace and the Development role is assigned to the RAM user, the RAM user has specified permissions on DataWorks service modules and the MaxCompute project that is associated with the workspace.
    • DataWorks: After the Development role is assigned to the RAM user, the RAM user can develop and commit code in the workspace but cannot deploy code to the production environment. Only the Project Owner, Workspace Manager, and O&M roles have permissions to deploy code to the production environment.
    • MaxCompute: After the Development role is assigned to the RAM user, the Role_Project_Dev role of the MaxCompute project is assigned to the RAM user. The Role_Project_Dev role has specified permissions on the MaxCompute project 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 in the preceding descriptions refers to a RAM user that is not specified as the access identity of 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 by a user with the workspace administrator permissions and assigned a custom workspace-level role. Assign a custom workspace-level roleWhen you create the custom workspace-level role, you can specify whether this role is mapped to a role of the MaxCompute project 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 project that is associated with the workspace.
    Note For more information about how to create a custom role, see Step 2: Create and manage custom workspace-level roles (Optional). For more information about how to add a workspace member and grant permissions to the workspace member, see Step 3: Add and manage workspace members.
    • DataWorks: After the custom workspace-level role is assigned to the RAM user, the RAM user has permissions only on the DataWorks service modules specified in the rule.
    • MaxCompute:
      • If the custom workspace-level role is not mapped to a role of the MaxCompute project, the RAM user does not have permissions on the MaxCompute project. The RAM user cannot query tables in the MaxCompute project.
      • If the custom workspace-level role is mapped to a role of the MaxCompute project, the RAM user has the permissions of the mapped MaxCompute role.
    Note If a RAM user is specified as the access identity of a MaxCompute project in the production environment, the RAM user can access tables in the production environment after the RAM user is added to the workspace associated with the MaxCompute project. 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 Associate a MaxCompute compute engine instance with a workspace.

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 associated with the workspace Permission on data in the production environment of a DataWorks workspace and data in the MaxCompute project associated with the workspace Permission on a DataWorks workspace
Workspace Manager Role_Project_Admin
  • MaxCompute: all permissions on the project and the tables, functions, resources, instances, jobs, and packages of the project.
  • DataWorks: permissions to develop data and deploy nodes to the production environment.
No permissions by default. You must apply for the permissions in Security Center. 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
  • MaxCompute: all permissions on the project and the functions, resources, instances, jobs, packages, and tables of the project.
  • DataWorks: permissions to develop data but no permissions to deploy nodes to the production environment.
No permissions by default. You must apply for the permissions in Security Center. 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.
No permissions by default. You must apply for the permissions in Security Center. 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. No permissions by default. You must apply for the permissions in Security Center. Same permissions as the O&M role, except for online O&M permissions
Visitor Role_Project_Guest No permissions by default. No permissions by default. You must apply for the permissions in Security Center. Permissions to view data but no permissions to edit workflows or code
Safety Manager Role_Project_Security No permissions by default. No permissions by default. You must apply for the permissions in Security Center. Permissions to configure sensitivity rules and audit data risks in Data Security Guard
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. DataStudio
For a global service module, such as Data Map, the workspace name is not displayed in the top navigation bar. Data Map