Access strategy evaluation process

Last updated: 2020-03-19 21:47:03

    Access COS Bucket and Bucket resources need to be authorized before Access. In Tencent Cloud's Permission system, the main account to which the resources belong owns all the management Permission of the resources in Bucket and Bucket by default. CAM users (other main accounts, collaborators, sub-accounts) and other types of users, such as anonymous users, need to be authorized by the main account to carry out Access.

    The Access policy in the account includes different policy types, such as user group policy, user policy, Bucket Access control list (ACL) and Bucket policy (Policy). In the evaluation of Access's strategy, there are the following key factors:

    1. User Identity verification: when a user Access has resources on COS, there are two situations.
      • If you carry the request signature, COS will parse the user's account information from the request signature, and then request repost to Identity verification Access's management CAM.
      • If you do not carry a signature request, it will be considered as an anonymous user to enter the next link of Verification.
    2. The category of Access strategy: Access strategy includes many types of strategies, such as user group, user, Bucket and so on. The category of Access strategy determines the order of Access strategy.
    3. Policy context information: when processing a request for user resource Access, it will make a joint judgment based on the details of Permission recorded in user group policy, user policy, Bucket policy and other policies, and finally decide whether to pass the request or not.

    Access strategy evaluation process

    When Tencent Cloud COS receives a request, it will first confirm the identity of the requester and verify whether the requester has the relevant Permission. The verification process includes checking the user policy, Bucket Access policy and resource-based Access control list to authenticate the request.

    When Tencent Cloud COS receives the request, Identity verification will be used first. According to the result of Identity verification, the identity of the requestor will be classified. Different identity categories may have different performance:

    1. Verified Tencent Cloud main account: the main account has all the operations on the resources to which it belongs, Permission. As for the resources that do not belong to it, it is necessary to evaluate the resources Permission, and if the authentication is passed, the resources of Access will be licensed.
    2. Authenticated CAM users (sub-accounts or collaborators): evaluate user policy-CAM users must have the authorization of their parent primary account before they are allowed to initiate the relevant Access. If the CAM user needs the resources to which Access's other main account belongs, you need to evaluate the resource Permission of the main account to which the CAM user belongs. If the authentication is passed, Access resources will be granted.
    3. Anonymous users without identity: evaluation resource Permission-Permission who evaluates the Bucket Access strategy or Bucket or the object's Access control list. If the authentication is passed, the Access resource is granted.
    4. Requesters other than the above categories of users: reject their Access.

    Access's strategy evaluation basis

    In the Tencent Cloud Permission system, in the Access strategy evaluation process, Permission is evaluated according to the policy context information, and there are the following basic principles:

    1. By default, all requests are implicitly rejected by Access Permission, who is entitled to all the resources under the (deny); main account by default.
    2. This default value is overridden if Explicit allows it in the user group policy, user policy, Bucket policy, or Bucket / object Access control list.
    3. Explicit's refusal in any strategy will override any permission.
    4. The effective Permission scope is the combination of identity-based policies (user group policy, user policy) and resource-based policies (Bucket policy or Bucket / object Access control list).
    • Explicit refuses: there is a clear Deny policy for specific users in user policy, user group policy and Bucket Policy. If the main account explicitly configures Deny sub-user UIN 1000000011 in the user policy GET Object Operation, the sub-user cannot download the object resources under the main account.
    • Explicit allows: pass in user policy, user group policy, Bucket Policy, Bucket ACL grant-\* Explicitly specify that a specific user has a clear Allow policy for a specific user.
    • Reject everyone: clearly specified in Bucket Policy Deny anyone After everyone is rejected, any request without signature will be rejected, and the request with signature will be authenticated with identity-based policy.
    • Allow everyone: explicitly specified in Bucket Policy Allow anyone Or explicitly specified in Bucket ACL public-\* .
    • Effective Permission's scope is the combination of identity-based policy and resource-based policy: in a complete authentication, COS will first resolve the user's identity and verify that he has the resources of Permission and Access according to the user's identity; at the same time, according to the resource-based policy, the user will be treated as an anonymous user for Permission verification. Access will be allowed if one of the two verifications is successful.

    Access's policy evaluation is based on the following figure. First, whether the user is an anonymous user is evaluated based on whether the signature is carried in the request. If the user is an anonymous user, it will evaluate whether there is a policy of rejecting or allowing everyone in the policy, and then decide whether to allow Access or reject Access. If the user is Valid's CAM user or the main account with resources, it will evaluate whether there is a policy in which Explicit rejects or Explicit allows or allows everyone, and then decides whether to allow Access or reject Access.

    Policy context information

    Policy context information refers to the details of Permission recorded in the policy. Minimum Permission principle Under, the user needs to explicitly specify the following information in the policy:

    • The principal (principal): must specify which sub-users you need to grant (Enter user ID), collaborator (Enter user ID), anonymous user or user group Permission. If you use a temporary key for Access, you do not need to specify this item.
    • The statement (statement): specifies Enter's corresponding parameters in the following parameters.
    • Effective (effect): must clearly state whether the policy is "allowed" or "rejected by Explicit", including both allow and deny.
    • The action (action): must explicitly declare the actions that are allowed or denied by the policy. The operation can be API (described with the name prefix) or a feature set (a specific set of API, described with the permid prefix).
    • The resource (resource): must explicitly declare the specific resources authorized by the policy. Resources are described in six paragraphs. You can specify the scope of the resource to the specified file, such as exampleobject.jpg, or the specified Directory, such as examplePrefix/ *. Unless the business needs, please do not arbitrarily grant the user Access all the resources of Permission, that is, wildcards *.
    • Conditional (condition): describes the constraints under which the policy takes effect. Conditions include operators, action keys, and operation values. Condition values can include information such as time, IP address, and so on.

    To write a policy, you need to write it according to a certain policy syntax, see Access Policy Language Overview Write according to the needs of the business. For examples of user policy and Bucket policy, please see User policy syntax structure and Examples of Bucket Policies .

    Access's example of Strategy Evaluation

    Suppose the main account UIN 100000000001 is the sub-account UIN 100000000011. Associate has a user default policy that allows the sub-account to read only the resources under the main account. The details of this user policy are as follows. This user policy allows the sub-account to execute all ListGetHead Operation and OptionsObject Operation.

    {
        "version": "2.0",
        "statement": [
            {
                "action": [
                    "cos:List*",
                    "cos:Get*",
                    "cos:Head*",
                    "cos:OptionsObject"
                ],
                "resource": "*",
                "effect": "allow"
            }
        ]
    }

    At the same time, the main account is read and written by a privately owned Bucket. examplebucket-1250000000 The following Bucket strategy has been added:

    {
      "Statement": [
        {
          "Principal": {
            "qcs": [
              "qcs::cam::anyone:anyone"
            ]
          },
          "Effect": "Deny",
          "Action": [
            "name/cos:GetObject"
          ],
          "Resource": [
            "qcs::cos:ap-guangzhou:uid/100000000011:examplebucket-1250000000/*"
          ]
        }
      ],
      "version": "2.0"
    }

    This Bucket strategy Explicit refused all users to execute the download object ( GetObject ). Therefore, in the Access strategy evaluation process:

    1. If the sub-account carries a signature parameter request GetObject The corresponding user policy will be matched according to the user identity represented by the request, and Access policy evaluation and verification will pass.
    2. If the sub-account does not carry a signature parameter request GetObject Will be judged as an anonymous request by the system and will be strategically implemented by Bucket Reject Access.

    Was this page helpful?

    Was this page helpful?

    • Not at all
    • Not very helpful
    • Somewhat helpful
    • Very helpful
    • Extremely helpful
    Send Feedback
    Help