MaxCompute's label-based access control (LabelSecurity) lets you enforce data sensitivity at the column level. Assign sensitivity-level labels (0–9) to tables or columns, and access-level labels (0–9) to users or roles. A user can only read data whose sensitivity level is at or below the user's access level.
Background
LabelSecurity is a mandatory access control (MAC) policy enforced at the project level. It is disabled by default for new projects.
To enable or disable LabelSecurity for a project, run the following statement as the project owner:
Set LabelSecurity=true|false;When LabelSecurity is enabled, two default policies apply:
| Policy | Behavior |
|---|---|
| No-ReadUp | Users cannot read tables or columns whose sensitivity level exceeds their access level. Explicit authorization via GRANT LABEL is required for exceptions. |
| Trusted-User | Users can write data with sensitivity level at or below their access level. Newly created tables, views, and users start at level 0 by default, so all users can access them. |
LabelSecurity provides the following capabilities for sensitive data:
A column is the minimum supported granularity for configuring sensitivity levels.
Sensitivity-level labels can be configured for views. The sensitivity-level labels of views are independent of the sensitivity-level labels of the source tables that correspond to the views.
Limitations
Sensitivity-level labels cannot be applied to partition key columns.
The No-WriteDown policy (which blocks writing data at a lower sensitivity level than the user's access level) is not enabled by default. To enable it, run
Set ObjectCreatorHasGrantPermission=false;.
Prerequisites
Before you begin, ensure that you have:
The project owner account or the Admin role in the target MaxCompute project
The account or role name of each user you want to label. Run
list users;orlist roles;on the MaxCompute client to look these up.The table or column names you want to label. Run
show tables;on the MaxCompute client to look these up.
If the user or role is not yet in the project, see User planning and management or Role planning.
Account name formats:
| Account type | Format |
|---|---|
| Alibaba Cloud account | ALIYUN$<account_id> |
| RAM user | RAM$<account_id>:<RAM user ID> |
| RAM role | RAM$<account_id>:role/<RAM role name> |
Set sensitivity-level labels for tables or columns
The project owner or a user with the Admin role assigns sensitivity levels to tables and columns.
Syntax
set Label <number> to table <table_name>[(<column_list>)];Parameters
| Parameter | Required | Description |
|---|---|---|
number | Yes | Sensitivity level. Valid values: 0–9. A higher value means higher sensitivity. |
table_name | Yes | Name of the table or view. Run show tables; on the MaxCompute client to get this. |
column_list | No | Comma-separated list of column names. Omit to apply the label to the whole table. |
How table and column labels interact
If you label a table without specifying columns, all columns inherit the table's sensitivity level.
A column label always takes effect regardless of the table label — column labels override the table label, not the other way around. For example, if
table_ais set to level 2 andcol1is set to level 3,col1remains at 3 after you reset the table label.To change a label, run the statement again with the new level.
Set access-level labels for users or roles
The project owner or a user with the Admin role assigns access levels to users or roles.
Syntax
set Label <number> to {USER|ROLE} <name>;Parameters
| Parameter | Required | Description |
|---|---|---|
number | Yes | The highest sensitivity level this user or role can access. Valid values: 0–9. For example, level 3 grants access to data at levels 0, 1, 2, and 3. |
name | Yes | Name of the user or role. Run list users; or list roles; on the MaxCompute client to get this. |
Column-level explicit authorization via GRANT LABEL takes precedence over a user's access level. For example, a user at level 0 who has been explicitly granted access to a level-3 column can still read that column.
Usage notes
To prevent data from moving across projects, enable project data protection by running
set ProjectProtection=true;. For details, see Project data protection.When an object is deleted, MaxCompute automatically revokes all labels associated with it.
When a user is removed from a project, their permissions are retained. If the same user is re-added, those permissions become active again. To clear residual permissions, see Completely clear the residual permission information of a removed user.
Examples
The following examples use project test_project_a, which contains a table sale_detail with columns shop_name, customer_id, and total_price. Bob@aliyun.com owns the project, and Allen (RAM$Bob@aliyun.com:Allen) is a RAM user added to the project.
Example 1: Set sensitivity-level labels for a table and its columns
-- Access the project as Bob@aliyun.com.
use test_project_a;
-- Set the table label to 1. All columns inherit level 1.
set Label 1 to table sale_detail;
-- Override shop_name and customer_id to level 2. total_price stays at 1.
set Label 2 to table sale_detail(shop_name, customer_id);
-- Reset the table label to 3. shop_name and customer_id stay at 2. total_price moves to 3.
set Label 3 to table sale_detail;
-- Override shop_name and customer_id to level 4. total_price stays at 3.
set Label 4 to table sale_detail(shop_name, customer_id);
-- Verify the labels.
describe sale_detail;Expected output:
+------------------------------------------------------------------------------------+
| Owner: ALIYUN$****@test.aliyun.com | Project: **** |
| TableComment: |
+------------------------------------------------------------------------------------+
| CreateTime: 2021-12-13 11:27:04 |
| LastDDLTime: 2021-12-13 11:27:04 |
| LastModifiedTime: 2021-12-13 11:27:26 |
+------------------------------------------------------------------------------------+
| TableLabel: 3 |
| MaxLabel: L4 |
+------------------------------------------------------------------------------------+
| InternalTable: YES | Size: 784 |
+------------------------------------------------------------------------------------+
| Native Columns: |
+------------------------------------------------------------------------------------+
| Field | Type | Label | Comment |
+------------------------------------------------------------------------------------+
| shop_name | string | 4 | |
| customer_id | string | 4 | |
| total_price | double | 3 | |
+------------------------------------------------------------------------------------+
| Partition Columns: |
+------------------------------------------------------------------------------------+
| sale_date | string | |
| region | string | |
+------------------------------------------------------------------------------------+Example 2: Set access-level labels for users
-- Access the project as Bob@aliyun.com.
use test_project_a;
-- Grant Kate access to data at levels 0–3.
set Label 3 to USER ALIYUN$Kate@aliyun.com;
-- Grant Allen access to data at levels 0–1.
set Label 1 to USER RAM$Bob@aliyun.com:Allen;
-- Verify Allen's label grants.
show label grants for RAM$Bob@aliyun.com:Allen;Expected output:
User Label: 1
(granted label list is empty)What's next
GRANT LABEL: Grant users or roles with a lower access level explicit access to high-sensitivity data.
REVOKE: Revoke an explicitly configured label from a user or role.
CLEAR EXPIRED GRANTS: Clear expired permissions granted through explicit authorization.