Permissions Management

If you need to assign different permissions to employees in your enterprise to access your resources purchased on Huawei Cloud, Identity and Access Management (IAM) is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, helping you to securely access your Huawei Cloud resources. If your HUAWEI ID does not require IAM for permissions management, you can skip this section.

IAM can be used on Huawei Cloud for free. You pay only for the resources purchased using your account.

With IAM, you can control access to specific Huawei Cloud resources. For example, you can create IAM users for software developers and grant them the permissions required for using COC resources but not the permissions needed for performing any other operations.

You can grant permissions using roles and policies.

Roles: A coarse-grained authorization method where you assign permissions based on user responsibilities. Only a limited number of service-level roles are available for authorization. Cloud Services depend on each other. When you grant permissions using roles, you also need to attach dependent roles. However, roles are not an ideal choice for fine-grained authorization and secure access control.
Policies: A fine-grained authorization strategy that defines permissions required to perform operations on specific cloud resources under certain conditions. This type of authorization is more flexible and is ideal for least secure access control. For example, you can grant users only permissions to manage ECSs of a certain type.

IAM supports both role-based access control (RBAC) and attribute-based access control (ABAC).

RBAC is a role-based authorization model. By default, a new principal does not have any permissions. You need to assign a system-defined role, system-defined policy, or custom policy to the principal and select the authorization scope so that the principal can have the specified permissions.

The other is a new model based on ABAC, which is also called policy authorization. An administrator can tailor access control policies based on service requirements and then attach or grant the policies to a principal so that the principal can have the specified permissions. The principal can then perform operations on specified cloud services.

The following table describes the differences between the two authorization models.

**Table 1** Differences between RBAC and ABAC
Authorization Model	Core Relationship	Permission	Authorization Method	Application Scenario
RBAC	Roles	System-defined roles System-defined policies Custom policies	Granting 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.
ABAC	Policies	System-defined policies Custom policies	Granting policies to principals Attaching policies to principals	It gives you more granular, more flexible control of your resources. There is no need to modify existing rules to accommodate new users. All administrators need to do is assign relevant attributes to the new users. However, the construction of a policy-based authorization model is more complex and has higher requirements on the professional capabilities. Therefore, this model is more suitable for medium- and large-sized enterprises.

COC supports only RBAC. For details about supported system-defined permissions, see System-defined Permissions in RBAC.

For more information about IAM, see What Is IAM?

System-defined Permissions in RBAC

COC supports RBAC. By default, new IAM users do not have any permissions assigned. You need to add them to one or more groups and attach policies or roles to these groups. The users then inherit permissions from the groups and can perform specified operations on cloud services based on the permissions they have been assigned.

COC is a global service deployed and accessed without specifying any physical region. When you set the authorization scope to Global services, users have permission to access COC resources in all regions.

Table 2 lists all the system-defined permissions for COC. System-defined policies in RBAC and ABAC are not interoperable.

**Table 2** COC system-defined permissions
System-defined Role/Policy Name	Description	Type	Dependency
COC ReadOnlyAccess	Read-only permissions of COC	System-defined policies	None
COC FullAccess	Administrator permissions of COC	System-defined policies	None

Table 3 lists the common operations supported by system-defined permissions for COC.

**Table 3** Common operations supported by each system-defined policy
Operation	COC ReadOnlyAccess	COC FullAccess
Viewing to-do tasks	√	√
Creating and handling to-do tasks	x	√
Viewing the resource list	√	√
Managing resources	x	√
Viewing the script list	√	√
Adding, deleting, modifying, and executing scripts	x	√
Viewing the job list	√	√
Adding, deleting, modifying, and executing jobs	x	√
Performing operations on ECSs	x	√
Viewing scheduled O&M tasks	√	√
Adding, deleting, modifying, and executing scheduled O&M tasks	x	√
Viewing the parameter center	√	√
Adding, deleting, and modifying parameters	x	√
Viewing incident tickets	√	√
Creating and handling incidents	x	√
Viewing alarm records	√	√
Handling alarms	x	√
View chaos drill plans	√	√
Executing drill tasks	x	√
Viewing shift schedules	√	√
Creating a shift schedule	x	√
Viewing account baselines	√	√
Creating account baselines	x	√

System-defined Permissions in ABAC

COC supports ABAC. Table 4 lists all the system-defined policies for COC with ABAC System-defined policies in RBAC and ABAC are not interoperable.

**Table 4** System-defined policies for COC
Policy	Description	Policy Type
COCReadOnlyPolicy	Read-only permissions of COC	System-defined policies
COCFullAccessPolicy	Administrator permissions of COC	System-defined policies

Table 5 lists the common operations supported by system-defined identity policies for COC.

**Table 5** Common operations supported by each system-defined policy
Operation	COCReadOnlyPolicy	COCFullAccessPolicy
Viewing to-do tasks	√	√
Creating and handling to-do tasks	x	√
Viewing the resource list	√	√
Managing resources	x	√
Viewing the script list	√	√
Adding, deleting, modifying, and executing scripts	x	√
Viewing the job list	√	√
Adding, deleting, modifying, and executing jobs	x	√
Performing operations on ECSs	x	√
Viewing scheduled O&M tasks	√	√
Adding, deleting, modifying, and executing scheduled O&M jobs	x	√
Viewing the parameter center	√	√
Adding, deleting, and modifying parameters	x	√
Viewing incident tickets	√	√
Creating and handling incidents	x	√
Viewing alarm records	√	√
Handling alarms	x	√
Viewing chaos drill plans	√	√
Executing drill tasks	x	√
Viewing shift schedules	√	√
Creating a shift schedule	x	√
Viewing account baselines	√	√
Creating account baselines	x	√

Feedback

Was this page helpful?

Helpful Not helpful

Provide feedback

Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.

The system is busy. Please try again later.

Which of the following issues have you encountered?

Content is inconsistent with the product UI

Unclear descriptions

Lack of examples or code

Incorrect steps

Can't find what I need

Lack of best practices

Feedback (optional)

0/500

Select at least one type of issue, and enter your comments or suggestions.

Enter a maximum of 500 characters.

Submit Cancel

For any further questions, feel free to contact us through the chatbot.

Chatbot

Permissions Management

System-defined Permissions in RBAC

System-defined Permissions in ABAC

Related Links

Feedback

Was this page helpful?