edit-icon download-icon


Last Updated: May 03, 2018

This document describes the syntax structure and rules of authentication policies in RAM. You can find information about policy structure, policy syntax, elements usage, and policy example in this document.


A policy consists of the policy version and a list of authorization statements.

Each statement contains the following elements: Effect (authorization type), Action (specified operations), Resource (specified objects), and Condition (specified restrictions). The Condition element is optional.

An example of the basic policy structure is shown in the following figure.

Basic Policy Structure


RAM only supports descriptions written in the JSON format. When creating or updating a policy, RAM will first check whether it is formatted correctly.

For information on JSON syntax standards, see RFC 7159. You can also use some online JSON format validators and editors to check the validity of the JSON text.


Know the characters allowed to be used in a policy and the related rules, and the syntax descriptions.

Character rules

Policies include the JSON characters: { } [ ] " , :; and the description syntax uses these special characters: = < > ( ) |.

For using the preceding characters, the rules include:

  • When an element permits multiple values, it can be expressed using commas and ellipses, for example: [<action_string>, <action_string>, ...]

  • All syntaxes that support multiple values, also allow single values. The following two expressions are equivalent: "Action": [<action_string>] and "Action": <action_string>

  • An element with a question mark indicates an optional element, for example: <condition_block?>

  • When multiple values are separated by a vertical bar (|), this indicates that only one of the values can be selected. For example: ("Allow" | "Deny")

  • An element enclosed with double quotes indicate a text string. For example: <version_block> = "Version" : ("1")

Syntax description

The syntax description is as follows:

  1. policy = {
  2. <version_block>,
  3. <statement_block>
  4. }
  5. <version_block> = "Version" : ("1")
  6. <statement_block> = "Statement" : [ <statement>, <statement>, ... ]
  7. <statement> = {
  8. <effect_block>,
  9. <action_block>,
  10. <resource_block>,
  11. <condition_block?>
  12. }
  13. <effect_block> = "Effect" : ("Allow" | "Deny")
  14. <action_block> = ("Action" | "NotAction") :
  15. ("*" | [<action_string>, <action_string>, ...])
  16. <resource_block> = ("Resource" | "NotResource") :
  17. ("*" | [<resource_string>, <resource_string>, ...])
  18. <condition_block> = "Condition" : <condition_map>
  19. <condition_map> = {
  20. <condition_type_string> : {
  21. <condition_key_string> : <condition_value_list>,
  22. <condition_key_string> : <condition_value_list>,
  23. ...
  24. },
  25. <condition_type_string> : {
  26. <condition_key_string> : <condition_value_list>,
  27. <condition_key_string> : <condition_value_list>,
  28. ...
  29. }, ...
  30. }
  31. <condition_value_list> = [<condition_value>, <condition_value>, ...]
  32. <condition_value> = ("String" | "Number" | "Boolean")

For the preceding description, note the following:

  • Version: The current policy version is 1.

  • Statements: A single policy can have multiple authorization statements.

    • Each authorization statement can be either Deny or Allow. In an authorization statement, Action is a list of multiple operations and Resource is a list of multiple objects.

    • Each authorization statement supports independent conditions. A condition block can specify multiple condition operation types and logical combinations of these conditions.

  • Deny takes priority: You can grant multiple policies to a single user. If these policies contain both Allow and Deny statements, the Deny statements have a higher priority.

  • Values:

    • When the value of an element is a numeric or Boolean value, the format is similar to character strings. In such cases, the value must be placed in double quotes.

    • When the value of an element is a character string, the wildcards (*) and (?) can be used for fuzzy matching. In a fuzzy match,

      • (*) can be replaced by zero or more English letters.
      • (?) can be replaced by any 1 English letter.

      For example, “ecs:happ*” matches the ECS API operation names “happiness” and “happy”, but “ecs:happ?” only matches “happy”.

Elements usage

Know how to use the elements in a policy.


Effect specifies the authorization type. The Effect value can be either Allow or Deny. For example,

  1. "Effect": "Allow"


Action specifies the operations to be authorized. Action supports multiple values, which are API operation names defined by cloud services. The format for Action values is as follows:

  1. <service-name>:<action-name>

Format description:

  • service-name: Refers to the name of an Alibaba Cloud product, such as ECS, RDS, Server Load Balancer, OSS, and Table Store.

  • action-name: Refers to the name of a service-related API.

Description example:

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


Resource generally specifies the operation objects, such as ECS virtual machine instances and OSS objects. Alibaba Cloud service resource names are formatted as follows:

  1. acs:<service-name>:<region>:<account-id>:<relative-id>

Format description:

  • acs: the abbreviation of Alibaba Cloud Service, indicating an Alibaba Cloud public cloud platform.

  • service-name: the name of an open service provided by Alibaba Cloud, such as ECS, OSS, or Table Store.

  • region: region information. If this option is not supported, use the wildcard “*” instead.

  • account-id: the account ID, such as 1234567890123456. You can also enter the wildcard “*”.

  • relative-id: the service-related resource. Its meaning is specified by the specific service. The format is similar to the tree-like structure of a file path. Using OSS as an example, relative-id = "mybucket/dir1/object1.jpg" indicates an OSS object.

Description example:

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


Condition specifies condition restrictions.

A condition block is composed of one or more condition clauses. A single condition clause consists of the condition operation type, condition keyword, and condition value.

Condition logic

The following figure shows the criteria for determining whether a condition is met:

Condition Determining Logic

  • When one or more values are specified for a single condition keyword, the condition clause is met when the value of the condition keyword is equal to one designated value.

  • A condition clause is met only when multiple condition keywords of the same operation type contained in the condition clause are met.

  • A condition block is met only when all condition clauses under the condition block are met.

Condition operation type

Condition operations are categorized as string, numeric, date, Boolean, and IP address.

The condition operation types support the following methods:

String Numeric Date and time Boolean IP address
StringEquals NumericEquals DateEquals Bool IpAddress
StringNotEquals NumericEquals DateNotEquals - NotIpAddress
StringEqualsIgnoreCase NumericLessThan DateLessThan - -
StringNotEqualsIgnoreCase NumericLessThanEquals DateLessThanEquals - -
StringLike NumericGreaterThan DateGreaterThan - -
StringNotLike NumericGreaterThanEquals DateGreaterThanEquals - -

Condition keyword

The condition keywords reserved by Alibaba Cloud service adopt the following naming format:

  1. acs:<condition-key>

Alibaba Cloud service reserves the following general condition keywords:

General condition keyword Type Description
acs:CurrentTime Date and time The time when the web server receives a request, in ISO 8601 format, for example, 2012-11-11T23:59:59Z.
acs:SecureTransport Boolean Whether a secure channel such as HTTPS is used for sending requests.
acs:SourceIp IP address The client IP address for sending requests.
acs:MFAPresent Boolean Whether MFA (two-step authentication) is adopted during user logon.

Product-level condition keywords can be defined for cloud products, in the following format:

  1. <service-name>:<condition-key>

The following table lists the condition keywords defined for some cloud products.

Product name Condition keyword Type Description
ECS ecs:tag/<tag-key> String ECS resource tag keyword, which can be customized by the user
RDS rds:ResourceTag/<tag-key> String RDS resource tag keyword, which can be customized by the user
OSS oss:Delimiter String Delimiter used to group object names by OSS
oss:Prefix String OSS object name prefix

Policy example

The following policy contains two authorization statements.

  • The first authorization statement grants permission to view all ECS resources in the East China 1 (Hangzhou) region (ecs:Describe*).

  • The second authorization statement grants read permission (oss:ListObjects, oss:GetObject) for objects in the OSS bucket mybucket, and restricts the source IP address of requesters to be “” or “”.

  1. {
  2. "Version": "1",
  3. "Statement": [
  4. {
  5. "Effect": "Allow",
  6. "Action": "ecs:Describe*",
  7. "Resource": "acs:ecs:cn-hangzhou:*:*"
  8. },
  9. {
  10. "Effect": "Allow",
  11. "Action": [
  12. "oss:ListObjects",
  13. "oss:GetObject"
  14. ],
  15. "Resource": [
  16. "acs:oss:*:*:mybucket",
  17. "acs:oss:*:*:mybucket/*"
  18. ],
  19. "Condition":{
  20. "IpAddress": {
  21. "acs:SourceIp": ["", ""]
  22. }
  23. }
  24. }
  25. ]
  26. }
Thank you! We've received your feedback.