Object Storage Service:Control policy

Evaluation logic

When a RAM user or RAM role in a member account accesses a cloud service like Object Storage Service (OSS), the system first evaluates the request against the Control Policy. If compliant, the system then evaluates the account's RAM policies to determine authorization.

Evaluation principles

The principle of explicit deny takes precedence applies at every evaluation level:

1. Explicit deny takes precedence: If a Deny rule matches the request, the request is immediately denied. The entire Control Policy evaluation process ends, and the system does not proceed to evaluate in-account RAM policies.

2. Explicit allow: If no matching Deny rule is found at a given level, the system looks for a matching Allow rule. If an Allow rule exists, the evaluation passes for that level and continues to the parent node. This process repeats up to the root folder. If the request passes at all levels up to and including the root, the overall Control Policy evaluation is successful, and the system proceeds to evaluate in-account RAM policies.

3. Implicit deny: If no matching Deny or Allow rule is found, the request is implicitly denied. The evaluation does not proceed to the next level, and the entire Control Policy evaluation process ends. The system does not proceed to evaluate in-account RAM policies.

Alibaba Cloud evaluates the Control Policies attached to the target account and to every level of the hierarchy above it. This ensures that policies attached at higher levels are enforced on all accounts below them. For more information, see Control Policy overview.

Policy types

• System control policy: A built-in Control Policy that you can view but not modify. After you enable the Control Policy feature, the FullAliyunAccess policy is attached by default to allow all operations.

• Custom control policy: A user-defined Control Policy that you can create, modify, delete, and attach to folders or members.

Scope

Control Policies apply to all RAM users and RAM roles within the member accounts of a Resource Directory. They do not affect service-linked roles, the root user of a member account, or any identity within the management account.

Step 1: Enable control policy

You only need to do this once. If you have already enabled this feature, skip this step.

1. Navigate to the Enable Control Policy page in the Resource Directory console.

2. Click Enable Control Policy and confirm your choice.

3. Click Refresh to check the status.

Step 2: Create a custom control policy

1. Navigate to the Create Control Policy page in the Resource Directory console.

2. Choose a configuration method.

   This example shows how to enforce the block public access setting. For more examples, see Common authorization scenarios.

   Important

   Before you apply a deny policy, ensure that existing resources in the member accounts already comply with the policy. For example, if you want to enforce block public access for OSS, confirm that all existing buckets have the block public access feature enabled.

   Visual editor

   In the Visual Editor tab, configure the following settings:

   • Effects: Select Deny

   • Service: Select Object Storage

   • Actions: Select oss:DeleteBucketPublicAccessBlock and oss:PutBucketPublicAccessBlock

   Script editor

   In the Script Editor tab, enter the following policy configuration:

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

   Note

   A Control Policy uses JSON and includes two core elements: Version and Statement. A Statement consists of Effect, Action, Resource, and Condition elements. For details about how to configure Action elements, see Action.

3. Click OK.

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

Step 3: Attach the control policy

1. Navigate to the Directory Management page in the Resource Directory console.

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

3. On the Policies tab, click Attach Policy.

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

Step 4: Verify the policy

Once attached, the policy applies to all member accounts within the folder. For the scenario where block public access is enforced, you can verify the policy's effect in the following ways:

1. Verify denied actions: In a member account, try to disable the block public access feature for an existing bucket. The operation should be denied by the Control Policy.

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

3. Verify hierarchical enforcement: Perform the same actions in member accounts at different levels within the folder to confirm that the policy is enforced throughout the hierarchy.

Scenario 1: Enforce block public access

You can enforce block public access for OSS buckets by using a Control Policy that denies actions that disable this feature or create buckets without it. The following is an example configuration:

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