Access Policy Language Overview

Overview

Access policies use the JSON-based access policy language and are used to grant access to COS resources. You can use the access policy language to authorize a specified principal to execute specified operations on specified COS resources.

Access Policy Elements

The access policy language contains the following elements with basic meanings:

• Principal: Describes the entity to be authorized by the policy. This includes entities such as users (root accounts, sub-accounts, anonymous users) and user groups. This element is valid for bucket access policies but cannot be added for user access policies.
• Statement: Describes the detailed information of one or more permissions. This element includes a permission or a permission set of multiple elements such as effect, action, and resource. A policy can and has only one statement element.
  • Effect: Describes whether the result of the statement is an "allow" or an explicit "deny". This includes allow and deny. This element is required.
  • Action: Describes the allowed or denied action. An action can be an API (described with the prefix "name") or a feature set (a set of specific APIs described with the prefix "permid"). This element is required.
  • Resource: Describes the detailed data authorized. A resource is described in a six-segment format. Detailed resource definitions vary by product. For more information on how to specify a resource, see the product documentation corresponding to the resources you are writing a statement for. This element is required.

Element Usage

Specifying a Principal

The principal element is used to specify the user, account, service, or another entity that is allowed or denied to access resources. This element only works in buckets; it doesn't need to be specified in user policies because such policies are directly added to the specific user. A sample specifying a principal is shown below.

"principal": {
  "qcs": [
    "qcs::cam::uin/1:uin/1"
  ]
}

Granting permissions to anonymous users:

"principal": {
  "qcs": [
    "qcs::cam::anonymous:anonymous"
  ]
}

Granting permissions to the root account with UIN 1200000313:

"principal": {
  "qcs": [
    "qcs::cam::uin/1200000313:uin/1200000313"
  ]
}

Grant permissions to a sub-account UIN 3030313 (under the root account UIN 1200000313):

Note:

Before the action, ensure that the sub-account has been added to the sub-account list of the root account.

"principal": {
  "qcs": [
    "qcs::cam::uin/1200000313:uin/3030313"
  ]
}

Specifying an Effect

If you don't explicitly grant access to (allow) a resource, access is implicitly denied. You can also explicitly deny access to (deny) a resource. In this way, you can ensure that users cannot access the resource, even if a different policy grants access. A sample specifying an allowed effect is shown below.

"effect" : "allow"

Specifying an Action

COS defines a specific COS action that you can specify in a policy. The specified action is identical to the initiated API request operation.

Bucket Operations

Object Operations

A sample specifying an action that is allowed is shown below:

"action": [
  "name/cos:GetObject",
  "name/cos:HeadObject"
]

Specifying a Resource

The resource element describes one or multiple operation objects, such as COS buckets and objects. All resources can be described in the following six-segment format.

qcs:project_id:service_type:region:account:resource

Where:

• qcs is the abbreviation of qcloud service.
• project_id describes project information, only for compatibility with early CAM logic. Please leave this blank here.
• service_type describes the abbreviation of the product, such as COS.
• region describes the region information.
• account describes the root account information of the resource owner.
• resource describes the detailed resource information. In COS services, it is described using the bucket XML API access endpoints.

A sample specifying the bucket burningtest-1251500699 is shown below.

"resource": ["qcs::cos:ap-city:uid/1251500699:burningtest-1251500699/*"]

A sample specifying all objects in the /test/ folder in the bucket burningtest-1251500699 is shown below.

"resource": ["qcs::cos:ap-city:uid/1251500699:burningtest-1251500699/test/*"]

A sample specifying the /test/1.txt object in the bucket burningtest-1251500699 is shown below.

"resource": ["qcs::cos:ap-city:uid/1251500699:burningtest-1251500699/test/1.txt"]

Practical Case

When the access source IP addresses are 101.226.100.185 and 101.226.100.186, if the root account allows anonymous users to execute the GET (download) and HEAD actions on objects in the bucket burningtest-1251500699 in city region, no authentication is required.

{
   "version": "2.0",
   "principal": {
      "qcs": [
         "qcs::cam::anonymous:anonymous"
      ]
   },
    "statement": [
        {
            "action": [
                "name/cos:GetObject",
                "name/cos:HeadObject"
            ],
            "effect": "allow",
            "resource": [
                "qcs::cos:city:uid/1251500699:burningtest-1251500699/*"
            ]
        }
    ]
}