Help Center/ Cloud Container Instance (CCI)/ API Reference/ Permissions Policies and Supported Actions/ Introduction
Updated on 2026-02-25 GMT+08:00
View PDF
Share

Introduction

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

With IAM, you can control access to specific resource using IAM users, user groups, IAM agencies. You can grant users permissions by using roles and policies. Roles are provided by IAM to define service-based permissions that match users' job responsibilities. Policies define API-based permissions for operations on specific resources under certain conditions, allowing for more fine-grained, secure access control of cloud resources.

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 the policies to a principal so that the principal can have the specified permissions. The principal can then perform specific operations on cloud services based on the assigned permissions.

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

Table 1 Differences between RBAC and ABAC

Parameter

Core Relationship

Permissions

Authorization Method

Scenario

RBAC

Roles
  • System-defined roles
  • System-defined policies
  • Custom policies

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.

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, this model can be hard to set up. It requires a certain amount of expertise and is suitable for medium- and large-sized enterprises.

Assume that you want to grant IAM users the permissions needed to create ECSs in CN North-Beijing4 and CCI pods in CN South-Guangzhou. With RBAC, the administrator needs to create two custom policies and assign 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.

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 the CCI pod list. With policy-based authorization, the IAM user must be granted the permissions allowing for action cci:pod:list.