All Products
Search
Document Center

Resource Access Management:Policy elements

Last Updated:Mar 19, 2026

This topic provides a reference for the elements that constitute a Resource Access Management (RAM) policy. Understanding these elements is essential for creating effective permissions.

A RAM policy is a JSON document that consists of one or more statements. Each statement describes a single permission and is built from the following elements.

Element

Description

Effect

Specifies whether the statement allows or denies access. Valid values are Allow and Deny.

Action / NotAction

Defines the specific API operations that are allowed or denied. You can specify either Action or its inverse, NotAction.

Principal

Specifies the user, account, service, or other entity that is allowed or denied access. This element is used in resource-based policies (such as an OSS bucket policy), but not in identity-based policies.

Resource

Specifies the resources that the statement applies to, identified by their Alibaba Cloud Resource Name (ARN).

Condition

Defines the conditions under which the policy is in effect. This element is optional.

Effect

The Effect element is required and specifies whether the statement results in an Allow or a Deny.

Note

An explicit Deny in any applicable policy always overrides an Allow.

Example:

"Effect": "Allow"

Action and NotAction

The Action or NotAction element is required and specifies the API operations governed by the statement. The value is a string or an array of strings in the format ram-code:action-name (such as ecs:DescribeInstances). For more information about each service's RAM code, see Services that work with RAM.

Action lists the operations that the policy allows or denies. NotAction matches every operation except for those listed. Using NotAction can result in granting broad permissions, so it should be used with caution.

You can use wildcards (*) to specify multiple actions. For example, ecs:Describe* matches all ECS operations that start with "Describe".

Example:

"Action": [
  "oss:ListBuckets",
  "ecs:Describe*",
  "rds:Describe*"
]

Example: Allows all actions except for those in RAM.

{
	"Effect": "Allow",
	"NotAction": "ram:*",
	"Resource": "*"
}

Resource

The Resource element is required and specifies the object or objects that the policy statement affects. Resources are identified by their Alibaba Cloud Resource Name (ARN).

The ARN format is acs:<ram-code>:<region>:<account-id>:<relative-id>.

  • acs: Stands for Alibaba Cloud Service.

  • product: The service's RAM code (such as ecs, oss, and ram). For more information, see Services that work with RAM.

  • region: The region where the resource is located. Use an asterisk (*) for global resources. For more information, see Regions and zones.

  • account-id: The ID of the Alibaba Cloud account that owns the resource.

  • relative-id: The path-like identifier for the specific resource within the service (such as instance/i-12345 or mybucket/dir1/object1.jpg).

Example:

"Resource": [
  "acs:ecs:*:*:instance/inst-001",
  "acs:ecs:*:*:instance/inst-002",
  "acs:oss:*:*:mybucket",
  "acs:oss:*:*:mybucket/*"
]

Condition

The optional Condition element lets you specify conditions for when a policy is in effect. A condition block contains one or more conditions, and each condition consists of an operator, a key, and a value.

Condition evaluation logic

  • A condition block is met only if all conditions within it evaluate to true (logical AND).

  • If a single condition key has multiple values, the condition is met if the request value matches any of the specified values (logical OR).

  • To achieve a logical OR between different conditions, place them in separate statements.

Condition operators

Operators are used to compare the key in the policy with the value in the request context. Common operators include StringEquals, StringLike, IpAddress, and DateGreaterThan. For a complete list, see Conditional operators.

Condition keys

Condition keys can be global or service-specific. Global condition keys start with the acs: prefix.

Global condition keys

Key

Description

acs:CurrentTime

The time the request is received. The value must be in ISO 8601 format and UTC (such as 2023-01-10T20:00:00+08:00 and 2023-01-10T12:00:00Z).

acs:SecureTransport

A boolean indicating whether the request was sent over a secure channel (HTTPS).

acs:SourceIp

The IP address or CIDR block from which the request originates.

acs:MFAPresent

A boolean indicating whether the user authenticated with multi-factor authentication (MFA).

Note

This condition key has no effect when a RAM user's MFA setting is configured to "Required Only for Unusual Logon."

acs:PrincipalARN

The ARN of the principal making the request. Useful in role trust policies and the Resource Directory's control policies.

Note

Specify the ARN of the desired RAM role in lowercase. To find the ARN, navigate to the role's details page in the RAM console.

acs:PrincipalRDId

The ID of the resource directory to which the requester's account belongs. Useful in role trust policies and OSS bucket policies.

acs:PrincipalRDPath

The path of the requester's account within the resource directory structure. Useful in role trust policies and OSS bucket policies.

acs:RequestTag/<tag-key>

The value of a tag that is passed in the request. Replace <tag-key> with your tag key. For supported services, see Services that work with Tag.

acs:ResourceTag/<tag-key>

The value of a specific tag attached to the resource being accessed. For supported services, see Services that work with Tag.

Service-specific condition keys

Services can define their own specific condition keys, which follow the format <ram-code>:<condition-key>. For example, OSS uses oss:Delimiter in some operations. For a list of keys supported by a service, see the documentation for that service.

Examples

Example 1: The logical relationship between different conditions in the same condition block is AND. This policy requires the user to both be authenticated with MFA and have a specific source IP (203.0.113.2).

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ecs:*",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "acs:SourceIp": [
            "203.0.113.2"
          ]
        },
        "Bool": {
          "acs:MFAPresent": [
            "true"
          ]
        }
      }
    }
  ]
}

Example 2: To create an OR relationship, use separate statements. This policy allows access if the user is authenticated with MFA or if the request is from the specified IP (203.0.113.2).

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ecs:*",
            "Resource": "*",
            "Condition": {
                "IpAddress": {
                    "acs:SourceIp": [
                        "203.0.113.2"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "ecs:*",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "acs:MFAPresent": [
                        "true"
                    ]
                }
            }
        }
    ]
}

Principal

The Principal element is used in resource-based policies (such as an OSS bucket policy and a RAM role trust policy) to specify the entity (the principal) that is allowed or denied access to a resource or to assume a role.

Note

You do not specify this element in identity-based policies. For identity-based policies, the principal is implicitly the RAM user, user group, or role to which the policy is attached.

You can specify the following types of principals:

  • Alibaba Cloud account: Specifies all principals within an account using the root ARN.

    Format: acs:ram::<account-id>:root

  • RAM user: Specifies a specific RAM user by its ARN. Wildcards are not supported in the user name.

    Format: acs:ram::<account-id>:user/<user-name>

    Important

    When you save a trust policy, RAM may convert the user ARN to a stable, internal ID. This ID becomes visible if the original RAM user is deleted, preventing the policy from breaking. This ensures that even if a user is deleted and a new user is created with the same name, the new user does not automatically inherit the permissions.

  • RAM role: Specifies a specific RAM role by its ARN. Wildcards are not supported in the role name.

    Format: acs:ram::<account-id>:role/<role-name>

    Important

    When you save a trust policy, RAM may convert the role ARN to a stable, internal ID. This ID becomes visible if the original RAM role is deleted, preventing the policy from breaking. This ensures that even if a role is deleted and a new role is created with the same name, the new role does not automatically inherit the permissions.

  • Alibaba Cloud service: Specifies a service principal that can assume a role on your behalf.

    Format: <service-name>.aliyuncs.com

  • Identity provider (IdP): Specifies a federated principal from a SAML or OIDC provider by its ARN.

    SAML format: acs:ram::<account-id>:saml-provider/<provider-name>

    OIDC format: acs:ram::<account-id>:oidc-provider/<provider-name>

Example of a trust policy allowing two RAM accounts and a service to assume a role:

"Principal": {
  "RAM": [
    "acs:ram::123456789012****:root",
    "acs:ram::987654321098****:root"
  ],
  "Service": "ecs.aliyuncs.com"
}