MaxCompute provides the policy-based access control method. You can attach a policy to a role to allow or deny one or more specified actions on an object. Then, you can assign the role to a user. This way, the user is granted the permissions of the role. This topic describes the syntaxes of commands that you can use to perform policy-based access control. This topic also provides examples on how to perform policy-based access control.

Background information

The policy-based access control method supports the whitelist and blacklist authorization mechanisms to allow or deny one or more specified actions on an object. The whitelist mechanism is configured by using the allow parameter. The blacklist mechanism is configured by using the deny parameter.

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 for the project by default. The owner of a MaxCompute project can run the set CheckPermissionUsingPolicy=true; or set CheckPermissionUsingPolicy=false; command to enable or disable policy-based access control for the project.

The following table describes the use scenarios of the policy-based access control method.

Scenario Description Authorized by Entry point for policy-based access control
Use a role to grant permissions to a user You can grant permissions on an object to a role to allow or deny one or more specified actions on an object. Then, you can assign the role to a user. This way, the user is granted the permissions of the role. For more information about the identities that can be used to perform policy-based access control, see the Authorized by column in the Permission list section in Permission list.
Use a custom role to perform finer-grained permission management on a user that is assigned a built-in role Access control lists (ACLs) cannot be used to perform finer-grained permission management on a user that is assigned a built-in role. If you want to perform such management, you can use the policy-based access control method. You can create a role, and use the method to grant permissions on objects in a MaxCompute project to the role to allow or deny actions on the objects. Then, you can assign the role to a user.

Prerequisites

Before you use the policy-based access control method, make sure that the following conditions are met:
  • The name of the role to which you want to grant permissions is obtained, and the role is added to your MaxCompute project.

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

    For more information about how to create a role, see Role planning and management.

  • 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 Permissions.

Limits

You can use the policy-based access control method to grant permissions only to existing roles.

Precautions

Before you use the policy-based access control method, take note of the following items:
  • If both the whitelist and blacklist mechanisms are used, the blacklist mechanism takes precedence.
  • You can use the policy-based access control method to grant a role the permissions on an object that does not exist. If you delete an existing object whose permissions are granted to a role, the permission information related to the object is retained. As a result, if you create an object that has the same name as the deleted object, security risks may exist.
  • 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.

Syntaxes of commands

The following code provides the syntaxes of the commands that you can use to perform policy-based access control:
  • Grant permissions
    grant <actions> on <object_type> <object_name> 
to ROLE <role_name> 
privilegeproperties("policy" = "true", "{allow|deny}"="{true|false}"[, "conditions"= "<conditions>" ,"expires"="<days>"]);
  • Revoke permissions
    revoke <actions> on <object_type> <object_name> 
from ROLE <role_name> 
privilegeproperties ("policy" = "true", "{allow|deny}"="{true|false}");
The following table describes the parameters used in the preceding syntaxes.
Parameter Required Description
actions Yes The action that is allowed or denied. You can specify multiple actions in a single command.

If you specify multiple actions, separate them with commas (,). For more information about the supported actions, see Permissions.

object_type Yes The type of object whose permissions are granted. You can specify only one type of object in a single command.

For more information about the supported object types, see Permissions.

object_name Yes The name of the object whose permissions are granted. The following types of objects are supported:
  • Project: To obtain the name of a project, log on to the MaxCompute console. In the top navigation bar, select the region where the project resides. On the Project management tab, view the name of the project.
  • Table or view: To obtain the name of a table or view, run the show tables; command on the MaxCompute client.
  • Resource: To obtain the name of a resource, run the list resources; command on the MaxCompute client.
  • Function: To obtain the name of a function, run the list functions; command on the MaxCompute client.
  • Instance: To obtain the name of an instance, run the show instances; command on the MaxCompute client. Instance names are the same as instance IDs in MaxCompute.

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.

role_name Yes The name of the role to which permissions are granted. You can specify only one role in a single command.

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

privilegeproperties policy Yes Set the value to true. The value true indicates that policy-based access control is used.
allow Required if you want to use the whitelist mechanism Specifies whether to allow the specified action on the specified object. Valid values:
  • true: The specified action on the specified object is allowed.
  • false: The specified action on the specified object is not allowed.
deny Required if you want to use the blacklist mechanism Specifies whether to deny the specified action on the specified object. Valid values:
  • true: The specified action on the specified object is denied.
  • false: The specified action on the specified object is not denied.
conditions No The conditions used for policy-based access control. For more information about the configurations of this parameter, see Configure the conditions parameter.
days No The duration in which permissions are valid. Unit: days. If you do not configure this parameter, permissions are permanently valid. If you configure this parameter, MaxCompute clears information about the permissions after the duration specified by this parameter elapses.

Examples

For example, the Alibaba Cloud account Bob@aliyun.com is the owner of the project test_project_a. Allen and Tom are the RAM users of Bob@aliyun.com. The RAM user Allen is assigned the Admin role of the project test_project_a. In the following examples, commands are run on the MaxCompute client.
  • Example 1: Use a role to grant permissions to a user based on the blacklist mechanism
    In this example, the Drop permission is granted to the RAM user Tom to allow Tom to drop tables whose names start with tb_ from the project test_project_a. Sample commands: 
    -- Use the Alibaba Cloud account Bob@aliyun.com to access the project test_project_a. 
use test_project_a; 
-- Create a role named Worker in the project. 
create role Worker; 
-- Add the RAM user Tom to the project as a member. 
add user RAM$Bob@aliyun.com:Allen;
-- Assign the role Worker to the RAM user Tom. 
grant Worker TO RAM$Bob@aliyun.com:Allen; 
-- Allow the role Worker to drop tables whose names start with tb_ from the project. 
grant Drop on table tb_* to ROLE Worker privilegeproperties("policy" = "true", "deny"="false");
-- Query the authorization result. 
show grants for RAM$Bob@aliyun.com:Tom; 
-- The following authorization result is returned: The result A indicates Allow. The RAM user Tom is allowed to drop tables whose names start with tb_ from the project. 
Authorization Type: Policy
[role/worker]
A       projects/test_project_a/tables/tb_*: Drop
  • Example 2: Revoke the permissions that are granted by using the policy-based access control method based on the blacklist mechanism from a user
    In this example, the Drop permission that is granted to the RAM user Tom in Example 1 is revoked. 
    -- Use the Alibaba Cloud account Bob@aliyun.com to access the project test_project_a. 
use test_project_a; 
-- Revoke the role Worker from the RAM user Tom. 
revoke Worker from RAM$Bob@aliyun.com:Tom;
-- Query the permissions of the RAM user Tom. The RAM user Tom does not have the Drop permission. 
show grants for RAM$Bob@aliyun.com:Top;
  • Example 3: Use a role to grant permissions to a user based on the whitelist mechanism
    In this example, the Update permission is granted to the RAM user Tom to allow Tom to update tables whose names start with tb_ in the project test_project_a. Sample commands: 
    -- Use the Alibaba Cloud account Bob@aliyun.com to access the project test_project_a. 
use test_project_a; 
-- Create a role named Worker. 
create role Worker; 
-- Add the RAM user Tom to the project as a member. 
add user RAM$Bob@aliyun.com:Tom;
-- Assign the role Worker to the RAM user Tom. 
grant Worker TO RAM$Bob@aliyun.com:Tom; 
-- Allow the role Worker to update tables whose names start with tb_ in the project. 
grant Update on table tb_* to ROLE Worker privilegeproperties("policy" = "true", "allow"="true");
-- Query the authorization result. 
show grants for RAM$Bob@aliyun.com:Tom; 
-- The following authorization result is returned: The result A indicates Allow. The RAM user Tom is allowed to update the tables whose names start with tb_ in the project. 
Authorization Type: Policy
[role/worker]
A       projects/test_project_a/tables/tb_*: Update
  • Example 4: Revoke the permissions that are granted by using the policy-based access control method based on the whitelist mechanism from a user
    In this example, the Update permission that is granted to the RAM user Tom in Example 3 is revoked. 
    -- Use the Alibaba Cloud account Bob@aliyun.com to access the project test_project_a. 
use test_project_a; 
-- Revoke the role Worker from the RAM user Tom. 
revoke Worker from RAM$Bob@aliyun.com:Tom;
-- View the permissions of the RAM user Tom. The RAM user Tom does not have the Update permission. 
show grants for RAM$Bob@aliyun.com:Tom;
  • Example 5: Grant finer-grained permissions to a user that is assigned a built-in role
    In this example, the RAM user Allen is denied from dropping any table from the project test_project_a. Sample commands: 
    -- Use the Alibaba Cloud account Bob@aliyun.com to access the project test_project_a. 
use test_project_a; 
-- Create a role named Worker. 
create role Worker; 
-- Assign the role Worker to the RAM user Allen. 
grant Worker TO RAM$Bob@aliyun.com:Allen; 
-- Deny the role Worker from dropping any table from the project. 
grant Drop on table * to ROLE Worker privilegeproperties("policy" = "true", "allow"="false");
-- Query the authorization result. 
show grants for RAM$Bob@aliyun.com:Allen; 
-- The following authorization result is returned: The RAM user Allen is denied from dropping any table from the project. 
[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

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
  • Example 6: Revoke permissions from a user that is assigned a built-in role
    In this example, the Drop permission that is granted to the RAM user Allen in Example 5 is revoked. Sample commands: 
    -- Use the Alibaba Cloud account Bob@aliyun.com to access the project test_project_a. 
use test_project_a; 
-- Revoke the role Worker from the RAM user Allen. 
revoke Worker from RAM$Bob@aliyun.com:Allen;
-- View the permissions of the RAM user Allen. The RAM user Allen does not have the Drop permission. 
show grants for RAM$Bob@aliyun.com:Allen;

What to do next

After you have a command of how the policy-based access control method works, you can perform the following operations based on your business requirements: