tencent cloud

PrevNext

Feedback

search by keyword

Recent Pages

Documentation
Cloud Access Management
    Documentation
    Download PDF

    Scenarios where 'deny' in permission policy is ineffective

    Last updated: 2024-01-23 17:54:33
    Download PDF
      When a permission policy contains both "allow" and "deny" authorization statements, it is necessary to determine whether "deny" is effective based on the specific scenario.
      This document describes the logic behind the ineffectiveness of 'deny' through three typical scenarios: operations involving the query of resource lists, COS permissions denying all users (anonymous users), and billing-related operations.

      Operations for Querying Resource Lists

      Tencent Cloud's various service operations (actions) can be simply divided into four categories: addition, deletion, modification, and query. The query category can be further divided into querying individual resource details and querying a list of certain resources. In the following scenarios, 'deny' may not be effective. It is recommended to avoid using 'deny' for these operations, as well as condition keys such as 'string_not_equal' and 'string_like'.

      Scenarios where 'deny' is ineffective:

      Scenario 1: If a sub-user is granted permission (allow) to access CVM instances a, b, and c, but denied (deny) to access to instance d, and is also granted access to resources tagged with T, where instance d is tagged with T, the policy of "deny access to instance d" will not be effective.
      For instance, when the following policy is authorized, the user can still view instance d while viewing the CVM instance list.
      {
         "version": "2.0",
         "statement": [
             {
                 "effect": "allow",
                 "action": [
                     "*"
                 ],
                 "resource": "*",
                 "condition": {
                     "for_any_value:string_equal": {
                         "qcs:resource_tag": [
                             "key&T"  // Tag T
                         ]
                     }
                 }
             },
             {
                 "effect": "allow",
                 "action": [
                     "*"
                 ],
                 "resource": [
                     "qcs::cvm:ap-guangzhou::instanceid/a",  // Instance a
                     "qcs::cvm:ap-guangzhou::instanceid/b",  // Instance b
                     "qcs::cvm:ap-guangzhou::instanceid/c"   // Instance c
                 ]
             },
             {
                 "effect": "deny",
                 "action": [
                     "*"
                 ],
                 "resource": [
                     "qcs::cvm:ap-guangzhou::instanceid/d"   // Instance d
                 ]
             }
         ]
      }
      Scenario 2: If a policy allows a sub-user to access resources tagged with T1 and denies the access to resources tagged with T2, and resource a is tagged with both T1 and T2, then the denial of access to resource a will not be effective.
      For instance, even when the following policy is authorized, resource a can still be viewed when viewing the resource list.
      {
         "version": "2.0",
         "statement": [
             {
                 "effect": "allow",
                 "action": [
                     "*"
                 ],
                 "resource": "*",
                 "condition": {
                     "for_any_value:string_equal": {
                         "qcs:resource_tag": [
                             "key&T1"  // Tag T1
                         ]
                     }
                 }
             },
             {
                 "effect": "deny",
                 "action": [
                     "*"
                 ],
                 "resource": "*",
                 "condition": {
                     "for_any_value:string_equal": {
                         "qcs:resource_tag": [
                             "key&T2"  // Tag T2
                         ]
                     }
                 }
             }
         ]
      }
      Scenario 3: When the permission policy includes a condition, the statement is effective only if the condition keys support precise matching, such as 'string_equal', 'ip_equal', 'ip_not_equal', etc. If other types of condition keys (for example, 'string_not_equal', etc.) are included, the statement will not be effective.
      For instance, even if the following policy is authorized, users may still be able to view resources associated with the tag 'T'.
      {
         "version": "2.0",
         "statement": [
             {
                 "effect": "allow",
                 "action": [
                     "*"
                 ],
                 "resource": "*",
                 "condition": {
                     "for_any_value:string_not_equal": {
                         "qcs:resource_tag": [
                             "key&T"  // Tag T
                         ]
                     }
                 }
             }
         ]
      }
      Scenario 4: When both permissions to access all resources and denial of access to resources bound with specific tags are granted, the denial of access may not be effective, meaning that resources associated with that tag can still be viewed.
      For instance, even if the following policy is authorized, users may still be able to view all resources under the root account when viewing the resource list.
      {
         "version": "2.0",
         "statement": [
             {
                 "effect": "allow",
                 "action": [
                     "*"
                 ],
                 "resource": "*"
             },
             {
                 "effect": "deny",
                 "action": [
                     "*"
                 ],
                 "resource": "*",
                 "condition": {
                     "for_any_value:string_equal": {
                         "qcs:resource_tag": [
                             "key&T"  // Tag T
                         ]
                     }
                 }
             }
         ]
      } 

      Denying Access to COS of All Users (Anonymous Users)

      If 'deny' is configured for all users (anonymous users) in the COS Bucket ACL or Bucket Policy, but there is also a specific 'allow' for a certain user, the user allowed can still access the COS bucket.

      Billing-Related Operations

      If a sub-user is associated with the AdministratorAccess or QCloudFinanceFullAccess policy, and is also associated with a policy that denies action finance:xx, this sub-user can still be authenticated for action finance:xx and will not be denied access.
      Contact Us

      Contact our sales team or business advisors to help your business.

      Contact Us
      Technical Support

      Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

      Submit a Ticket
      7x24 Phone Support
      Copyright © 2013-2024 Tencent Cloud. All Rights Reserved.
      Privacy PolicyLegalCookie Policy