Updated on 2026-01-08 GMT+08:00

Permissions and Supported Actions

You can use Identity and Access Management (IAM) for fine-grained permissions management of your CCM resources. If your HUAWEI IDaccount does not need individual IAM users, you can skip this section.

With IAM, you can control access to specific Huawei Cloudcloud resources from principals (IAM users, user groups, agencies, or trust agencies). IAM supports role/policy-based authorization and identity policy-based authorization.

The following table describes their differences.

Table 1 Differences between role authorization and policy authorization

Name

Relationship

Permission

Authorization Method

Description

Roles

User-Role-Rights

  • System-defined role
  • System-defined policy
  • Custom policy

Assigning roles or policies to principals

It offers a simple approach to access management but is not always flexible enough. For more granular permissions control, administrators need to constantly add more roles, which may lead to role explosion. This model can work well for small- and medium-sized enterprises where there is not too much work involved in maintaining roles and permissions.

Policies

User-Policy

  • System-defined policy
  • Custom policy
  • Granting a policy to a subject
  • Attaching a policy to a subject

When resources are added, all related roles need to be maintained under role authorization. While the policy-based authorization model only needs to maintain a small number of resources, making it more scalable and convenient. However, this model can be hard to set up. It requires a certain amount of expertise. It is suitable for medium- and large-sized enterprises.

For example, if you want to grant an IAM user the permissions to create ECSs in CN North-Beijing4 and OBSs in CN South-Guangzhou, you need to use the administrator role to create two custom policies and assign them to the IAM user. In the policy-based authorization mode, the administrator only needs to create a custom policy and configure the condition key g:RequestedRegion in the policy to control the authorized regions. You can attach a subject to a policy or grant the policy to the subject to assign the corresponding permissions. This permission configuration mode is more fine-grained and flexible.

Policies and actions in the two authorization models are not interoperable. You are advised to use the policy-based authorization model.

If you use IAM users in your account to call an API, the IAM users must be granted the required permissions. The required permissions are determined by the actions supported by the API. Only users with the policies allowing for those actions can call the API successfully.

Assume that an IAM user wants to call an API to query certificate lists. With role/policy-based authorization, the IAM user must have the scm:cert:list action in their permissions to call the API. With identity policy-based authorization, the IAM user must have the scm:cert:list action in their permissions to call the API.