Policy Evaluation Logic

When you try to use the Huawei Cloud console, API, or CLI, they send requests to Huawei Cloud. When a cloud service receives a request, it completes several steps to determine whether to allow or deny the request.

Authentication: The cloud service authenticates the principal that sends the request. (Some services may skip this step and may allow some requests from anonymous identities.)
Request context processing: The cloud service processes information carried in the request for subsequent policy evaluation.
Policy logic evaluation: IAM evaluates all policy types in sequence and determines whether to allow or deny the request based on the request context.

The following is an example:

When both identity policies and resource policies are used, if an IAM principal accesses resources in the same account, only one of the identity policy and resource policy needs to allow the access. If an IAM principal accesses resources across accounts, both the identity and resource policies must allow the access.
If the account to which the IAM principal belongs is a member of an organization and the IAM principal accesses a resource that does not have a resource policy configured, the final permissions are the intersection of the identity policy and the SCP. This means that an operation must be allowed by both policies to be allowed. If either the identity policy or the SCP explicitly denies an operation, it is denied. For more information, see IAM Policy Evaluation Logic.

An explicit deny in any policy overrides allows in other policies.

Request Context

Importance of request context
Understanding request context and its interaction with policy evaluation is important for the following:
- Checking access issues.
- Designing effective and secure policies.
- Understanding the full scope of permissions granted by a policy.
- Predicting policy evaluation results in different scenarios
How IAM uses request context
Huawei Cloud collects the necessary information required for policy evaluation into the request context. Then, IAM evaluates policies based on the request context. A request context contains the following information:
- Principal: the person (such as an IAM user, a trust agency, and an application) who sends the request
- Action: the action that the principal wants to perform
- Resource: the Huawei Cloud resource upon which the principal requests to perform an operation
- Environment data: information about the IP address, time, and user agent in the request
- Resource data: data related to the resource requested, such as the tags of an IAM user and trust agency
IAM compares the information in the request context with the policies associated with the principal to determine whether to allow or deny the request.

How IAM evaluates a policy depends on the type of the policy associated with the principal. For more information about policy types, see Access Control Policies Supported by IAM. For details about the evaluation logic when multiple policies are used together, see IAM Policy Evaluation Logic.

Example of Identity Policy Evaluation

The following example uses identity policy-based permission control to describe how to evaluate a policy based on the request context.

The following identity policy allows the iam:agencies:getV5 action only when the request context contains g:PrincipalTag/dept=123 and the requested resource matches iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test.

{
	"Version": "5.0",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"iam:agencies:getV5"
			],
			"Resource": [
				"iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test"
			],
			"Condition": {
				"StringEquals": {
					"g:PrincipalTag/dept": [
						"123"
					]
				}
			}
		}
	]
}

The following table shows how IAM uses request context to evaluate identity policies and make decisions.

**Table 1** How IAM uses request context to evaluate identity policies and make decisions
Request Context	Result
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:agencies:getV5 Resource: iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test Context: - g:PrincipalTag/dept=123	Match
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:mfa:listMFADevicesV5 Resource: iam::8c1eef3a241945f69c3d3a6b0252e783:agency:test Context: - g:PrincipalTag/dept=123 NOTE: The action in the request is iam:mfa:listMFADevicesV5*, which does not match the policy.	No match
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:agencies:getV5 Resource: iam::8c1eef3a241945f69c3d3a6b0252e783:agency:test Context: - g:PrincipalTag/dept=321 NOTE: The request contains g:PrincipalTag/dept=321* so it does not match the policy.	No match
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:agencies:getV5 Resource: iam::8c1eef3a241945f69c3d3a6b0252e783:agency:test Context: NOTE: The request does not contain g:PrincipalTag/dept* so it does not match the policy.	No match

IAM Policy Evaluation Logic

IAM policy evaluation logic
IAM policy evaluation logic is classified into intra-account authorization and cross-account authorization. IAM checks the mandatory access control (MAC) policy and discretionary access control (DAC) policy based on the authentication request context. If the authentication request context does not match any "Allow" MAC policy, the authentication result is "Deny". After checking the MAC policy, IAM checks whether the principal of the request is authorized by the DAC policy. For details about MAC policies and DAC policies, see Access Control Policies Supported by IAM.
- Intra-account policy evaluation
  The following figure shows the policy evaluation logic of intra-account authorization.
  Figure 1 Policy evaluation logic of intra-account authorization
  
  Example for Intra-account policy evaluation
  
  There are two types of policies: identity policies and resource policies. When a principal requests access to a resource in an account, at least one of the two types of policies must grant the principal the access permission. Note that an explicit deny in either type of policy overrides the allow in the other type of policy.
  
  If one of the identity policy and resource policy in an account allows the request, and the other does not allow (or explicitly deny) the request, the request is still allowed. Note that this does not apply to trust policies. When a trust agency is used, the trust policy and identity policy must both allow the request for the trust agency to be assumed.
  For example, you can attach the following identity policy to the IAM user colorsone to allow the user to obtain some list permissions of OBS.
```
{
  "Version": "5.0",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "obs:bucket:listAllMyBuckets",
        "obs:bucket:listBucket",
        "obs:bucket:listBucketMultipartUploads",
        "obs:bucket:listBucketVersions",
        "obs:object:listMultipartUploadParts"
      ],
      "Resource": [
        "obs:*:*:bucket:*"
      ],
      "Condition": {
        "StringEquals": {
          "g:UserName": [
            "colorsone"
          ]
        }
      }
    }
  ]
}
```
  Assume that the ID of user colorsone is aaaaaae41869426db2e2d87b7d1db00b and the account ID is 66871fe214924948a794aaaaaaaaaaaa. You can also attach the following resource policy (called bucket policy) to bucket my-bucket to achieve the same result. This policy specifies that user colorsone can access bucket my-bucket, and has the permissions to list and query details of the resource.
```
{
    "Statement": [
        {
            "Sid": "listobs",
            "Effect": "Allow",
            "Principal": {
                "ID": [
                    "domain/66871fe214924948a794aaaaaaaaaaaa:user/aaaaaae41869426db2e2d87b7d1db00b"
                ]
            },
            "Action": [
                "Get*",
                "List*"
            ],
            "Resource": [
                "my-bucket"
            ]
        }
    ]
}
```
- Cross-account policy evaluation
  You can allow principals in one account to access resources in another account. This is called cross-account access. To allow cross-account authorization, attach a resource policy to the resource you want to share. The resource policy specifies principals who are allowed to access the resource. Additionally, you must attach an identity policy to the principals in the account you want to share with. The identity policy specifies the resources that the principals are allowed to access. A principal can access a resource only if both the resource policy and identity policy allow the access. Other types of policies, such as SCPs of Organizations and resource sharing policies of RAM, may also affect the policy evaluation of cross-account access.
  
  The following figure shows the policy evaluation logic of cross-account authorization.
  Figure 2 Policy evaluation logic of cross-account authorization
  
  Example of cross-account policy evaluation
  
  The following example shows how account B (account ID: 888888888888434680659e1bec79e6e5) grants permissions to an IAM user in account A (account ID: 777777777777434680659e1bec79e6e5) to access resources in account B.
  For example, user A is a developer and has an IAM user whose user ID is 11111111111e4cdba0df0735a4bf01ed in account A. User A wants to access resources in bucket test-d177 in account B. Assume that user A is attached to the following identity policy, which grants user A all operations on OBS.
```
{
  "Version": "5.0",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "OBS:*:*"
      ]
    }
  ]
}
```
  In addition, the following resource policy (bucket policy) needs to be attached to the test-d177 bucket in AccountB. This policy grants user A the permissions to list and query details of test-d177 bucket. User A can query resources in the bucket but cannot delete or modify the resources.
```
{
    "Statement": [
        {
            "Sid": "listobs",
            "Effect": "Allow",
            "Principal": {
                "ID": [
                    "domain/777777777777434680659e1bec79e6e5:user/11111111111e4cdba0df0735a4bf01ed"
                ]
            },
            "Action": [
                "Get*",
                "List*"
            ],
            "Resource": [
                "test-d177",
                "test-d177/*"
            ]
        }
    ]
}    
```
  For more examples of cross-account resource access, see Accessing Resource Across Accounts.
- Explicit deny and implicit deny
  If a policy contains a "Deny" statement, the request is explicitly denied. If a policy applied to a request contains both "Allow" and "Deny" statements, the "Deny" statement takes precedence over the "Allow" statement, and the request is explicitly denied.
  
  If no "Deny" or "Allow" statement is present, implicit deny takes effect. In this case, you must explicitly allow the operations that the principal requests. When creating a policy, you must create a policy that contains "Allow" statements to allow the principal to successfully send requests.
  You can choose to use any combination of explicit deny and implicit deny. For example, you can create the following identity policy that contains explicit allow, implicit deny, and explicit deny statements. The first statement of the identity policy allows all operations related to iam:users:*, but does not explicitly allow other operations. For example, operations related to iam:agencies:* are implicitly denied. In the second and third statements, both "Deny" and "Allow" statements are specified for operations related to iam:groups:*, so all operations related to iam:groups:* are explicitly denied by the second statement, even if the third statement explicitly grants permissions to iam:groups:*.
```
{
  "Version": "5.0",
  "Statement": [
    {
      "Sid": "statementOne",
      "Effect": "Allow",
      "Action": [
        "iam:users:*"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "statementTwo",
      "Effect": "Deny",
      "Action": [
        "iam:groups:*"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "statementThree",
      "Effect": "Allow",
      "Action": [
        "iam:groups:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
```