How to use RBAC to control feature permissions-阿里云帮助中心

Global and workspace-level services

Log on to the DataWorks console and enter a DataWorks workspace. Click the icon in the upper-left corner to view all DataWorks services, as shown in the figure. DataWoks界面 Click a service to open its page. On the service page:

If the top navigation bar displays the workspace name, it is a workspace-level service. For example, DataStudio.
If the top navigation bar does not display a workspace name, it is a global-level service. For example, DataMap.

Note

For details on how to differentiate between global and workspace-level services, see Appendix: Differentiating between workspace-level and global-level services.

Global and workspace-level roles

The DataWorks permission system for service usage is built on a Role-Based Access Control (RBAC) model. You can define global and workspace-level roles for global and workspace-level services, respectively. When you assign a role to a user (a RAM user or RAM role), that user gains the role's permissions to use the corresponding DataWorks services.

Key concepts:

User: An identity, which can be a RAM user or a RAM role.
Role: A collection of permissions. Roles can be at the workspace level or global level.
Permission: The right to use workspace-level or global-level services.

DataWorks provides built-in global and workspace-level roles that you can assign directly to users. You can also create custom global or workspace-level roles based on your needs. The relationship between users, roles, and permissions is shown in the following figure. RBAC权限模型

Note

Among all roles, only the global Tenant Administrator role has permissions to use all services.
All RAM users under an Alibaba Cloud account are granted the Tenant Member role by default.
If a Tenant Administrator creates a custom global role that restricts access to certain global services, that role's permissions take precedence over the permissions of the Tenant Member role.

For example, a RAM user (User A) is a Tenant Member by default and can access the DataMap service. If a tenant administrator creates a custom role that denies access to DataMap and assigns this role to User A, User A will no longer be able to access the service.

Global roles

DataWorks global roles include tenant administrator, tenant member, tenant security administrator, data directory administrator, metadata collection administrator, and data governance administrator. The following table describes the permissions of each role.

Role	Permissions	Authorizer	Description
Tenant Administrator	Permissions to use all DataWorks services, excluding operations in the DataWorks console.	The tenant owner (the Alibaba Cloud account), a RAM user with the AliyunDataWorksFullAccess policy, a user with AdministratorAccess permissions, or another Tenant Administrator can grant the Tenant Administrator role to a RAM user.	The highest-level administrator in DataWorks, who can operate all services within the product.
Tenant Member	Has the same usage permissions as the current developer role. Read-only permissions on Data Security Guard Standard permissions on Security Center, excluding full permission auditing Standard permissions on Data Map, excluding the permissions of the data directory administrator and metadata collection administrator roles Permissions to use DataAnalysis Standard permissions on Approval Center, excluding permission to manage approval policies	No authorization is required. By default, all RAM users under the current Alibaba Cloud account are granted the Tenant Member role.	All RAM users and RAM roles under the current Alibaba Cloud account are Tenant Member by default.
tenant security administrator	Full permissions on Security Center, Approval Center, and Data Security Guard.	A Tenant Administrator can grant the Security Administrator role to other RAM users.	Manages security-related configurations in DataWorks.
Data Governance Administrator	Standard permissions on Data Governance Center (excluding service activation and creating, enabling, or disabling check items), plus management permissions for Data Governance Center.	A Tenant Administrator can grant the Data Governance Administrator role to other users.	Manages tasks within Data Governance Center.
Data Directory Administrator	Standard permissions on DataMap and permissions to manage the DataMap Data Catalog feature.	A Tenant Administrator can grant the Data Directory Administrator role to other users.	Manages the data directory feature in Data Map.
Metadata Collection Administrator	Standard permissions on DataMap and permissions for Metadata Collection.	A Tenant Administrator can grant the Metadata Collection Administrator role to other users.	Manages the metadata collection feature in Data Map.

Workspace-level roles

DataWorks provides various built-in workspace-level roles and also allows you to create custom workspace-level roles to meet your access control needs.

Built-in workspace-level roles

DataWorks provides the following built-in roles: Project Owner, Data Analyst, Workspace Administrator, Development, O&M Personnel, Deployment Personnel, Visitor, Security Administrator, and Model Designer.

Note
The workspace owner is the Alibaba Cloud account that creates the workspace. RAM users create workspaces on behalf of the Alibaba Cloud account. You cannot grant the Project Owner role to other users. For details on the permissions of each built-in role for different DataWorks services, see Appendix: Permission list of built-in workspace-level roles.
Custom workspace-level roles

Custom workspace-level roles let you control permissions for specific workspace-level services. For instructions on how to create a custom role, see Manage permissions for workspace-level services.

When you use workspace-level roles to manage access to workspace-level services, permissions apply to two types of objects: DataWorks service operations and compute engine operations (such as permissions to create, read, update, and delete tables and resources). The following table describes the permissions of built-in and custom roles for these two types of objects.

Permission object	Built-in roles	Custom roles
DataWorks service operations	DataWorks predefines the permissions of each role on workspace-level services. For details, see Appendix: Permission list of built-in workspace-level roles.	When you create a custom role, you specify the role's permissions for specific workspace-level services.
Permissions for MaxCompute compute engine	Permissions on the MaxCompute compute engine in the development environment: By default, built-in workspace-level roles have some permissions on the MaxCompute compute engine in the development environment. This means users with these roles can directly access MaxCompute tables there. For details on the permissions of each built-in workspace-level role on the MaxCompute compute engine in the development environment, see Appendix: Mappings between built-in workspace-level roles and MaxCompute permissions. Permissions on the MaxCompute compute engine in the production environment: Built-in workspace-level roles do not have permissions on the MaxCompute compute engine in the production environment. To access MaxCompute tables in the production environment, you must request permissions through Security Center. For details, see MaxCompute data access control.	When you create a custom role, if you map it to a MaxCompute compute engine role, the custom role inherits the permissions of the mapped MaxCompute role.
Permissions for EMR compute engine	When you register an EMR cluster, you can map workspace members to accounts to grant compute engine permissions. For details, see DataStudio (legacy): Bind an EMR compute resource.
Permissions for CDH compute engine	You can grant compute engine permissions by mapping workspace members to Linux or Kerberos accounts. For details, see Configure a workspace.
Permissions for other compute engines	Before using any compute engine with DataWorks, you must first create a data source in DataWorks. When creating a data source for other compute engines, you must configure a scheduling identity for both the development environment and production environment (for example, an AnalyticDB for PostgreSQL data source requires a database username and password). Users with workspace-level roles (both built-in and custom) use the scheduling identity configured for the data source when executing tasks. This means that workspace-level roles do not directly manage permissions for non-MaxCompute compute engines; access is governed by the identity specified when the data source is created.

As described above:

DataWorks provides built-in workspace-level roles and maps them to roles in the compute engine associated with the workspace. This allows the built-in roles to inherit some compute engine operation permissions.
DataWorks supports custom workspace-level roles. When creating a custom role, you can also map it to compute engine roles to grant it compute engine operation permissions.

Therefore, after you assign a workspace-level role to a user, the user gains permissions for both DataWorks service operations and compute engine operations. The following scenarios use the MaxCompute compute engine as an example to explain the permission logic after assigning built-in and custom workspace-level roles.

Scenario 1: Assign a built-in workspace-level role
A workspace administrator adds a RAM user as a workspace member and grants them the built-in Development role.

Note
For information about how to add a member and grant permissions, see Manage permissions for workspace-level services.

Once added, the RAM user has permissions for both DataWorks and the MaxCompute compute engine. The operational permissions are as follows:
- At the DataWorks level: With the Development role, the user can write and commit code in DataWorks but cannot deploy it to the production environment. Deployment requires O&M permissions, which are held by roles such as Project Owner, Administrator, and O&M Personnel.
- At the MaxCompute compute engine level: Granting the Development role also assigns the Role_Project_Dev role in the MaxCompute compute engine to the RAM user. This role grants permissions for some tables and the project in the MaxCompute development environment.
  Note
  
  Even if a RAM user is granted a built-in administrator role with extensive DataWorks permissions, they still cannot directly access production tables.
  
  The RAM user mentioned here refers to a sub-account that has not been designated as a scheduling access identity for the MaxCompute compute engine in the production environment.
Scenario 2: Assign a custom workspace-level role
A workspace administrator adds a RAM user as a workspace member and grants them a custom workspace role.When you create a custom role, you can specify whether to map it to a role in the MaxCompute compute engine. After the custom role is created and assigned to a member, the RAM user gains partial permissions at both the DataWorks and MaxCompute compute engine levels. The operational permissions are as follows.

Note
For instructions on how to create a custom role, see Manage permissions for workspace-level services. For information about how to add a member and grant permissions, see Manage permissions for workspace-level services.
- At the DataWorks level: A user with a custom DataWorks role can access only the services permitted by that role.
- At the MaxCompute compute engine level:
  - If the custom DataWorks role is not mapped to a compute engine role, the RAM user has no operational permissions on the MaxCompute compute engine and cannot run commands for queries or other operations.
  - If the custom DataWorks role is mapped to a compute engine role, the RAM user inherits the permissions of the mapped MaxCompute role.
Note
A RAM user added as a workspace member has no default permissions in the production environment, unless the user is designated as the scheduling access identity for the MaxCompute compute engine. To operate on or access production tables, the user must apply for permissions in Security Center. For details, see: Apply for table permissions in Security Center. For more information about MaxCompute access identities, see: Configure a workspace.

Workspace role mapping to MaxCompute permissions

The following table describes the permission mappings between DataWorks built-in workspace-level roles and roles in a MaxCompute development project, along with their permission details.

DataWorks member role	MaxCompute role	Data permissions (development)	Data permissions (production)	DataWorks permission highlights
workspace administrator	Role_Project_Admin	At the MaxCompute compute engine level: All permissions on the project/table/function/resource/instance/job; `read` permission on `package`; and management permissions such as creating table/function/resource/instance. At the DataWorks level: Can develop and deploy tasks to the production environment.	No default permissions. Permissions must be requested through an approval process in Security Center.	This is the manager of the workspace, who can manage the basic properties, data sources, compute engine configurations, and members of the workspace. This role can also grant other roles, such as workspace administrator, developer, O&M, deployment, and visitor, to other members.
developer	Role_Project_Dev	At the MaxCompute compute engine level: All permissions on the project/table/function/resource/instance/job, and `read` permission on `package`. At the DataWorks level: Can develop but cannot deploy tasks to the production environment.		A user with the developer role can create workflows, script files, resources, and UDFs, as well as create and delete tables. They can also create deployment packages but cannot perform deployment operations.
O&M	Role_Project_Pe	All permissions on the project/function/resource/instance/job; Read permission on package; and Read/Describe permissions on table. Note Although this role has permissions at the MaxCompute compute engine level, users with the O&M role cannot run nodes directly from the DataWorks UI to execute tasks.		A workspace administrator grants the O&M role. This role provides permissions for deployment and online O&M, but not for data development.
deployment	Role_Project_Deploy	No default permissions.		The deployment role is similar to the O&M role but lacks permissions for online O&M operations.
data analyst	Role_Project_Data_Analyst	No default permissions.		By default, this role only grants permissions to use the DataAnalysis service.
visitor	Role_Project_Guest	No default permissions.		A user with the visitor role only has view permissions and cannot edit workflows, code, or other assets.
security administrator	Role_Project_Security	No default permissions.		The security administrator role is used only in the Data Security Guard service for tasks such as configuring sensitivity rules and auditing data risks.
model designer	Role_Project_Erd	No default permissions.		Can view models and edit content related to data warehouse planning, data standards, dimensional modeling, and data metrics, but cannot publish models.
N/A	Project Owner	The owner of the MaxCompute project, with full permissions on that project.	Has permissions.	N/A
N/A	Super_Administrator	The super administrator of the MaxCompute project, with management permissions on the project and full permissions on all resource types within it.	Has permissions.	N/A
N/A	Admin	When a project is created, an Admin role is automatically created and granted specific permissions. It can access all objects within the project, manage users or roles, and grant permissions. Unlike the Project Owner, the Admin role cannot assign Admin permissions to other users, configure the project's security settings, or modify the project's authentication model. The permissions of the Admin role cannot be modified. The Project Owner can assign the Admin role to a user to delegate security management.	Has permissions.	N/A

Workspace vs. global services

A service is workspace-level if the top navigation bar displays the workspace name, such as DataStudio.

A service is global-level if the top navigation bar does not display a workspace name, such as DataMap.