All Products
Search

This Product

    MaxCompute:Policy-based access control

    Document Center

    MaxCompute:Policy-based access control

    Last Updated:Nov 15, 2025

    MaxCompute provides a policy-based access control method for complex and flexible permission settings. This method is ideal for large enterprises and complex scenarios that require fine-grained control. Unlike access control list (ACL) authorization, policy-based access control also supports a blacklist. This feature lets you create policies that grant or deny a role permission to perform specific operations on specific objects. After you attach the role to a user, the permissions of the role take effect. This topic describes the policy authorization commands that MaxCompute supports and provides authorization examples.

    Background information

    Policy-based access control supports whitelist and blacklist authorization. You can grant (whitelist) or deny (blacklist) a role permission to perform specific operations on specific objects.

    This access control method resolves authorization issues that cannot be resolved by using ACL-based access control. For example, a user is assigned the developer role and has the permissions to drop tables by default. If you want to deny the role from dropping tables, you can use this access control method.

    After a MaxCompute project is created, policy-based access control is enabled by default. The project owner can run the set CheckPermissionUsingPolicy=true|false; command in the MaxCompute project to enable or disable this feature.

    Policy-based access control applies to the following scenarios.

    Scenario

    Description

    Authorizer

    Authorization endpoint

    Grant permissions to users based on roles

    Grant a role the permission to allow or deny one or more operations on a specific object. Then, attach the role to multiple users. The users inherit the permissions of the role.

    See the Authorizer column in MaxCompute permissions.

    Use a custom role for fine-grained authorization for a user with a built-in role

    If a user is already assigned a built-in role and you need more fine-grained control over their permissions, ACL authorization is not sufficient. In this case, use policy-based access control to create a new role. You can then grant or deny the role permission to perform operations on project objects and attach the role to the user for fine-grained permission management.

    Scope

    Before you use the policy-based access control feature, take note of its prerequisites, limits, and precautions.

    • Prerequisites:

      • Policy-based access control supports authorization only for existing roles. Confirm the name of the role to be authorized and ensure that the role has been added to the MaxCompute project. You can run the list roles; command on the MaxCompute client to retrieve role information. To create a new role, see Role planning.

      • The type of the object on which you want to grant permissions, the name of the object, and the actions that you want to allow on the object are obtained.

        For more information about object types and actions supported for each type of object, see MaxCompute permissions.

    • Precautions:

      • If both whitelist and blacklist authorizations are configured, the blacklist takes precedence.

      • Policy-based access control lets you grant permissions on objects that do not exist. When you delete an object, the associated policy authorization information is not deleted. The authorizer must be aware of the security risks that can arise from deleting and then recreating an object with the same name.

      • After a user is removed, the permissions that are granted to the user are retained. If the user is added to the project again, the historical access permissions of the user are activated again. For more information about how to clear the residual permission information of a removed user, see Completely clear the residual permission information of a removed user.

    Command format

    The policy-based access control commands are formatted as follows:

    • Policy authorization

      GRANT <actions> ON <object_type> <object_name> 
TO ROLE <role_name> 
PRIVILEGEPROPERTIES("policy" = "true", "allow"="{true|false}"[, "conditions"= "<conditions>"]);

    • Revoke policy authorization

      REVOKE <actions> ON <object_type> <object_name> 
FROM ROLE <role_name> 
PRIVILEGEPROPERTIES("policy" = "true", "allow"="{true|false}");

    The following table describes the parameters.

    Parameter

    Required

    Description

    actions

    Yes

    The action to be granted. You can specify multiple actions in a single command.

    If you specify multiple actions, separate them with commas (,). For more information about the valid values, see MaxCompute permissions.

    object_type

    Yes

    The type of the object to be granted. You can specify only one object type in a single command.

    For more information about the valid values, see MaxCompute permissions.

    object_name

    Yes

    The name of the object to be granted. You can obtain the name in one of the following ways:

    • Project name: You can log on to the MaxCompute console, switch the region in the upper-left corner, and then obtain the MaxCompute project name from the Project Management tab.

    • Table or view: To obtain the name of a table or view, run the show tables; command on the MaxCompute client.

    • Model name: You can use the MaxCompute client to execute the show models; command to obtain the model name.

    • Resource name: You can obtain the resource name by executing the list resources; command on the MaxCompute client.

    • Function name: You can run the list functions; command on the MaxCompute client to obtain the function name.

    • Instance Name: You can obtain the instance ID by executing the show instances; command on the MaxCompute client.

    You can use asterisks (*) when you configure this parameter. For example, if you set this parameter to table taobao*, all tables whose names start with taobao are matched.

    Note

    You can use asterisks (*) only when the value of subject_type is ROLE.

    role_name

    Yes

    The name of the role to be authorized. You can specify only one role in a single command.

    You can run the list roles; command on the MaxCompute client to obtain the role name.

    privilegeproperties

    policy

    Yes

    Set the value to true. This indicates that the policy-based access control method is used.

    allow

    Required for whitelist authorization

    Specifies the authorization mechanism. Valid values:

    • true: Allows the specified operation on the specified object.

    • false: Denies the specified operation on the specified object. This is the blacklist mechanism.

    conditions

    No

    Controls permissions based on dimensions such as the source of the request message and the access method. For more information about the valid values, see Conditions.

    Policy-based access control examples

    Assume that Bob@aliyun.com is the owner of the test_project_a project, and Allen and Tom are Resource Access Management (RAM) users under the account Bob@aliyun.com. Allen has been assigned the Admin role of the test_project_a project. The following examples show how to perform authorization operations on the MaxCompute client:

    • Example 1: Grant permissions to a user based on a role (blacklist)

      Deny Tom from deleting tables that start with tb_.

      • The following example shows how to implement policy authorization using commands:

        -- Bob enters the test_project_a project.
USE test_project_a;
-- Create the Worker role.
CREATE ROLE Worker;
-- Add the user Tom as a project member.
ADD USER RAM$Bob@aliyun.com:Tom;
-- Attach the Worker role to the user Tom.
GRANT Worker TO RAM$Bob@aliyun.com:Tom;
-- Deny the Worker role from deleting tables that start with tb_ in the test_project_a project.
GRANT Drop ON TABLE tb_* TO ROLE Worker PRIVILEGEPROPERTIES("policy" = "true", "allow"="false");
-- View the authorization result for the user Tom.
SHOW GRANTS FOR RAM$Bob@aliyun.com:Tom;
-- The following authorization result is returned. D indicates Deny. Deleting tables that start with tb_ is denied.
Authorization Type: Policy
[role/worker]
D      projects/test_project_a/tables/tb_*: Drop

      • The following example shows how to implement policy authorization in the console:

        1. Log on to the MaxCompute console and select a region in the upper-left corner.

        2. In the navigation pane on the left, choose Management Configuration > Project Management.

        3. On the Projects page, locate the target project and click Manage in the Actions column.

        4. On the Role Permissions tab, click Create Project-level Role.

        5. In the Create Role dialog box, create a Resource role, enter a Role Name, and define the authorization policy.

          The following is a sample policy:

          {
    "Statement":[
        {
            "Action":[
                "odps:Drop"
            ],
            "Effect":"Deny",
            "Resource":[
                "acs:odps:*:projects/test_project_a/tables/tb_*"
            ]
        }
    ],
    "Version":"1"
}

        6. On the Role Permissions tab, click Manage Members in the Actions column for the new role and add RAM$Bob@aliyun.com:Tom to the role.

    • Example 2: Revoke policy authorization (blacklist)

      Based on Example 1, revoke the authorization from the user Tom.

      -- Bob enters the test_project_a project.
USE test_project_a; 
-- Revoke the Worker role from the user Tom.
REVOKE Worker FROM RAM$Bob@aliyun.com:Tom;
-- View the authorization result for the user Tom. The permission list does not contain the Drop permission information.
SHOW GRANTS FOR RAM$Bob@aliyun.com:Tom;

    • Example 3: Grant permissions to a user based on a role (whitelist)

      Allow Tom to update data in tables that start with tb_.

      • The following example shows how to implement policy authorization using commands:

        -- Bob enters the test_project_a project.
USE test_project_a; 
-- Create the Worker role.
CREATE ROLE Worker; 
-- Add the user Tom as a project member.
ADD USER RAM$Bob@aliyun.com:Tom;
-- Attach the Worker role to the user Tom.
GRANT Worker TO RAM$Bob@aliyun.com:Tom; 
-- Allow the Worker role to update data in tables that start with tb_ in the test_project_a project.
GRANT Update ON TABLE tb_* TO ROLE Worker PRIVILEGEPROPERTIES("policy" = "true", "allow"="true");
-- View the authorization result for the user Tom.
SHOW GRANTS FOR RAM$Bob@aliyun.com:Tom; 
-- The following authorization result is returned. A indicates Allow. You can update data in tables that start with tb_.
Authorization Type: Policy
[role/worker]
A       projects/test_project_a/tables/tb_*: Update

      • The following example shows how to implement policy authorization in the console:

        1. Log on to the MaxCompute console and select a region in the upper-left corner.

        2. In the navigation pane on the left, choose Management Configuration > Project Management.

        3. On the Projects page, locate the target project and click Manage in the Actions column.

        4. On the Role Permissions tab, click Create Project-level Role.

        5. In the Create Role dialog box, create a Resource role, enter a Role Name, and define the authorization policy.

          The following is a sample policy:

          {
    "Statement":[
        {
            "Action":[
                "odps:Update"
            ],
            "Effect":"Allow",
            "Resource":[
                "acs:odps:*:projects/test_project_a/tables/tb_*"
            ]
        }
    ],
    "Version":"1"
}

        6. On the Role Permissions tab, click Manage Members in the Actions column for the new role and add RAM$Bob@aliyun.com:Tom to the role.

    • Example 4: Revoke policy authorization (whitelist)

      Based on Example 3, revoke the authorization from the user Tom.

      -- Bob enters the test_project_a project.
USE test_project_a; 
-- Revoke the Worker role from the user Tom.
REVOKE Worker FROM RAM$Bob@aliyun.com:Tom;
-- View the authorization result for the user Tom. The permission list does not contain the Update permission information.
SHOW GRANTS FOR RAM$Bob@aliyun.com:Tom;

    • Example 5: Perform fine-grained authorization for a user with a built-in role

      Deny Allen from deleting all tables in the test_project_a project.

      • The following example shows how to implement policy authorization using commands:

        -- Bob enters the test_project_a project.
USE test_project_a;
-- Create the Worker role.
CREATE ROLE Worker;
-- Attach the Worker role to the user Allen.
GRANT Worker TO RAM$Bob@aliyun.com:Allen;
-- Deny the Worker role from deleting all tables in the test_project_a project.
GRANT Drop ON TABLE * TO ROLE Worker PRIVILEGEPROPERTIES("policy" = "true", "allow"="false");
-- View the authorization result for the user Allen.
SHOW GRANTS FOR RAM$Bob@aliyun.com:Allen;
-- The following authorization result is returned. Deleting all tables is denied.
[roles]
role_project_admin, worker
Authorization Type: Policy
[role/role_project_admin]
A       projects/test_project_a: *
A       projects/test_project_a/instances/*: *
A       projects/test_project_a/jobs/*: *
A       projects/test_project_a/offlinemodels/*: *
A       projects/test_project_a/packages/*: *
A       projects/test_project_a/registration/functions/*: *
A       projects/test_project_a/resources/*: *
A       projects/test_project_a/tables/*: *
A       projects/test_project_a/volumes/*: *
[role/worker]
A       projects/test_project_a/tables/tb_*: Update
D       projects/test_project_a/tables/*: Drop
-- A in AG indicates Allow. G in AG indicates With Grant Option, which lets you grant permissions on the object.
Authorization Type: ObjectCreator
AG      projects/test_project_a/tables/local_test: All
AG      projects/test_project_a/tables/mr_multiinout_out1: All
AG      projects/test_project_a/tables/mr_multiinout_out2: All
AG      projects/test_project_a/tables/ramtest: All
AG      projects/test_project_a/tables/wc_in: All
AG      projects/test_project_a/tables/wc_in1: All
AG      projects/test_project_a/tables/wc_in2: All
AG      projects/test_project_a/tables/wc_out: All

      • The following example shows how to implement policy authorization in the console:

        1. Log on to the MaxCompute console and select a region in the upper-left corner.

        2. In the navigation pane on the left, choose Management Configuration > Project Management.

        3. On the Projects page, locate the target project and click Manage in the Actions column.

        4. On the Role Permissions tab, click Create Project-level Role.

        5. In the Create Role dialog box, create a Resource role, and specify the Role Name and the authorization policy.

          The following is a sample policy:

          {
    "Statement":[
        {
            "Action":[
                "odps:Drop"
            ],
            "Effect":"Deny",
            "Resource":[
                "acs:odps:*:projects/test_project_a/tables/*"
            ]
        }
    ],
    "Version":"1"
}

        6. On the Role Permissions tab, click Manage Members in the Actions column for the new role, and add RAM$Bob@aliyun.com:Allen to the role.

    • Example 6: Revoke authorization for a user with a built-in role

      Based on Example 5, revoke the authorization from the user Allen. The following is a sample command.

      -- Bob enters the test_project_a project.
USE test_project_a;
-- Revoke the Worker role from the user Allen.
REVOKE Worker FROM RAM$Bob@aliyun.com:Allen;
-- View the authorization result for the user Allen. The permission list does not contain the Drop permission information.
SHOW GRANTS FOR RAM$Bob@aliyun.com:Allen;

    • Example 7: Grant a user (Tom) the permission to query all tables based on a role (whitelist)

      • The following example shows how to implement policy authorization using commands:

        -- Bob enters the test_project_a project.
USE test_project_a;
-- Create the Worker role.
CREATE ROLE Worker;
-- Add the user Tom as a project member.
ADD USER RAM$Bob@aliyun.com:Tom;
-- Attach the Worker role to the user Tom.
GRANT Worker TO RAM$Bob@aliyun.com:Tom;
-- Allow the Worker role to query all tables in the test_project_a project.
GRANT Describe,Select ON TABLE * TO ROLE Worker PRIVILEGEPROPERTIES("policy" = "true", "allow"="true");
-- View the authorization result for the user Tom.
SHOW GRANTS FOR RAM$Bob@aliyun.com:Tom;
-- The following authorization result is returned. A indicates Allow. You can query all tables in the test_project_a project.
Authorization Type: Policy
[role/worker]
A      projects/test_project_a/tables/*: Describe | Select

      • The following example shows how to implement policy authorization in the console:

        1. Log on to the MaxCompute console and select a region in the upper-left corner.

        2. In the navigation pane on the left, choose Management Configuration > Project Management.

        3. On the Projects page, locate the target project and click Manage in the Actions column.

        4. On the Role Permissions tab, click Create Project-level Role.

        5. In the Create Role dialog box, set Role Type to Resource, specify the Role Name, and set Authorization Method to Policy.

          The following is a sample policy:

          {
    "Statement":[
        {
            "Action":[
                "odps:Describe",
                "odps:Select"
            ],
            "Effect":"Allow",
            "Resource":[
                "acs:odps:*:projects/test_project_a/tables/*"
            ]
        }
    ],
    "Version":"1"
}

        6. On the Role Permissions tab, click Manage Members in the Actions column for the new role and add RAM$Bob@aliyun.com:Tom to the role.

    What to do next

    After you understand the policy authorization mechanism, you can perform the following authorization operations as needed:

    For more information about the policy authorization mechanism, see the following topics: