Help Center/ Data Encryption Workshop/ API Reference/ Permissions Policies and Supported Actions/ Introduction to Permissions Policies and Supported Actions
Updated on 2025-11-10 GMT+08:00
View PDF
Share

Introduction to Permissions Policies and Supported Actions

If fine-grained permission management is required for your DEW, you can use IAM. In other cases, skip this section.

With IAM, you can control access to specific Huawei Cloud resources from principals (IAM users, user groups, agencies, or trust agencies). There are two types of IAM authorization: role/policy authorization and identity policy authorization.

The differences and relationships between the two authorization models are as follows:

Table 1 Differences between the two types of authorization

Name

Relationship

Permission

Authorization Method

Scenario

Role/Policy

User-permission-authorization scope
  • System-defined role
  • System-defined policies
  • Custom policies

Grants a role or policy to principals.

To authorize a user, add it to a user group and specify the scope of authorization. It is hard to provide fine-grained permissions control using authorization granted by user groups and a limited number of condition keys. This method is suitable for small- and medium-sized enterprises.

Identity policy

User-policy
  • System-defined policies
  • Custom identity policies
  • Grants an identity policy to principals.
  • Attaches identity policies to principals.

To authorize a user, grant an identity policy to it. User-specific authorization and a variety of key conditions allow for more fine-grained permissions control. However, this model can be hard to set up. It requires a certain amount of expertise and 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 permissions required for calling an API are determined by the actions supported by the API. Only users who have been granted permissions allowing the actions can call the API successfully.

Parent Topic: Permissions Policies and Supported Actions