IAM-based Access Control

If you need to assign different permissions to employees in your enterprise to access your cloud resources, 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 securely access cloud resources. If your account does not require IAM for permissions management, you can skip this section.

IAM is a free service. You only pay for the resources in your account.

With IAM, you can control access to specific Huawei Cloud resources. For example, if you want some software developers in your enterprise to use CCI resources but do not want them to delete resources or perform any other high-risk operations, you can grant permission to use CCI resources but not permission to delete them.

You can grant permissions by using roles and policies.

• Roles: A coarse-grained authorization strategy provided by IAM to assign permissions based on users' job responsibilities. Only a limited number of service-level roles are available for authorization. Huawei Cloud services depend on each other. When you grant permissions using roles, you also need to attach any existing role dependencies. Roles are not ideal for fine-grained authorization and least privilege access.
• 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 privilege access. For example, you can grant users only permission to manage ECSs of a certain type. A majority of fine-grained policies contain permissions for specific APIs, and permissions are defined using API actions. For the API actions supported by CCI, see Permissions Policies and Supported Actions.

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.

ABAC is a policy-based authorization model, which offers more fine-grained, flexible access control. 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 these two authorization models.

Assume that you want to grant IAM users permission to create ECSs in CN North-Beijing4 and OBS buckets in CN South-Guangzhou. With RBAC, the administrator needs to create two custom policies and attach both to the IAM users. With ABAC, the administrator only needs to create one custom policy, configure the condition key g:RequestedRegion for the policy, and then attach the policy to the users or grant the users the access permissions to the specified regions. ABAC is more flexible than RBAC.

Policies and actions in the two authorization models are not interoperable. You are advised to use the ABAC authorization model. For details about system-defined permissions, see System-defined Permissions in RBAC and System-defined Permissions in ABAC.

For more information about IAM, see IAM Service Overview.