MaxCompute supports label-based access control. You can assign sensitivity level labels to tables or columns and access level labels to users at the project level. Users can access data in a MaxCompute project only if its sensitivity level is less than or equal to their assigned access level. This topic describes how to manage these permissions and provides examples.
How it works
Label-based access control, also known as LabelSecurity, is a project-level mandatory access control (MAC) policy that is disabled by default.
A project owner can run the SET LabelSecurity=true|false; command to enable or disable LabelSecurity at the project level.
After you enable LabelSecurity, the project owner must perform the following actions:
Define clear sensitivity levels for tables or columns.
Define user access level classifications.
Assign sensitivity level labels to tables or columns, and access level labels to users or roles.
When a user accesses data that is assigned a sensitivity level, the user must have SELECT permission for the target table and can access the table or column data only if its sensitivity level is less than or equal to the user's access level.
Supported features
Column-level support: The finest supported granularity is the column level. You can set sensitivity level labels for any column in a table. This allows a table to consist of columns with different sensitivity levels.
View support: You can set sensitivity level labels for views. A view's sensitivity level label is independent of the labels on its source tables.
Setting sensitivity level labels on partition columns is not supported.
Supported operations
A project owner or a user with the Admin role can perform the following operations.
You can perform these operations by using tools such as the MaxCompute client, MaxCompute Studio, and DataWorks.
Default access control policies
No-ReadUp: Prohibits users from accessing data with a sensitivity level greater than their access level. If your business scenario requires this, you must perform an explicit grant. For more information, see Explicitly grant label permissions.
Trusted-User: Allows users to write data with a sensitivity level no higher than their access level. Newly created tables or views default to level 0 (not confidential). New users also default to level 0.
Usage notes
Some traditional MAC systems support more complex security policies to prevent the arbitrary distribution of data within a project.
For example, the No-WriteDown policy prohibits users from writing data to a sensitivity level lower than their access level. To reduce the management cost of data sensitivity levels, MaxCompute does not support the No-WriteDown policy by default.
If your project requires similar restrictions, you can run the
Set ObjectCreatorHasGrantPermission=false;command to modify the project's security configuration to meet your needs.To prevent data from flowing between different projects, you can run the
set ProjectProtection=true;command to enable the ProjectProtection feature. Once enabled, this feature restricts data access to the current project, preventing data from leaving it. For more information about project data protection, see Data protection mechanism.When you delete an object, MaxCompute automatically revokes all label permissions associated with it.
When you remove a user from a project, MaxCompute retains their permissions. If you later add the user back to the project, their previous permissions are reactivated. To permanently clear a user's permission information, see Permanently clear permission information left by deleted users.
Prerequisites
Before you use the label-based access control solution, you need the following information:
The account name or role name of the grantee. You must add the account or role to the MaxCompute project.
Format for an Alibaba Cloud account: ALIYUN$<account_id>
Format for a RAM user account: RAM$<account_id>:<RAM_user_UID>
Format for a RAM role account:
RAM$<account_id>:role/<RAM_role_name>
Run the
LIST users;orLIST roles;command in the MaxCompute client to obtain account or role information.To add a new user or role, see User Planning and Management or Role Planning.
The name of the target table or column.
Run the
SHOW TABLES;command in the MaxCompute client to obtain the names of tables or views, and columns.
Set sensitivity levels for tables or columns
A project owner or a user with the Admin role can set sensitivity level labels for tables or columns.
Command syntax
SET LabelSecurity=true; SET Label <number> TO TABLE <table_name>[(<column_list>)];Usage notes
If you set a sensitivity level label for a table but not for its columns, all columns in the table inherit the table's sensitivity level.
A column-level label always overrides the table-level label. Setting a table-level label does not affect existing column-level labels. For example, if you initially set a table's sensitivity level to 2 and then set the sensitivity level of a column named col1 to 3, the table's sensitivity level remains 2, the sensitivity level of col1 becomes 3, and other columns remain at level 2.
To modify an existing sensitivity level label on a table or column, run the command again with the new level.
To remove a label, set its sensitivity level to 0.
Parameters
Parameter
Required
Description
number
Yes
Specifies the sensitivity level. Valid values: 0 to 9. Higher values indicate greater sensitivity.
table_name
Yes
The name of the target table or view.
Run the
SHOW TABLES;command in the MaxCompute client to obtain table or view names.column_list
No
Specifies one or more column names. Separate multiple column names with commas (,).
Set access levels for users or roles
A project owner or a user with the Admin role can set access level labels for other users or roles.
Command syntax
SET LabelSecurity=true; SET Label <number> TO {USER|ROLE} <name>;Usage notes
After an access level label is set for a user, the user can access only data with a sensitivity level that is less than or equal to their access level. For example, if a user is assigned an access level of 3, they can only access data with a sensitivity level from 0 to 3.
To modify an existing access level label for a user or role, run the command again with the new access level label.
Parameters
Parameter
Required
Description
number
Yes
Specifies the highest data sensitivity level that the user or role can access. Valid values: 0 to 9.
name
Yes
The name of the user or role.
Run the
LIST users;orLIST roles;command in the MaxCompute client to obtain account or role information.
Explicitly grant label permissions
A project owner or a user with the Admin role can grant users permission to access data that exceeds their assigned access level.
Command syntax
GRANT Label <number> ON TABLE <table_name> [(<column_list>)] TO {USER|ROLE} <name> [WITH exp <days>];Usage notes
For a given user, an explicit grant on a column overrides an explicit grant on the parent table.
Parameters
Parameter
Required
Description
number
Yes
The highest data sensitivity level that the user or role can access.
This value corresponds to the data sensitivity level labels. Valid values: 0 to 9.
table_name
Yes
The name of the target table or view.
Run the
SHOW TABLES;command in the MaxCompute client to obtain table or view names.column_list
No
Specifies the columns for which to grant permissions. You can specify multiple column names separated by commas (,).
name
Yes
The name of the user or role.
Run the
LIST users;orLIST roles;command in the MaxCompute client to obtain account or role information.days
No
The expiration period of the permission in days. Valid values: 0 to 263-1. If you do not specify this parameter, the permission is valid for 180 days by default.
Revoke explicit label permissions
A project owner or a user with the Admin role can revoke explicit label permissions.
Command syntax
REVOKE Label ON TABLE <table_name> [(<column_list>)] FROM {USER|ROLE} <name>;Usage notes
Revoking an explicit grant on a table also revokes any explicit grants on that table's columns for the same user.
Revoking an explicit grant does not affect the user's assigned access level. For example, a user has an access level of 2 and is explicitly granted access to data with a sensitivity level up to 3 in a table. After the explicit grant is revoked, the user can still access data with a sensitivity level of 2 or less in the table.
Parameters
Parameter
Required
Description
table_name
Yes
The name of the target table or view.
Run the
SHOW TABLES;command in the MaxCompute client to obtain table or view names.column_list
No
Specifies the columns from which to revoke permissions. You can specify multiple column names separated by commas (,).
name
Yes
The name of the user or role.
Run the
LIST users;orLIST roles;command in the MaxCompute client to obtain account or role information.
Clear expired permissions
After explicit grants expire, a project owner or a user with the Admin role must run the following command to clear them.
clear expired grants;Examples
Assume that a project named test_project contains a table named sale_detail. The table has the columns shop_name, customer_id, and total_price.
Bob@aliyun.com is the project owner of test_project. Allen is a RAM user under Bob's Alibaba Cloud account, and Bob has added Allen to the test_project project.
The following statement is used to create the table:
CREATE TABLE sale_detail (
shop_name STRING COMMENT 'Shop name',
customer_id STRING COMMENT 'Customer ID',
total_price DOUBLE COMMENT 'Order total price'
);Example 1: Set sensitivity levels
-- Bob enters the test_project project.
USE test_project;
-- Set the label of the sale_detail table to level 1. At this point, all columns in the table have a sensitivity level of 1.
SET Label 1 TO TABLE sale_detail;
-- Set the label for the shop_name and customer_id columns of sale_detail to level 2. Other columns remain at level 1.
SET Label 2 TO TABLE sale_detail(shop_name, customer_id);
-- View the label information of the table.
DESCRIBE sale_detail;
-- The result is as follows:
+------------------------------------------------------------------------------------+
| TableLabel: |
| MaxLabel: L2 |
+------------------------------------------------------------------------------------+
| InternalTable: YES | Size: 0 |
+------------------------------------------------------------------------------------+
| Native Columns: |
+------------------------------------------------------------------------------------+
| Field | Type | Label | Comment |
+------------------------------------------------------------------------------------+
| shop_name | string | 2 | Shop name |
| customer_id | string | 2 | Customer ID |
| total_price | double | 1 | Order total price |
+------------------------------------------------------------------------------------+
-- Modify the label of the sale_detail table to level 3. Note that the labels for the shop_name and customer_id columns remain at level 2, and the labels for other columns are changed to 3.
SET Label 3 TO TABLE sale_detail;
-- View the label information of the table.
DESCRIBE sale_detail;
-- The result is as follows:
+------------------------------------------------------------------------------------+
| TableLabel: 3 |
| MaxLabel: L3 |
+------------------------------------------------------------------------------------+
| InternalTable: YES | Size: 0 |
+------------------------------------------------------------------------------------+
| Native Columns: |
+------------------------------------------------------------------------------------+
| Field | Type | Label | Comment |
+------------------------------------------------------------------------------------+
| shop_name | string | 2 | Shop name |
| customer_id | string | 2 | Customer ID |
| total_price | double | 3 | Order total price |
+------------------------------------------------------------------------------------+
-- Modify the label for the shop_name and customer_id columns of the sale_detail table to level 4. The labels for other columns remain at level 3.
SET Label 4 TO TABLE sale_detail(shop_name, customer_id);
-- View the label information of the table.
DESCRIBE sale_detail;
-- The result is as follows:
+------------------------------------------------------------------------------------+
| TableLabel: 3 |
| MaxLabel: L4 |
+------------------------------------------------------------------------------------+
| InternalTable: YES | Size: 0 |
+------------------------------------------------------------------------------------+
| Native Columns: |
+------------------------------------------------------------------------------------+
| Field | Type | Label | Comment |
+------------------------------------------------------------------------------------+
| shop_name | string | 4 | Shop name |
| customer_id | string | 4 | Customer ID |
| total_price | double | 3 | Order total price |
+------------------------------------------------------------------------------------+Example 2: Set user access levels
Regular user in the project: Kate@aliyun.com
RAM user in the project: RAM$Bob@aliyun.com:Allen
-- Bob enters the test_project project.
USE test_project;
-- Set the access level label for Kate to 3. Kate can access data with a sensitivity level from 0 to 3.
SET Label 3 TO USER ALIYUN$Kate@aliyun.com;
-- Set the access level label for the RAM user Allen to 1. Allen can access data with a sensitivity level from 0 to 1.
SET Label 1 TO USER RAM$Bob@aliyun.com:Allen;
-- View the access level information for Allen.
SHOW LABEL GRANTS FOR RAM$Bob@aliyun.com:Allen;
-- The result is as follows:
User Label: 1
(granted label list is empty)Example 3: Grant explicit permissions
-- Enter the test_project project.
USE test_project;
-- Explicitly grant Allen permission to access data with a sensitivity level up to 3 in the sale_detail table. The permission is valid for 4 days.
GRANT LABEL 3 ON TABLE sale_detail TO USER RAM$Bob@aliyun.com:Allen WITH exp 4;
-- View the result of the explicit grant for Allen.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
-- The result is as follows:
User Label: 1
+-------------+--------------+--------------------------+
| Column | GrantedLabel | Expires |
+-------------+--------------+--------------------------+
| total_price | 3 | 2025-12-26T11:13:20+0800 |
+-------------+--------------+--------------------------+
-- Explicitly grant Allen permission to access data with a sensitivity level up to 4 in the shop_name, customer_id, and total_price columns of the sale_detail table. The permission is valid for 10 days.
GRANT LABEL 4 ON TABLE sale_detail(shop_name, customer_id, total_price) TO USER RAM$Bob@aliyun.com:Allen WITH exp 10;
-- View the result of the explicit grant for Allen.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
-- The result is as follows:
User Label: 1
+-------------+--------------+--------------------------+
| Column | GrantedLabel | Expires |
+-------------+--------------+--------------------------+
| customer_id | 4 | 2026-01-01T11:14:40+0800 |
+-------------+--------------+--------------------------+
| shop_name | 4 | 2026-01-01T11:14:40+0800 |
+-------------+--------------+--------------------------+
| total_price | 4 | 2026-01-01T11:14:40+0800 |
+-------------+--------------+--------------------------+Example 4: Revoke explicit permissions
-- In the previous data permission configuration:
-- First, Allen was explicitly granted permission to access data with a sensitivity level up to 3 in the sale_detail table.
-- Then, Allen was explicitly granted permission to access data with a sensitivity level up to 4 in the shop_name, customer_id, and total_price columns of the sale_detail table.
-- Revoke the column-level data access permission for Allen on the shop_name, customer_id, and total_price columns of the sale_detail table.
REVOKE LABEL ON TABLE sale_detail(shop_name, customer_id, total_price) FROM USER RAM$Bob@aliyun.com:Allen;
-- View the result after the permission is revoked for Allen.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
--The result is as follows:
-- Revoke the permission for Allen to access sensitive data in the sale_detail table.
REVOKE LABEL ON TABLE sale_detail FROM USER RAM$Bob@aliyun.com:Allen;
--View the result after the permission is revoked for Allen.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
--The result is as follows:
User Label: 1
(granted label list is empty)Next steps
After you understand the label-based authorization mechanism, you can grant permissions as needed: