Basic Concepts About Permissions

Permissions

New IAM users or user groups do not have any permissions assigned by default. You need to attach identity policies to these users or groups to grant the permissions to allow them to perform operations on cloud services.

Identity Policies

Identity policies define permissions for actions on resources. For details, see Identity Policy Grammar. Identity policy-based authorization is more flexible and is ideal for least privilege access. You can attach identity policies to IAM users, user groups, agencies, and trust agencies, to specify specific operations that principals can perform. For example, you can attach an identity policy to IAM user developer to perform the ecs:blockDevice:get action on ECS.

System-defined Identity Policies

System-defined identity policies define the common actions on cloud services. These policies cannot be modified and can only be used to assign permissions. For details about the system-defined identity policies of all cloud services, see System-defined Permissions.

If there are no system-defined identity policies for a specific cloud service in IAM, it means the cloud service does not support IAM. You can submit a service ticket to request that cloud service to predefine permissions in IAM.

Custom Identity Policies

If system-defined identity policies cannot meet your requirements, you can create custom identity policies for more refined access control.

You can create custom identity policies in the visual editor or in JSON view.

Identity Policy-based Authentication

When a user initiates an access request, the system authenticates the request based on the actions in the policies that have been attached to the group to which the user belongs. The following diagram shows the authentication process.

Figure 1 Authentication process

1. A user initiates an access request.
2. The system looks for a Deny among the applicable actions of the identity policies from which the user gets permissions. If the system finds an applicable Deny, it returns a decision of Deny, and the authentication ends. Here the identity policy includes a Deny statement, so the request is explicitly denied.
3. If no Deny is found applicable, the system looks for an Allow that would apply to the request. If the system finds an applicable Allow, it returns a final decision of Allow, and the authentication ends.
4. If no Allow is found applicable, the system returns a final decision of Deny, and the authentication ends. Here the identity policy includes neither an Allow nor a Deny statement, so the request is implicitly denied.

Resource Policies

Different from identity policies, resource policies can be attached to Huawei Cloud resources that support resource policies. For example, a trust agency supports resource policies, and the trust policy attached to the trust agency is a resource policy. You can write a trust policy when creating a trust agency to allow the specified principals to assume the trust agency. For the services that support resource policies, see "Resource-based Policy" in Cloud Services for Using Identity Policies and Trust Agencies.

You can use resource policies to specify which principals can access what resources and what actions they can perform on the resources.

Differences Between Identity Policies and Resource Policies

Identity Policies

In the following example, Account A has three IAM users: engineer, finance, and operation. The account also has three resources: Resource A, Resource B, and Resource C. The administrator attaches an identity policy to three IAM users. They can perform specified operations on resources Resource A, Resource B, and Resource C. For example, engineer can perform the List operation on Resource A, but cannot perform any operations on Resource B. User finance can perform the Read operation on Resource B, and user operation can perform List and Read operations on Resource C.

Figure 2 Accessing resources in the same account using identity policies

Resource policies

In the following example, Account A has three IAM users: engineer, finance, and operation. Account B has three resources: Resource A, Resource B, and Resource C. The administrator of Account A attaches an identity policy to three IAM users. They can perform specified operations on resources Resource A, Resource B, and Resource C. For example, engineer can perform the List operation on Resource A, but cannot perform any operations on Resource B. User finance can perform the Read operation on Resource B, and user operation can perform List and Read operations on Resource C. The administrator of account B attaches some resource policies to Resource A, B, and C, allowing user engineer to perform the List operation on Resource A and Resource B, user finance to perform Read on Resource B, and user operation to perform Read on Resource C. Based on the preceding permissions, user engineer of account A can perform the List operation on Resource A of account B but cannot perform the List operation on Resource B. User finance of account A can perform the Read operation on Resource B of account B but cannot perform the List operation on Resource B. User operation of account A can perform the Read operation on Resource C of account B but cannot perform the List operation on Resource C.

Figure 3 Accessing resources in another account using identity policies and resource policies

Both identity policies and resource policies are permission policies and are evaluated together. Accessing resources within your own account generally requires either the identity policy or the resource policy to permit the corresponding operation, such as allowing access through the OBS bucket policy in the resource policy. However, the IAM trust policy is an exception; although it is also a type of resource policy, access is granted only if both the identity policy and the trust policy permit. To access resources in another account, both the identity policy and resource policy must allow the access. For details, see IAM Policy Evaluation Logic.