MaxCompute lets you assign sensitivity labels to tables or columns and access level labels to users or roles. Users can access only data whose sensitivity level is less than or equal to their access level. This topic describes how label-based access control works and how to manage sensitivity labels and access level labels.
How label-based access control works
Label-based access control — also known as LabelSecurity — is a mandatory access control (MAC) policy applied at the project level. It is disabled by default.
LabelSecurity uses two types of labels:
-
Sensitivity labels — assigned to tables or columns, indicating how sensitive the data is. Valid values: 0–9. Higher values indicate higher sensitivity.
-
Access level labels — assigned to users or roles, indicating the maximum sensitivity level they can access. Valid values: 0–9.
A user can access data only when both conditions are met:
-
The data's sensitivity level is less than or equal to the user's access level.
-
The user has SELECT permission on the table.
Newly created tables and views have a default sensitivity level of 0. New users have a default access level of 0.
Default access control policies
| Policy | Behavior |
|---|---|
| No-ReadUp | Users cannot read data whose sensitivity level exceeds their access level. To grant access above a user's level, use explicit label grants. |
| Trusted-User | Users can write data whose sensitivity level does not exceed their access level. |
| No-WriteDown | Not supported by default. To prevent users from writing data at a lower sensitivity level than their own, run Set ObjectCreatorHasGrantPermission=false; to modify the project's security configuration. |
Supported granularity
-
The smallest supported granularity is the column level. A single table can contain columns with different sensitivity levels.
-
Sensitivity labels can be assigned to views. A view's sensitivity label is independent of its source tables' labels.
-
Sensitivity labels cannot be assigned to partition key columns.
Workflow overview
To implement label-based access control, the project owner or a user with the Admin role completes the following steps in order:
| Step | Task | Details |
|---|---|---|
| 1 | Enable LabelSecurity | Run SET LabelSecurity=true; at the project level |
| 2 | Assign sensitivity labels | Label each table or column with a sensitivity level (0–9) |
| 3 | Assign access level labels | Set the maximum access level for each user or role (0–9) |
| 4 | Grant explicit access (if needed) | Grant individual users temporary access to data above their level |
| 5 | Revoke or clean up grants | Revoke explicit grants when no longer needed; clean up expired records |
Run the following command to enable or disable LabelSecurity:
SET LabelSecurity=true|false;
Limitations
-
To prevent data from flowing between projects, run
set ProjectProtection=true;to enable project protection. For more information, see Data protection mechanism. -
When an object is deleted, MaxCompute automatically revokes all label-based permissions associated with that object.
-
When a user is removed from a project, their existing permissions are retained. If the user is added back later, their historical permissions are reactivated. To completely remove a user's permissions, see Manage user permissions using commands.
Prerequisites
Before you begin, ensure that you have:
-
The account or role name of the user to be granted permissions. The account or role must already be added to the MaxCompute project. Run
LIST users;orLIST roles;in the MaxCompute client to get account or role information. To add users or roles, see User planning and management or Role planning.Account type Format Alibaba Cloud account ALIYUN$<account_id>RAM user RAM$<account_id>:<ram_user_uid>RAM role RAM$<account_id>:role/<ram_role_name> -
The name of the table or column to be labeled. Run
SHOW TABLES;in the MaxCompute client to list table and view names.
Perform all label operations using the MaxCompute client, MaxCompute Studio, or DataWorks.
Assign sensitivity labels to tables or columns
The project owner or a user with the Admin role runs this command to assign sensitivity labels to tables or columns.
Command syntax
SET LabelSecurity=true;
SET Label <number> TO TABLE <table_name>[(<column_list>)];
Parameters
| Parameter | Required | Description |
|---|---|---|
number |
Yes | The sensitivity level. Valid values: 0–9. Higher values indicate higher sensitivity. |
table_name |
Yes | The name of the target table or view. Run SHOW TABLES; in the MaxCompute client to list table and view names. |
column_list |
No | One or more column names. Separate multiple column names with commas (,). |
Usage notes
-
If you assign a sensitivity label to a table without specifying columns, all columns inherit the table's sensitivity level. For example, assigning level 2 to a table gives all columns level 2.
-
Column-level labels override table-level labels, regardless of which value is higher. Table-level labels never override column-level labels. For example, if a table is at level 2 and you assign level 3 to
col1, the table stays at level 2,col1has level 3, and other columns remain at level 2. -
To update an existing label, run the command again with the new level.
Assign access level labels to users or roles
The project owner or a user with the Admin role runs this command to assign access level labels to other users or roles.
Command syntax
SET LabelSecurity=true;
SET Label <number> TO {USER|ROLE} <name>;
Parameters
| Parameter | Required | Description |
|---|---|---|
number |
Yes | The maximum sensitivity level the user or role can access. Valid values: 0–9. |
name |
Yes | The name of the user or role. Run LIST users; or LIST roles; in the MaxCompute client to get this information. |
Usage notes
-
After assigning an access level label, the user can access only data whose sensitivity level is less than or equal to the assigned level. For example, a user at level 3 can access data with sensitivity levels 0 through 3.
-
To update an existing access level label, run the command again with the new level.
Grant explicit access to highly sensitive data
When a user's access level is lower than the sensitivity level of the data they need, the project owner or a user with the Admin role can grant explicit access for a specific table or columns.
Command syntax
GRANT Label <number> ON TABLE <table_name> [(<column_list>)] TO {USER|ROLE} <name> [WITH exp <days>];
Parameters
| Parameter | Required | Description |
|---|---|---|
number |
Yes | The maximum sensitivity level of data the user or role can access. Valid values: 0–9. |
table_name |
Yes | The name of the target table or view. Run SHOW TABLES; in the MaxCompute client to list table and view names. |
column_list |
No | One or more column names, when granting access to specific columns. Separate multiple column names with commas (,). |
name |
Yes | The name of the user or role. Run LIST users; or LIST roles; in the MaxCompute client to get this information. |
days |
No | The time-to-live (TTL) of the grant, in days. Valid values: 0–263−1. Default: 180 days. |
Usage notes
A column-level explicit grant overrides a table-level explicit grant for the same user.
Revoke explicit label grants
The project owner or a user with the Admin role runs this command to revoke explicit grants.
Command syntax
REVOKE Label ON TABLE <table_name> [(<column_list>)] FROM {USER|ROLE} <name>;
Parameters
| Parameter | Required | Description |
|---|---|---|
table_name |
Yes | The name of the target table or view. Run SHOW TABLES; in the MaxCompute client to list table and view names. |
column_list |
No | One or more column names, when revoking access to specific columns. Separate multiple column names with commas (,). |
name |
Yes | The name of the user or role. Run LIST users; or LIST roles; in the MaxCompute client to get this information. |
Usage notes
-
Revoking a table-level explicit grant also revokes all column-level explicit grants for the same user on that table.
-
Revoking explicit grants does not affect the user's access level label. For example, if a user has access level 2 and was explicitly granted access up to level 3, the user can still access data up to level 2 after the grant is revoked.
Clean up expired grants
After explicit label grants expire, the project owner or a user with the Admin role runs the following command to remove the expired permission records.
clear expired grants;
Examples
The following examples use a table named sale_detail in the project test_project. The table has three columns: shop_name, customer_id, and total_price.
Bob@aliyun.com is the project owner. Allen is a RAM user under Bob and has been added to test_project.
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 a table and its columns
-- Bob enters test_project.
USE test_project;
-- Set sale_detail to sensitivity level 1. All columns now have level 1.
SET Label 1 TO TABLE sale_detail;
-- Set 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 sale_detail to level 3. shop_name and customer_id retain level 2 (column overrides table). total_price changes 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 shop_name and customer_id to level 4. total_price remains 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 users
This example assigns access levels to two users:
-
A regular user:
Kate@aliyun.com -
A RAM user:
RAM$Bob@aliyun.com:Allen
-- Bob enters test_project.
USE test_project;
-- Assign Kate access level 3. Kate can access data with sensitivity levels 0–3.
SET Label 3 TO USER ALIYUN$Kate@aliyun.com;
-- Assign Allen access level 1. Allen can access data with sensitivity levels 0–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: Grant Allen explicit access to highly sensitive data
Allen's access level is 1, but he needs temporary access to data with higher sensitivity levels in sale_detail.
-- Enter test_project.
USE test_project;
-- Grant Allen access to sale_detail data up to level 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 |
+-------------+--------------+--------------------------+
-- Grant Allen access to shop_name, customer_id, and total_price up to level 4. The grant expires in 10 days.
-- This column-level grant overrides the previous table-level grant.
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 explicit access
-- Previously:
-- First, explicitly granted Allen access to sale_detail data up to level 3.
-- Then, explicitly granted Allen column-level access to shop_name, customer_id, and total_price up to level 4.
-- Revoke Allen's column-level access to shop_name, customer_id, and total_price.
REVOKE LABEL ON TABLE sale_detail(shop_name, customer_id, total_price) FROM USER RAM$Bob@aliyun.com:Allen;
-- View Allen's grants.
SHOW LABEL GRANTS ON TABLE sale_detail FOR USER RAM$Bob@aliyun.com:Allen;
-- Output:
-- Revoke Allen's table-level access to sale_detail.
REVOKE LABEL ON TABLE sale_detail FROM USER RAM$Bob@aliyun.com:Allen;
-- View Allen's 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 | |
+-------------+--------------+---------+