Permissions Management
If you need to assign different permissions to employees in your organization to access your CSS resources, IAM is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control.
If the current account has met your requirements, you do not need to create an independent IAM user for permission management. Then you can skip this section. This will not affect other functions of CSS.
With IAM, you can use your account to create IAM users for your employees and assign permissions to the users to control their access to your resources. IAM is free of charge. You pay only for the resources you purchase. For more information about IAM, see "IAM Service Overview".
Permissions Management
By default, new IAM users do not have any permissions assigned. To grant permissions to a user, add the user to one or more groups and attach permissions, policies or roles to these groups. The user then inherits permissions from its groups. This process is called authorization. and can perform specified operations on cloud services based on these permissions.
CSS is a project-level service deployed in specific physical regions. Therefore, CSS permissions are assigned to projects in specific regions and only take effect in these regions. If you want the permissions to take effect in all regions, you need to assign the permissions to projects in each region. When accessing CSS, the users need to switch to a region where they have been authorized to use cloud services.
You can use roles and policies to grant users permissions.
- Roles are a type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. There are only a limited number of service-level roles for granting permissions to users. When using roles to grant permissions, you need to also assign dependency roles. Roles are not ideal for fine-grained authorization and secure access control.
- Policies are a type of fine-grained authorization mechanism that defines the permissions for performing operations on specific cloud resources under certain conditions. This mechanism allows for more flexible authorization. Policies allow you to meet requirements for more secure access control. For example, CSS administrators can only grant CSS users the permissions needed for managing a particular type of CSS resources. Most policies define permissions based on APIs. For the API actions supported by CSS, see Permissions Policies and Supported Actions.
Table 1 lists all the system-defined roles and policies supported by CSS.
- Elasticsearch Administrator depends on the roles of other services to execute its permissions. Therefore, if you assign the Elasticsearch Administrator role to a user, assign its dependency roles at the same time.
- CSS FullAccess and CSS ReadOnlyAccess can be used to control the resources that users can access. For example, if you want your software developers to use CSS resources but not delete them or perform any high-risk operations, you can create IAM users for these software developers and assign them only the permissions required for using CSS resources.
Role/Policy Name |
Type |
Role/Policy Description |
Dependency |
---|---|---|---|
Elasticsearch Administrator |
System-defined role |
Full permissions for CSS. This role depends on the Tenant Guest and Server Administrator roles in the same project. |
|
CSS FullAccess |
System-defined policy |
Full CSS permissions granted through policies. Users with these permissions can perform all operations on CSS. |
None |
CSS ReadOnlyAccess |
System-defined policy |
Read-only permissions for CSS. Users with these permissions can only view CSS data. |
None |
Table 2 lists the common operations supported by each system permission of CSS. Please choose proper system permissions according to this table.
Operation |
CSS FullAccess |
CSS ReadOnlyAccess |
Elasticsearch Administrator |
Remarks |
---|---|---|---|---|
Creating a cluster |
√ |
x |
√ |
- |
Querying a cluster list |
√ |
√ |
√ |
- |
Querying cluster details |
√ |
√ |
√ |
- |
Deleting a cluster |
√ |
x |
√ |
- |
Restarting a cluster |
√ |
x |
√ |
- |
Expanding cluster capacity |
√ |
x |
√ |
- |
Adding instances and expanding instance storage capacity |
√ |
x |
√ |
- |
Querying tags of a specified cluster |
√ |
√ |
√ |
- |
Querying all tags |
√ |
√ |
√ |
- |
Automatically setting basic configurations of a cluster snapshot |
√ |
x |
√ |
Depends on OBS and IAM permissions |
Modifying basic configurations of a cluster snapshot |
√ |
x |
√ |
Depends on OBS and IAM permissions |
Setting the automatic snapshot creation policy |
√ |
x |
√ |
- |
Querying the automatic snapshot creation policy |
√ |
√ |
√ |
- |
Manually creating a snapshot |
√ |
x |
√ |
- |
Querying the snapshot list |
√ |
√ |
√ |
- |
Restoring a snapshot |
√ |
x |
√ |
- |
Deleting a snapshot |
√ |
x |
√ |
- |
Disabling the snapshot function |
√ |
x |
√ |
- |
Modifying specifications |
√ |
x |
√ |
- |
Scaling in clusters |
√ |
x |
√ |
- |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot