Control Policy

Authentication mechanism

A Control Policy defines permission boundaries but does not grant permissions. When a RAM user or role in a member account accesses a cloud service, the system first checks compliance against the Control Policy. If the request passes, the system then evaluates the account's RAM permission policies.

Evaluation principles

Evaluation starts at the account that owns the requested resource and proceeds up the Resource Directory hierarchy. At each level, explicit deny takes precedence:

1. Explicit deny takes precedence: If a Deny rule matches the request, the request is immediately denied. Evaluation ends without checking the account's RAM permission policy.

2. Search for an explicit allow: If no Deny rule matches at a level, the system looks for a matching Allow rule. If a matching Allow rule is found, evaluation passes at that level and continues up to the root folder. If the root folder also passes, the Control Policy check succeeds and the system evaluates the account's RAM permission policy.

3. Default deny: If neither a Deny nor Allow rule matches, the request is denied by default. Evaluation ends without proceeding to the next level or evaluating the account's RAM permission policy.

Alibaba Cloud evaluates policies attached to the accessed account and every ancestor in its hierarchy, ensuring that higher-level policies apply to all accounts beneath them. Overview of Control Policies.

Policy types

• System Control Policy: A built-in, read-only policy. When you enable Control Policy, the FullAliyunAccess policy is attached by default, allowing all operations.

• Custom Control Policy: A policy you create and manage. Attach it to a folder or member.

Scope

A Control Policy applies to all RAM users and roles in member accounts within a Resource Directory. It does not apply to Service-Linked Roles, a member's root user, or identities within the management account.

Step 1: Enable the Control Policy feature

You only need to enable this feature once. Skip this step if it is already enabled.

1. Go to the Resource Directory - Enable Control Policy page.

2. Click Enable Control Policy and confirm your choice.

3. Click Refresh to check the status.

Step 2: Create a custom Control Policy

1. Go to the Resource Directory - Create Control Policy page.

2. Choose a configuration method.

   The following example creates a policy that enforces block public access. For more configuration examples, see Common authorization scenarios.

   Important

   Before configuring a deny policy, ensure all existing resources in member accounts already comply. For block public access, confirm that block public access is enabled for all existing buckets.

   Visual editor

   In the Visual editor section, configure the following settings:

   • Effects: Select Deny.

   • Service: Select OSS.

   • Actions: Select oss:DeleteBucketPublicAccessBlock and oss:PutBucketPublicAccessBlock.

   Policy editor

   In the Policy editor section, enter the following policy configuration:

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Deny",
         "Action": [
           "oss:DeleteBucketPublicAccessBlock",
           "oss:PutBucketPublicAccessBlock"
         ],
         "Resource": "*"
       }
     ]
   }

   Note

   A Control Policy is in JSON format with two core fields: Version and Statement. A Statement contains Effect, Action, Resource, and Condition elements. For details about how to configure an Action, see Action.

3. Click OK.

4. In the Create Control Policy dialog box, enter a name and description, then click OK.

Step 3: Attach the Control Policy to a folder

1. Go to the Resource Directory - Directory Management page.

2. In the resource directory tree, click the target folder.

3. On the Policy tab, click Attach Policy.

4. In the Attach Policy panel, select the Control Policy that you want to attach, and then click OK.

Step 4: Verify the policy

After the policy is attached, all member accounts in the folder are subject to its constraints. Verify the block public access policy with the following checks:

1. Verify the deny action: In a member account, try to disable block public access for an existing bucket. The Control Policy should deny the operation.

2. Verify creation restrictions: Try to create a new bucket without enabling block public access. The system should deny the creation request.

3. Verify hierarchical enforcement: Perform the same operations in member accounts at different levels of the hierarchy to confirm that the policy is effective throughout the entire folder.

Scenario 1: Enforce block public access for OSS buckets

This policy enforces block public access for OSS buckets by preventing users from disabling the feature or creating buckets without it:

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteBucketPublicAccessBlock",
        "oss:PutBucketPublicAccessBlock"
      ],
      "Resource": "*"
    }
  ]
}