Syntax Structure

Last Updated At: 2025-11-17 15:23:54

The syntax structure of the entire policy is shown in the figure below. A policy consists of a version and statements, and may also include principal information. The principal information is only used for policy syntax-related parameters in policy management APIs.
A statement consists of several substatements. Each substatement includes four elements: action, resource, condition (optional), and effect.

JSON Format

The policy syntax is based on the JSON format. If the created or updated policy fails to meet the JSON format, it will not be submitted successfully, so users need to ensure that the JSON format is correct. The JSON format standard is defined in RFC7159, and you can also check the policy format using an online JSON verification program.

Syntax Conventions

The syntax description has the following conventions:

  • The following characters are JSON characters included in the policy syntax.

    { } [ ] " , :
    
  • The following characters are special characters used to describe the policy syntax and are not included in a policy.

    = < > ( ) |
    
  • When multiple values are allowed for an element, comma delimiters and ellipsis are used. Example:

    [<resource_string>, < resource_string>, ...]  
    <principal_map> = { <principal_map_entry>, > <principal_map_entry>, ... }
    

When the policy syntax allows multiple values, it can contain just one value. In this case, the trailing comma needs to be omitted, and the square brackets "[]" are optional. Example:

"resource": [<resource_string>]     
"resource": <resource_string>
  • The question mark "?" after the element indicates that the element is optional. Example:

    <condition_block?>
    
  • If the element includes enum values, they are separated by a vertical bar "|", and the range of values is defined within parentheses "()". Example:

    ("allow" | "deny")
    
  • String elements are enclosed in double quotes. Example:

    <version_block> = "version" : "2.0"
    

Syntax Description

policy={
    <version_block><principal_block?>,
    <statement_block>
}<version_block>="version": "2.0"<statement_block>="statement": [
    <statement>,
    <statement>,
    ...
]<statement>={
    <effect_block>,
    <action_block>,
    <resource_block>,
    <condition_block?>
}<effect_block>="effect": ("allow"|"deny")<principal_block>="principal": ("*"|<principal_map>)<principal_map>={
    <principal_map_entry>,
    <principal_map_entry>,
    ...
}<principal_map_entry>="qcs": [
    <principal_id_string>,
    <principal_id_string>,
    ...
]<action_block>="action": ("*"|[
    <action_string>,
    <action_string>,
    ...
])<resource_block>="resource": ("*"|[
    <resource_string>,
    <resource_string>,
    ...
])<condition_block>="condition": {
    <condition_map>
}<condition_map>{
    <condition_type_string>: {
        <condition_key_string>: <condition_value_list>
    },
    <condition_type_string>: {
        <condition_key_string>: <condition_value_list>
    },
    ...
}<condition_value_list>=[
    <condition_value>,
    <condition_value>,
    ...
]<condition_value>=("string"|"number")

Syntax description:

  • A policy can contain multiple statements.
    The maximum length of a policy is 4,096 characters (excluding spaces). For details, see Restrictions.
    The display order of blocks is not restricted. For example, in a policy, a version_block can follow an effect_block.
  • The currently supported syntax version is 2.0.
  • Writing the principal_block element in the console is not allowed. Principal is supported only in policy management APIs and policy syntax-related parameters.
  • Both the action and resource support lists, with action also supporting permid (a set of product-defined actions).
  • A condition can include a single condition or a logical combination of multiple sub-condition blocks. Each effective condition consists of the condition operator (condition_type), condition key (condition_key), and condition value (condition_value).
  • The effect of each policy statement is either deny or allow. When a policy statement contains both allow and deny, the deny-override principle is applied.

String Description

The element string of syntax description is described as follows:

action_string

It consists of description scope, service type, and action name.

//All actions of all products
"action":"*"
"action":"*:*"
// All actions of COS products
"action":"cos:*"
// Action named GetBucketPolicy of COS products
"action":"cos:GetBucketPolicy"
// Action for matching some buckets of COS products
"action":"cos:*Bucket*"
//List of actions with action set ID 280649
"action":"permid/280649"
// Action list named GetBucketPolicy\PutBucketPolicy\DeleteBucketPolicy of COS products
"action":["cos:GetBucketPolicy","cos:PutBucketPolicy","cos: DeleteBucketPolicy"]

Where, permid is the action set ID defined for each product. For details, see the relevant product documentation.

resource_string

Resource is described in a six-segment format.

qcs: project :serviceType:region:account:resource

Examples are as follows:

// For object resources of a COS product, located in Luzon, with resource owner UID 10001234, resource name bucket1/object2, and resource prefix prefix, its resource description is as follows.
qcs::cos:sh:uid/10001234:prefix//10001234/bucket1/object2
// For a queue of CMQ products, located in Luzon, with resource owner UIN 12345678, resource name 12345678/queueName1, and resource prefix queueName, its resource description is as follows.
qcs::cmqqueue:sh:uin/12345678:queueName/12345678/queueName1
// For CVM of a CVM product, located in Luzon, with resource owner UIN 12345678, resource name ins-abcdefg, and resource prefix instance, its resource description is as follows.
qcs::cvm:sh:uin/12345678:instance/ins-abcdefg

For details, see the resource description method on the Supported Resource-level Permissions page of each product.

condition_type_string

Condition operators, describing the type of test conditions. Examples include string_equal, string_not_equal, date_equal, date_not_equal, ip_equal, ip_not_equal, numeric_equal, and numeric_not_equal. Here is an example:

"condition":{
         "string_equal":{"cvm:region":["CAX01","ACX01"]},
         "ip_equal":{"qcs:ip":"10.131.12.12/24"}
}

condition_key_string

Condition key, representing the application of condition operators on its value to determine if the condition is met. CAM defines a set of condition keys that can be used in all products, including qcs:current_time, qcs:ip, qcs:uin, and qcs:owner_uin. For details, see Conditions.

principal_id_string

For CAM, the user is also its resource. Hence, the principal is also described in the six-segment format. The following is an example. For details, see Resource Description Methods.

"principal":   {"qcs":["qcs::cam::uin/1238423:uin/3232",
             "qcs::cam::uin/1238423:groupid/13"]}