Basic Concepts

A domain (account) is created after you successfully sign up for the cloud platform. Your domain owns your resources and has full access permissions for your cloud services and resources. You can use your domain to perform operations such as resetting the login password and assigning permissions to IAM users.

You can use your domain to create users and assign permissions for specific resources. Each user has their own identity credentials (password and access keys) and uses cloud resources based on the assigned permissions.

If a user forgot their password, the user can reset the password by referring to "What Should I Do If I Forgot My Password?" in the Identity and Access Management FAQs.

An account and its IAM users have a parent-child relationship. IAM users are created by an account, and they only have the permissions granted by the account. The account can modify or revoke the IAM users' permissions at any time.

Authorization is the process of using policies to grant IAM users permissions required to perform specific tasks, such as managing ECS resources in your account. After a system-defined or custom policy is assigned to a user group, users in the group inherit the permissions defined by the policy to manage resources.

An IAM user group is a collection of IAM users. User groups let you specify permissions for multiple users. This makes it easier to manage the permissions for those users. IAM users added to a user group automatically inherit the permissions from the group. If a user is added to multiple user groups, the user inherits the permissions from all these groups.

There is a default user group admin. It has all the permissions required to use all of the cloud resources. IAM users in this group can perform operations on all resources, including but not limited to creating user groups and users, assigning permissions, and managing resources.

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.
• 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 the permissions required to manage ECSs of a certain type. IAM supports both system-defined and custom policies.
  • A system-defined policy defines the common actions of a cloud service. You can use system-defined policies to assign permissions to user groups. You cannot modify such policies. If you need to assign permissions for a specific service to a user group or agency on the IAM console but cannot find corresponding policies, the service does not support permissions management through IAM.
  • Custom policies function as a supplement to system-defined policies. You can create custom policies using the actions supported by cloud services for more refined access control. You can create custom policies in the visual editor or in JSON view.

The cloud platform uses credentials to verify the identities of users when they attempt to access through the console or APIs. Credentials can be passwords or access keys. You can manage your own credentials and your IAM users' credentials.

• Password: A common credential for logging in to the management console or calling APIs.
• Access key: An access key ID/secret access key (AK/SK) pair, which is available only for API calls. Each access key provides a signature for cryptographic authentication to ensure that access requests are secret, complete, and correct.

A virtual MFA device is an application that generates 6-digit verification codes in compliance with the Time-based One-time Password Algorithm (TOTP) standard. MFA devices can be hardware- or software-based. The cloud platform only supports software-based virtual MFA devices, which are application programs running on smart devices such as mobile phones.

A region corresponds to a project. Default projects are defined to group and physically isolate computing, storage, and network resources across regions. You can grant users permissions in a default project to access all resources in the region associated with the project. If you need more refined access control, you can create subprojects under a default project and create resources in subprojects. Then you can assign required permissions for users to access only resources in specific subprojects.

Enterprise projects allow you to group and manage resources across regions. Resources in enterprise projects are logically isolated from each other. An enterprise project can contain resources of multiple regions, and you can easily add resources to or remove resources from enterprise projects.

You can use an agency to establish a trust relationship between your account and another account or a cloud service.

• Account delegation: You can delegate another account to implement O&M on your resources based on assigned permissions.