RAM policy evaluation allow deny permissions - Resource Access Management

When a RAM principal (user or role) requests access to an Alibaba Cloud resource, RAM evaluates all applicable policies to allow or deny the request.

Core principles

Policy evaluation follows two principles:

Deny by default: RAM principals have no permissions by default. Unless a policy explicitly allows a request, it is implicitly denied.
Explicit deny overrides allow: If any policy contains an explicit Deny statement, the request is denied regardless of any Allow statements in other policies.

Evaluation flow

RAM evaluates policies in a fixed order. If any step denies the request, evaluation stops. The request is allowed only if it passes all applicable policy checks.

Policy evaluation flow

The evaluation includes the following steps:

Step 1: Evaluate Resource Directory control policies (if applicable)

If the account is a member of a resource directory, RAM evaluates the applicable control policies. Control policies serve as permission guardrails for the account.

If the control policy does not allow the requested action, the request is denied and the evaluation stops.
If allowed, evaluation proceeds to the next step.
If no control policies exist, this step is skipped.

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.

Step 2: Evaluate RAM role session policies (if applicable)

If the principal is a RAM role assumed with a session policy (such as via the AssumeRole operation), RAM evaluates that policy.

If the session policy does not allow the requested action, the request is denied and the evaluation stops.
If allowed, evaluation proceeds.

Note

This step is skipped for RAM user requests and federated SSO, as session policies do not apply.

Step 3: Evaluate identity-based and resource-based policies

RAM evaluates identity-based policies (attached to the requesting RAM user or role) and resource-based policies (attached to the target resource).

Identity-based policy: RAM evaluates all policies attached to the requesting principal. If any policy explicitly denies the request, the result is an explicit deny. If at least one policy allows the request, the result is an allow. Otherwise, the result is an implicit deny.

Note
During IdP-initiated SSO, the user has not yet assumed an identity, so no identity-based policy is evaluated. Only the RAM role's trust policy is checked.
Resource-based policy: If the target resource has a resource-based policy (such as an OSS bucket policy or a RAM role trust policy), RAM evaluates it with the same logic: the result is an allow, an explicit deny, or an implicit deny. If no resource-based policy exists, this check is skipped.

Step 4: Determine the final outcome

RAM combines results from all preceding steps to reach a final decision.

If an explicit deny was produced at any step, the final decision is DENY.
If no explicit deny exists and at least one allow was produced (from an identity-based or resource-based policy), the final decision is ALLOW.
In all other cases (if no policies explicitly allow the request), the final decision is an implicit deny.

Note

Special evaluation cases

Assuming a RAM role: Assuming a RAM role is a special case that requires an Allow from both the principal's identity-based policy and the role's trust policy. For more information, see How RAM evaluates policies when a role is assumed.
Object Storage Service (OSS): For OSS requests, ACLs on buckets or objects are evaluated after RAM policies. An ACL may deny a request even if a RAM policy allows it. OSS authorization.