MaxCompute lets you assign label-based access levels to users at the project level and sensitivity labels to tables or table columns. Users can access only table or column data whose sensitivity level is less than or equal to their own access level. This topic describes how to grant label-based permissions and provides examples.
Overview
Label-based access control—also known as LabelSecurity—is a mandatory access control policy applied at the project level. It is disabled by default.
The project owner can run the SET LabelSecurity=true|false; command at the project level to enable or disable LabelSecurity.
After enabling LabelSecurity, the project owner must complete the following steps:
Define clear sensitivity levels for tables or table columns
Define standards for user access level classifications
Assign sensitivity labels to tables or table columns and assign access level labels to users or roles
When a user accesses data with a sensitivity label, the user must have SELECT permission on the target table. In addition, the user can access only table or column data whose sensitivity level is less than or equal to the user's access level.
Supported capabilities
Column-level support: The smallest supported granularity is the column level. You can assign sensitivity labels to any column in a table. A single table can contain columns with different sensitivity levels.
View support: You can assign sensitivity labels to views. A view's sensitivity label is independent of the sensitivity labels of its source tables.
You cannot assign sensitivity labels to partition key columns.
Supported operations
Project owners and users with the Admin role can perform the following operations.
Set data tag access for users or roles based on sensitivity level
Grant low-access-level users or roles permission to access highly sensitive data
Revoke permission to access highly sensitive data from users or roles
You can perform these operations using the MaxCompute client, MaxCompute Studio, or DataWorks.
Default access control policies
No-ReadUp: Users cannot access data whose sensitivity level exceeds their access level. If your business requires this behavior, you must explicitly grant permission. For more information about explicit grants, see Explicit label grants.
Trusted-User: Users can write data whose sensitivity level does not exceed their access level. By default, newly created tables or views have a sensitivity level of 0 (unclassified). New users are assigned an access level of 0 by default.
Scope of use
In some traditional mandatory access control (MAC) systems, complex security policies prevent data from being distributed arbitrarily within a project.
For example, users cannot write data whose sensitivity level is lower than or equal to their access permission level (No-WriteDown). However, MaxCompute does not support No-WriteDown by default due to the management overhead associated with sensitivity levels.
If your project has similar requirements, you can run the
Set ObjectCreatorHasGrantPermission=false;command to modify the project's secure configuration to achieve the control objective.To prevent data flow between projects, run the
set ProjectProtection=true;command to enable project protection. After enabling project protection, users can access data only within the project. This prevents data from flowing outside the project. For more information, see Data protection mechanism.If an object is deleted, MaxCompute automatically revokes all label-based permissions associated with that object.
When a user is removed, their existing permissions remain. If the user is later added back to the project, their historical permissions are reactivated. To completely remove a user's permissions, see Completely remove permissions left by a deleted user.
Prerequisites
Before using label-based access control, record the following information:
The account or role name of the user to be granted permissions. The account or role must already be added to the MaxCompute project.
An Alibaba Cloud account uses the format ALIYUN$<account_id>
A RAM user account uses the format RAM$<account_id>:<ram_user_uid>
A RAM role account uses the format `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 new users or roles, see User planning and management or Role planning.
The name of the table or column to be granted permissions.
Run the
SHOW TABLES;command in the MaxCompute client to list table or view names and column names.
Assign sensitivity labels to table or column data
A project owner or a user with the Admin role assigns sensitivity labels to tables or table columns.
Command syntax
SET LabelSecurity=true; SET Label <number> TO TABLE <table_name>[(<column_list>)];Notes
If you assign a sensitivity label to a table but not to its columns, all columns inherit the table's sensitivity level. For example, if you assign level 2 to a table and do not assign levels to its columns, all columns have level 2.
Column-level labels override table-level labels, regardless of level value. Table-level labels never override column-level labels. For example, if you assign level 2 to a table and then assign level 3 to column col1, the table retains level 2, col1 has level 3, and other columns retain level 2.
To change an existing sensitivity label for a table or column, run the command again with the new level.
Description
Parameter Name
Required
Description
number
Yes
The sensitivity level. Valid values: 0 to 9. Higher values indicate higher security.
table_name
Yes
The name of the target table or view.
Run the
SHOW TABLES;command in the MaxCompute client to list table or view names.column_list
No
The column name or names. Separate multiple column names with commas (,).
Assign access level labels to users or roles
A project owner or a user with the Admin role assigns access level labels to other users or roles.
Command syntax
SET LabelSecurity=true; SET Label <number> TO {USER|ROLE} <name>;Notes
After assigning an access level label to a user, the user can access only data whose sensitivity level is less than or equal to the assigned level. For example, if you assign level 3 to a user, the user can access only data with sensitivity levels 0 through 3.
To change an existing access level label for a user or role, run the command again with the new level.
Parameter description
Parameter Name
Required
Description
number
Yes
The highest sensitivity level that the user or role can access. Valid values: 0 to 9. This value corresponds to sensitivity labels.
name
Yes
The name of the user or role.
Run the
LIST users;orLIST roles;command in the MaxCompute client to list account or role information.
Explicit label grants
A project owner or a user with the Admin role grants low-access-level users permission to access highly sensitive data.
Command syntax
GRANT Label <number> ON TABLE <table_name> [(<column_list>)] TO {USER|ROLE} <name> [WITH exp <days>];Notes
A column-level explicit grant overrides a table-level explicit grant for the same user.
Parameter description
Parameter Name
Required
Description
number
Yes
The highest sensitivity level of data that the users or roles can access.
Valid values range from 0 to 9, and each value corresponds to a data sensitivity level tag.
table_name
Yes
The name of the target table or view.
Run the
SHOW TABLES;command in the MaxCompute client to list table or view names.column_list
No
Specify this parameter when granting access to specific columns in the target table or view. Separate multiple column names with commas (,).
name
Yes
The name of the user or role.
Run the
LIST users;orLIST roles;command in the MaxCompute client to list account or role information.days
No
The time-to-live (TTL) of the permission, in days. Valid values: 0 to 263-1. If omitted, the default TTL is 180 days.
Revoke explicit label grants
A project owner or a user with the Admin role revokes explicit label grants.
Command syntax
REVOKE Label ON TABLE <table_name> [(<column_list>)] FROM {USER|ROLE} <name>;Notes
Revoking a table-level explicit grant also revokes all column-level explicit grants for the same user.
Revoking explicit label grants does not affect the user's access level label. For example, if a user has access level 2 and was explicitly granted access to data with sensitivity level up to 3, the user can still access data with sensitivity level up to 2 after the grant is revoked.
Metric description
Parameter Name
Required
Description
table_name
Yes
The name of the target table or view.
Run the
SHOW TABLES;command in the MaxCompute client to list table or view names.column_list
No
Specify this parameter when revoking access to specific columns in the target table or view. Separate multiple column names with commas (,).
name
Yes
The name of the user or role.
Run the
LIST users;orLIST roles;command in the MaxCompute client to list account or role information.
Clean up expired permissions
After explicit label grants expire, a project owner or a user with the Admin role must run the following command to clean up expired permission information.
clear expired grants;Label-based access control examples
Assume a table named sale_detail exists in the project test_project. The table has 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 and has been added to test_project.
The table creation statement is as follows:
CREATE TABLE sale_detail (
shop_name STRING COMMENT 'Shop name',
customer_id STRING COMMENT 'Customer ID',
total_price DOUBLE COMMENT 'Order total'
);Example 1: Assign sensitivity labels to the sale_detail table or its columns
-- Bob enters the test_project.
USE test_project;
-- Set the table sale_detail to sensitivity level 1. All columns now have level 1.
SET Label 1 TO TABLE sale_detail;
-- Set columns shop_name and customer_id to level 2. Other columns remain at level 1.
SET Label 2 TO TABLE sale_detail(shop_name, customer_id);
-- View the table's label information.
DESCRIBE sale_detail;
-- Output
+------------------------------------------------------------------------------------+
| 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 | | Order total |
+------------------------------------------------------------------------------------+
-- Change the table sale_detail to level 3. Columns shop_name and customer_id remain at level 2. Other columns change to level 3.
SET Label 3 TO TABLE sale_detail;
-- View the table's label information.
DESCRIBE sale_detail;
-- Output
+------------------------------------------------------------------------------------+
| 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 |
+------------------------------------------------------------------------------------+
-- Change columns shop_name and customer_id to level 4. Other columns remain at level 3.
SET Label 4 TO TABLE sale_detail(shop_name, customer_id);
-- View the table's label information.
DESCRIBE sale_detail;
-- Output
+------------------------------------------------------------------------------------+
| TableLabel: |
| 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 | | Order total |
+------------------------------------------------------------------------------------+Example 2: Assign access level labels to regular users and RAM users in the project
A regular user in the project: Kate@aliyun.com
A RAM user in the project: RAM$Bob@aliyun.com:Allen
-- Bob enters the test_project.
USE test_project;
-- Set Kate's access level to 3. Kate can access data with sensitivity levels 0 to 3.
SET Label 3 TO USER ALIYUN$Kate@aliyun.com;
-- Set RAM user Allen's access level to 1. Allen can access data with sensitivity levels 0 to 1.
SET Label 1 TO USER RAM$Bob@aliyun.com:Allen;
-- View Allen's access level.
SHOW LABEL GRANTS FOR RAM$Bob@aliyun.com:Allen;
-- Output
User Label: 1
(granted label list is empty)Example 3: Explicitly grant Allen permission to access highly sensitive data
-- Enter the test_project.
USE test_project;
-- Explicitly grant Allen permission to access data in sale_detail with sensitivity level up to 3. The grant expires in 4 days.
GRANT LABEL 3 ON TABLE sale_detail TO USER RAM$Bob@aliyun.com:Allen WITH exp 4;
-- View Allen's explicit grants.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
-- Output:
User Label: 1
+-------------+--------------+--------------------------+
| Column | GrantedLabel | Expires |
+-------------+--------------+--------------------------+
| total_price | 3 | 2025-12-26T11:13:20+0800 |
+-------------+--------------+--------------------------+
-- Explicitly grant Allen permission to access columns shop_name, customer_id, and total_price in sale_detail with sensitivity level up to 4. The grant expires in 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 Allen's explicit grants.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
-- Output:
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 Allen's permission to access highly sensitive data
-- Previously:
-- First, explicitly granted Allen permission to access data in sale_detail with sensitivity level up to 3.
-- Then, explicitly granted Allen permission to access columns shop_name, customer_id, and total_price in sale_detail with sensitivity level up to 4.
-- Revoke Allen's permission to access columns shop_name, customer_id, and total_price in sale_detail.
REVOKE LABEL ON TABLE sale_detail(shop_name, customer_id, total_price) FROM USER RAM$Bob@aliyun.com:Allen;
-- View Allen's revoked grants.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
-- Output:
-- Revoke Allen's permission to access sensitive data in sale_detail.
REVOKE LABEL ON TABLE sale_detail FROM USER RAM$Bob@aliyun.com:Allen;
-- View Allen's revoked grants.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
-- Output:
User Label: 1
+-------------+--------------+---------+
| Column | GrantedLabel | Expires |
+-------------+--------------+---------+
| total_price | 1 | |
+-------------+--------------+---------+Next steps
After learning how label-based authorization works, grant permissions based on your business needs: