Overview

Scenarios

When an enterprise organizes all departments under a resource directory, it needs a way to enforce organization-wide rules—such as prohibiting domain registration or log deletion—without relying on each department to self-police. Control Policy lets the management account define access control policies centrally and attach them to folders or members in the resource directory, ensuring security compliance and cost control across the organization.

Types of access control policies

• System access control policy

  Resource Directory provides one built-in system access control policy: FullAliyunAccess. This policy allows all operations on all cloud resources and is automatically attached to every folder and member when you enable Control Policy. You can view it but cannot create, modify, or delete it.

• Custom access control policy

  Custom access control policies are created and managed by you. After creating a policy, attach it to the folders or members where it should apply. Detach it when it is no longer needed.

How it works

1. Enable Control Policy using the management account of your resource directory. For more information, see Enable the Control Policy feature.

   After enabling Control Policy, the system attaches FullAliyunAccess to all folders and members by default. This prevents access failures while you set up custom policies.

2. Create a custom access control policy using the management account. For more information, see Create a custom control policy.

3. Attach the policy to folders or members. For more information, see Attach a custom access control policy.

   Policies attached to a folder automatically apply to all its subfolders and members. For example, if Policy A is attached to a folder and Policy B is attached to one of its subfolders, both policies apply to all members in that subfolder.

   Note

   Start by attaching a custom access control policy to a small set of folders or members to verify it works as expected before rolling it out more broadly.

4. When a RAM user or RAM role in a member account makes an access request, the system evaluates the request against all attached access control policies, traversing the resource directory hierarchy from the member upward:

   • Evaluation starts at the member that owns the target resource and moves up level by level through parent folders.

   • If a Deny statement matches, evaluation stops immediately and the request is denied—without checking the RAM user's or role's permissions.

   • If no Deny or Allow statement matches at any level, the request is denied.

   • If no Deny matches but an Allow matches, evaluation continues up to the Root folder. Once the Root folder passes, the system proceeds to verify the RAM user's or role's permissions. For more information, see Policy evaluation process.

   • Access control policies do not apply to service-linked roles. For more information about service-linked roles, see Service-linked roles.

   • Policies attached to a folder apply to all members in that folder and in any of its subfolders.

   Important

   Control policies apply to all RAM principals (users and roles) within a member account but do not apply to the owner of that account or any principals in the management account of the Resource Directory.

Allow specific Alibaba Cloud services to bypass a custom access control policy

Custom access control policies restrict resource access for the members they are attached to. Because Alibaba Cloud services often use service roles to access account resources on your behalf, a custom policy that denies the required permissions can break those service features. To exclude a service role from a policy, update the policy to include a condition that exempts the role.

1. Find the name of the service role used by the service you want to exempt.

   Log on to the RAM console to view all service roles in your account.

2. Add the "acs:PrincipalARN" key to the Condition parameter in the policy document, then set its value to the service role name. The following example denies ram:UpdateUser for all principals except the specified service role:

   {
       "Statement": [
           {
               "Action": [
                   "ram:UpdateUser"
               ],
               "Resource": "*",
               "Effect": "Deny",         
               "Condition": {
                   "StringNotLike": {
                       "acs:PrincipalARN":"acs:ram:*:*:role/<Name of the service role>"
                  }
              }
           }
       ],
       "Version": "1"
   }

   For more information about the syntax of access control policies, see Languages of access control policies.

Limits

For more information, see Limits on resource directories.

Alibaba Cloud services that do not support the Control Policy feature

• Microservices Engine (MSE) of a specific engine version supports the Control Policy feature.

  For more information about MSE engine versions, see Edition features.

• The following applications and clusters in ApsaraMQ for RocketMQ do not support the Control Policy feature:

  • The mq-http application does not support the Control Policy feature.

  • The onsbroker application does not support the Control Policy feature in the following regions:

    • UAE (Dubai).

    • China (Shanghai): The sh-share9 and shvip-st21ujm8f01 clusters in this region do not support the Control Policy feature.

    • China North 2 Ali Gov 1: The beijing.gov.vip.v0h0ovmfp02, beijing.gov.vip.nif1zmrlf02, and vip-cn-north-2-gov-1-45914plw301 clusters in this region do not support the Control Policy feature.