Policy-based access control
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
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.
该授权方式可以弥补ACL授权机制无法解决的授权问题。例如用户已经被赋予了开发角色,默认具备删除表的权限,但如果需要禁止用户执行删除表操作,可以通过Policy方式进行授权。
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. |
Usage notes
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 角色规划.-
授权对象类型、对象名称及操作。
更多对象类型及操作信息,请参见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.
-
当一个用户被移除后,与该用户有关的授权仍然会被保留。一旦该用户以后被再次添加到该项目时,该用户的历史授权访问权限将被重新激活。如果需要彻底清除用户的权限信息,请参见彻底清除被删除用户遗留的权限信息。
Syntax
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:
授权对象支持以通配符星号(*)来表达。例如, Note
授权给ROLE支持使用通配符星号(*);授权给USER不支持使用通配符。 |
|
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 | |
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:
| |
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:
Log on to the MaxCompute console and select a region in the upper-left corner.
-
In the left-side navigation pane, choose .
-
On the Projects page, locate the target project and click Manage in the Actions column.
-
On the Role Permissions tab, click Create Project-level Role.
-
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" } -
On the Role Permissions tab, find the new role, click Manage Members in the Actions column, and add
RAM$Bob@aliyun.com:Tomto 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:
Log on to the MaxCompute console and select a region in the upper-left corner.
-
In the left-side navigation pane, choose .
-
On the Projects page, locate the target project and click Manage in the Actions column.
-
On the Role Permissions tab, click Create Project-level Role.
-
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" } -
On the Role Permissions tab, find the new role, click Manage Members in the Actions column, and add
RAM$Bob@aliyun.com:Tomto 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:
Log on to the MaxCompute console and select a region in the upper-left corner.
-
In the left-side navigation pane, choose .
-
On the Projects page, locate the target project and click Manage in the Actions column.
-
On the Role Permissions tab, click Create Project-level Role.
-
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/*" ] } ], "Version":"1" } -
On the Role Permissions tab, find the new role, click Manage Members in the Actions column, and add
RAM$Bob@aliyun.com:Allento 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:
Log on to the MaxCompute console and select a region in the upper-left corner.
-
In the left-side navigation pane, choose .
-
On the Projects page, locate the target project and click Manage in the Actions column.
-
On the Role Permissions tab, click Create Project-level Role.
-
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:Describe", "odps:Select" ], "Effect":"Allow", "Resource":[ "acs:odps:*:projects/test_project_a/tables/*" ] } ], "Version":"1" } -
On the Role Permissions tab, find the new role, click Manage Members in the Actions column, and add
RAM$Bob@aliyun.com:Tomto 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:
For authorization practices of policy-based access control, see Policy-based access control practices.
To perform more fine-grained management of operation permissions for users with built-in roles, see Manage permissions for users with built-in roles based on policies.
For frequently asked questions about permission management in MaxCompute, see 权限管理常见问题.