Skip to main content Link Menu Expand (external link) Document Search Copy Copied

IAM - Access Control

User

Sub-users

A sub-user is a type of IAM user identity that has the following characteristics: Belongs to the cloud service account (i.e. the master account), which is created and managed by the master account, and generally corresponds to the employees or applications of the enterprise;

By default, there are no permissions, and the master account can only log in/access resources after authorization;

Each sub-user independently has a long-term API key;

Independent billing is not supported, and the consumption generated by sub-users is settled through the master account.

The sub-user is deleted without affecting the resources it created;

Create sub-user

The sub-user logs in through the mailbox, and the user name is the unique identifier of the sub-user under the cloud service account.

Add permissions for sub-users

Sub-users need to obtain resource permissions to carry out a series of management tasks. IAM allows sub-users to directly bind resource permissions, and can also exercise group resource permissions by joining a user group.

Add sub user to user group

After a sub-user joins a user group, it automatically obtains the resource permissions of the group. Sub-users can join multiple user groups.

Freeze/unfreeze/logout sub-user

After the sub-user is frozen, it will not be able to log in, and it will be restored after unfreezing. Sub-user logout is irreversible. Any changes to sub-users will not affect the resource usage under the cloud service account.

View sub user details

Manage the specific permissions and group information of sub-users through the details page. Note that sub-users cannot manage the resource permissions of their group.

User groups

Use user groups to group sub-users with similar responsibilities or permissions into one category and unify authorization, so as to manage IAM sub-users more efficiently.

When the functional scope of the entire user group changes, only the authorization of the group needs to be modified;

When the scope of permissions of individual users changes, e.g. transfer and new members join, just move them out/into the user group;

Create a user group

“User Group Name” represents the unique identification of the User Group under the cloud service account and cannot be duplicated.

Authorize user groups

Select the permission policy to be bound and the effective scope of the policy for the user group. As shown in the figure, this user group has super administrator privileges under the default project. Financial center permissions and access control permissions are global policies and do not need to specify the effective scope.

Add members to the user group

Select a sub-user to join the user group, and the members of the group automatically obtain the permissions bound by the user group.

Delete a user group

Deleting a user group automatically removes all members of the group.

View user group details

Use the details page to manage the specific permissions and member information of user groups, including adding, removing, and viewing.

Policy management

Permissions describe the relationship between a user and a resource, and determine the user’s ability to access and control the resource.

A policy is a collection of permissions built through syntax. It consists of five parts: V (version) E (effect) A (action) R (resource) C (condition). It describes exactly what actions the user can achieve on what resources under what conditions.

  • V (version) Syntax version, maintained by SCloud. The current version of the system policy V1 cannot be modified; A new version of a custom policy is automatically generated after you edit and save it.
  • E (effect) Enforcement effect, Allow or Deny.
  • A (action) API name, one or more supported.
  • R (resource) resource, denoted by urn.
  • C (condition) defines the prerequisites for the policy to take effect. e.g. Time, IP.

SCloud provides two modes of permission policies:

  • System Policy – configured and managed by SCloud
  • Custom policies – configured and managed by the user

Policy level

Policies can be divided into two levels according to the scope of effect, global level and project level.

The scope of the global level is the global service of the account, which does not distinguish between projects, and the global level policy does not support sub-project authorization;

The effective scope of the project level is the specified project, and the project-level policy supports sub-project authorization;

Some system policies are global/project level, and custom policies cannot be created.

Review the system policy

A system policy is a set of permissions packaged by action type. Click Details to view the APIs included in the policy and the references.

Create a custom policy

Custom policies can specify specific APIs for allow/deny actions. For example, sub-users are not allowed to create new ECSs.

Custom policies can be edited and deleted.

After the content of the permission policy is modified, the system automatically generates a new version of the permission policy, which becomes the current version.

You can set a historical version to the current version.

Authorize sub-users

When authorizing, you need to distinguish between global-level and project-level authorization, select the project level, and select some projects under the account.

Project

When you register a SCloud cloud account, the system creates a project by default, and the resources to which you belong fall under this project. If you have a new service to use cloud services, you can create a new project and deploy the new service under the new project to achieve network and logical isolation between services.

  1. The default network and logical isolation between projects, that is, the host of project A cannot bind the EIP of project B, and by default cannot communicate with the host intranet of project B. However, after the project is connected, uhost, udb, and umem can realize intranet communication.
  2. Resources cannot be migrated between projects, that is, the hosts in project A cannot be migrated to project B, because they are not in a basic network and are logically isolated. However, for static resources such as autonomous images, you can submit a ticket to request migration to other projects.
  3. Only the cloud account itself can delete a project, and it can only be deleted if the project has no resources, no sub-members, or no connection with other projects.

Sets the specified project as the default project

Since there may be multiple projects under a cloud account, you must specify the project first, whether you manage cloud resources through the console or API. If you do not specify it, the system assumes that you have specified a Default Project.

  1. After entering a certain product, click the drop-down arrow in the upper left corner to set a certain project as the default project.
  2. The current project settings become the default project, and the next time you log in, you will directly enter the project console.

Edit the project

  1. Open the permission management page, move the mouse next to the project name to be modified, and click ICON.
  2. Enter the project name and click Confirm to modify.

    Only company administrators can edit project information, and currently only support modifying the project name.

    Delete the project

  3. Open the permission management page and click Delete in the operation item.
  4. After confirmation, click the OK button.

This operation can only be performed by administrators, please remove all project members and resources before deleting the project. Once the item is deleted, it cannot be recovered, so please proceed with caution.

Add members to the project

  1. Open Permission Management - Personnel Management and click New Sub-account
  2. Fill in the sub-account information and click Next.
  3. Set the role and project, click OK.
  4. Notify the owner of the sub-account to check the activation email.
  5. The owner of the sub-account clicks the activation link in the email and sets the account password to log in and use

Successful practices and typical cases

Successful practice

  1. Change the login password regularly, preferably including uppercase and lowercase letters, numbers, special characters, and do not contain common English words. You can enable the regular password change function for a specified account, please refer to:
  2. Follow the principle of minimum authorization. When you authorize a member role, grant just the role that is required for his job. If an O&M personnel in your company only needs to view the load of all cloud hosts, grant them only the role of “cloud host read-only”. Enable API access control, allowing only your company’s egress IP to manage cloud resources through APIs, not all IPs. You can go to the API product and set it in the API key

Typical case

Bob is the technical backbone of a high-tech company, and later decided to start a business with a few old friends. At the beginning of the establishment of the company,

Bob registered an account (devops@example.com) in SCloud through the recommendation of a friend, tried uhost, eip, udb and other cloud products, and after several evaluations, finally chose SCloud as its cloud service provider, and officially renewed the previous trial uhost, eip, and udb for one year, so as to enjoy the discount of buying 10 months and getting 2 months free.

  1. In addition to safety, it is also safety There is no need to talk about the hardships of entrepreneurship, seven or eight people nestled in a house of tens of square meters, after several months of struggle, the new product finally came out, and the response from the outside world was good.
    Considering that the possibility of account passwords being leaked is very high, and once leaked, the impact on the company’s future is simply unimaginable.
    After consulting SCloud’s technical support, John Doe knew that SCloud provides two two-factor secure login services: WeChat dynamic password and mobile phone scan code login, of which WeChat secret protection supports the use of WeChat binding account, in addition to entering the account password each time you log in, you must obtain a dynamic verification code input from WeChat to log in, without installing or purchasing any MFA equipment. Scan code login is more convenient, only need to install onion APP, each time you log in only need to use the onion APP to scan the code to log in, completely free.
    After several considerations, Bob chose the scheme of scanning the code to log in. The mobile phone carries with you, and the face recognition is turned on in the onion APP, only Bob can start the onion APP, compared to the WeChat verification code, the security level is higher and it is officially goodbye to the password era.
  2. Multi-person cooperation, its happiness After many optimizations and upgrades of the product, the number of users is increasing, the company has entered a stage of rapid development, and the R&D team has become dozens of people, all of whom use devops@example.com to manage cloud resources is neither convenient nor secure.
    Bob enabled the account and permission management service, created an account for each partner who had the need to manage cloud resources, and added these accounts to the only project “X Plan” of the devops@example.com account, so that each partner could log in to SCloud’s cloud console with his own account to manage cloud resources.
    Subsequently, Bob created other roles based on the initial role of project administrator and granted them to the corresponding sub-accounts. Each role has specific permissions, for example, the role of web development engineer only has the permission to view and operate the product of Uhost, but does not have the permission to create and delete. If the role of an account in “Project X” is web development engineer, then this account only has the view and operation permissions of the uhost product.
  3. Multi-business management, no big deal In the process of “Project X”, several friends of Bob’s team identified an emerging market opportunity and named it “Y Mission”.
    To ensure business security, Bob created a new project and named it “Y Task”. Move the partners in charge of “Y Task” into “Y Task”, and since this group of partners is not in charge of Plan X, they will also move them out of the “Plan X” project.
    In this way, the partner responsible for the Y task can only manage the cloud resources used to deploy the Y task, and the Y task and the X plan are under different basic networks and do not affect each other.