MaxCompute uses a layered permission model that combines role-based access control (RBAC) and discretionary access control (DAC): permissions are assigned to roles, roles are assigned to users, and object owners can grant access directly. Every operation — from querying a table to managing project settings — goes through this model.
This topic explains the building blocks of the permission system, how authentication works, and how permissions flow from administrators to end users.
Key concepts
The permission system is built around three core components: principals (who), objects (what), and access control (how).
Principals
MaxCompute recognizes two types of principals:
Users: Alibaba Cloud accounts, RAM users, and RAM roles. Administrators add, remove, and query users at the project level.
Roles: MaxCompute includes built-in administrator roles and supports custom roles. You can add, remove, and query custom roles.
For user management details, see User planning and management. For role management, see Role planning.
Objects
MaxCompute enforces fine-grained access control on the following object types:
| Scope | Objects |
|---|---|
| Project level | Projects, tables, models, resources, functions, instances |
| Tenant level | Quotas, network connections (NetworkLink) |
For the full permissions list per object, see MaxCompute permissions.
Access control methods
MaxCompute provides five authorization methods to cover different scenarios:
| Method | Best for |
|---|---|
| ACL-based access control | Granting a user or role operation permissions on specific objects (projects, tables, models, resources, functions, or instances) |
| Policy-based access control | Granting a role operation permissions on objects, then assigning the role to multiple users |
| Download permission control | Controlling which users or roles can download tables, functions, or resources |
| Label-based access control | Restricting access to sensitive data by access level |
| Cross-project access using packages | Sharing resources across projects by packaging them and permitting other projects to install the package |
To grant the same permissions to multiple users, assign permissions to a role and then assign the role to users — this is simpler than granting permissions to each user individually. For role-based authorization operations, see Project-level role authorization.
To grant permissions directly to individual users, use direct authorization. For user authorization operations, see Manage user permissions using commands.
To view the current permissions of project members, see Query permission information.
DataWorks has its own permission system. If you manage a MaxCompute project through DataWorks, you can use DataWorks user and role management to assign roles. For the relationship between the two permission systems, see Permission relationship between MaxCompute and DataWorks.
Authentication process
Every MaxCompute operation goes through two layers of authentication: RAM (Resource Access Management) authentication and MaxCompute service authentication.
The Alibaba Cloud account that owns a resource has the highest level of permissions. It can perform all operations and delegate management permissions to RAM users or RAM roles, who can then grant permissions to others.
The following diagram shows the full authentication flow.
RAM authentication
RAM authentication applies when users need to activate services, purchase resources, or manage quotas, projects, or tenants in the MaxCompute console. If the user lacks the required RAM permissions, the operation is blocked.
For the list of operations that require RAM authentication, see RAM permissions.
To grant system policies to RAM users or RAM roles, see Manage the permissions of a RAM user.
MaxCompute service authentication
MaxCompute service authentication covers two scopes: project-level and tenant-level.
Project-level authentication
Project-level permissions fall into two categories:
Object operation permissions: Permissions to perform operations on projects and objects within them, such as
CreateTable,CreateModel,CreateInstance, andSelectTable. For the full list, see List of permissions on projects and objects in projects.Management permissions: Permissions for configuring project security, managing users and roles, managing packages, controlling label-based permissions, and clearing expired permissions. For the full list, see List of project management permissions.
When a user initiates a project-level operation, MaxCompute authenticates the request in the following order:
User authentication: The system verifies the user's identity. Log in to the MaxCompute console with an Alibaba Cloud account (primary account or RAM user). When connecting via odpscmd or JDBC, provide an AccessKey ID and AccessKey secret. A user can only initiate operations in a project after an administrator adds the user with the
add user "xxx"command. For details, see User authentication.IP address check: The system checks whether the request source IP is on the project's whitelist. For details, see Manage IP address whitelists.
Project status check: The system verifies that the project is in the Normal state.
Permission check: The system checks whether the user has the required permissions for the requested operation, based on the configured access control methods (access control list (ACL), Policy, Download permission control, Label-based access control, or Packages). For user permission management, see Manage user permissions using commands.
Tenant-level authentication
Tenant-level permissions also fall into two categories:
Object operation permissions: Permissions on tenant-level objects such as quotas and NetworkLink. Examples include
use quotaandCreateNetworkLink. One account can manage multiple Project objects through tenant-level operations, simplifying cross-project permission management. For the full list, see List of permissions on objects in a tenant.Management permissions: Permissions for adding or deleting tenant-level users, creating or deleting tenant-level roles, viewing tenant-level user and role lists, granting or revoking tenant-level roles to or from users, and adding or removing tenant-level roles from projects.
If a user does not have the required tenant-level permissions, the operation is blocked.
Authorization flows
The following flows cover the most common authorization scenarios.
Flow 1: Grant a user operation permissions on objects directly
Add the target user to the project, then grant the user operation permissions on objects using ACL-based access control.
Flow 2: Grant multiple users operation permissions via a role
Add the target users and a role to the project. Grant the role operation permissions using ACL-based, policy-based, or download permission control. Assign the role to the users.
Flow 3: Grant a user access to highly sensitive data directly
Add the target user to the project. The project owner or a user with the Admin role sets a permitted access level for the user. When the user needs access to specific highly sensitive data, the project owner or Admin user grants label-based permissions for that data.
Flow 4: Grant multiple users access to highly sensitive data via a role
Add the target users to the project. The project owner or a user with the Admin role sets a permitted access level for each user. Create a role, grant it label-based permissions on the highly sensitive data, and assign the role to the users.
Flow 5: Grant users in another project access to packaged resources directly
The source project owner creates a package, adds the resources, and permits the target project to install it. The target project owner installs the package and grants users access using ACL-based or label-based access control.
Flow 6: Grant users in another project access to packaged resources via a role
The source project owner creates a package, adds the resources, and permits the target project to install it. The target project owner installs the package, grants a role access using ACL-based or label-based access control, and assigns the role to the users.
Permission relationship between MaxCompute and DataWorks
Workspace modes and attached projects
When you create a DataWorks workspace, MaxCompute projects are automatically attached based on the workspace mode:
Basic Mode: One MaxCompute project is attached.
Standard Mode: Two MaxCompute projects are attached — a development (_dev) project and a production (Prod) project.
You also need to configure the MaxCompute visitor identity, which determines the account-level access policy for the attached MaxCompute project.
How the two permission systems interact
Managing permissions through MaxCompute commands does not affect how users interact in the DataWorks UI. DataWorks provides a visual interface to manage MaxCompute project permissions.
However, assigning roles to users in DataWorks does affect their MaxCompute permissions. The following table shows how DataWorks roles map to MaxCompute roles.
MaxCompute permissions corresponding to DataWorks roles are fixed. If a user is granted additional MaxCompute permissions through the command line, their actual MaxCompute permissions will differ from what DataWorks displays.
Role mapping
| DataWorks role | MaxCompute role | Permissions in dev environment | Permissions in prod environment | DataWorks permissions |
|---|---|---|---|---|
| Workspace Administrator | Role_Project_Admin | MaxCompute: All permissions on the project and its tables, functions, resources, instances, and jobs; Read on packages. DataWorks: Data development and task deployment to production. | None by default. Request permissions in Security Center. | Manages workspace properties, data sources, compute engine configurations, and members; assigns roles to workspace members. |
| Development | Role_Project_Dev | MaxCompute: All permissions on the project and its tables, functions, resources, instances, and jobs; Read on packages. DataWorks: Data development, but no task deployment to production. | None by default. Request permissions in Security Center. | Creates workflows, script files, resources, user-defined functions (UDFs), tables, and deployment tasks; deletes tables; no deployment permissions. |
| O&M | Role_Project_Pe | MaxCompute: All permissions on the project and its functions, resources, instances, and jobs; Read on packages; Read and Describe on tables. Note The O&M role has MaxCompute compute engine permissions but cannot run nodes in the DataWorks console. | None by default. Request permissions in Security Center. | Deployment and online O&M permissions granted by Workspace Administrator; no data development permissions. |
| Deploy | Role_Project_Deploy | None by default. | None by default. Request permissions in Security Center. | Similar to O&M, except without online O&M permissions. |
| Visitor | Role_Project_Guest | None by default. | None by default. Request permissions in Security Center. | Read-only access to data; cannot modify workflows or code. |
| Security Manager | Role_Project_Security | None by default. | None by default. Request permissions in Security Center. | Configures sensitive data identification rules and audits data risks in Data Security Guard. |
| Data Analyst | Role_Project_Data_Analyst | MaxCompute: CreateInstance and CreateTable permissions in the project. DataWorks: View models in Data Modeling; view and use features in DataAnalysis. | None by default. Request permissions in Security Center. | Permissions only on DataAnalysis. |
| Model Designer | Pole_Project_Erd | None by default. | None by default. Request permissions in Security Center. | Views models in Data Modeling; modifies parameter configurations in Data Warehouse Planning, Data Standard, Dimensional Modeling, and Data Metric; cannot publish models. |
| Data Governance Administrator | Role_Project_Data_Governance | None by default. | None by default. Request permissions in Security Center. | Permissions only on Data Governance Center; manages governance issues, plans, and check items; no data development or O&M permissions. |
| Workspace owner (Alibaba Cloud account) | Project Owner | All permissions on the project. | Same as dev environment. | — |
| — | Super_Administrator | Management permissions on the project and all permissions on all resource types. | Same as dev environment. | — |
| — | Admin | Access to all objects; manage users, roles, and permissions. Cannot assign the Admin role to users, configure security policies, modify the authentication model, or modify Admin role permissions. The project owner assigns this role to authorize security configuration management. | Same as dev environment. | — |
| — | Role_Project_Scheduler | None by default. | MaxCompute: All permissions on the project and its tables, functions, resources, instances, and jobs; Read on packages. DataWorks: Identity for committing tasks to production for scheduling. Note If you specify a RAM user or RAM role as the default access identity when adding a MaxCompute project to a workspace as a production data source, that identity receives Role_Project_Scheduler permissions. See Add a data source. | Schedules and runs MaxCompute tasks in the production environment. |
User management differences
DataWorks workspace: The workspace owner must be an Alibaba Cloud account. Workspace members must be RAM users belonging to the same Alibaba Cloud account. Add users and assign roles through Workspace Management.
MaxCompute project: An Alibaba Cloud account can be the project owner or a project member. RAM users of an Alibaba Cloud account can also be project members. Add a user with
add user xxx;, add a role withadd role xxx;, and assign the role withgrant role xxx to user xxx;.
The following figure shows the relationship between users and permissions across workspace modes and visitor identities.
