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.
Permissions Management¶
New IAM users do not have any permissions assigned by default. You need to first add them to one or more groups and attach policies or roles to these groups. The users then inherit permissions from the groups and can perform specified operations on cloud services based on the permissions they have been assigned.
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.
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. Some functions depend on corresponding permissions. To use certain functions, you need to enable the dependent permissions in the same project. | The VPCEndpoint Administrator system role is required for accessing a cluster through a VPC endpoint. Some operations depend on the following permissions:
|
CSS ReadOnlyAccess | System-defined policy | Read-only permissions for CSS. Users with these permissions can only view CSS data. Some functions depend on corresponding permissions. To use certain functions, you need to enable the dependent permissions in global services. | Some operations depend on the following permissions:
|
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 | Y | x | Y |
|
Querying a cluster list | Y | Y | Y |
|
Querying cluster details | Y | Y | Y |
|
Deleting a cluster | Y | x | Y |
|
Restarting a cluster | Y | x | Y |
|
Expanding cluster capacity | Y | x | Y |
|
Adding instances and expanding instance storage capacity | Y | x | Y |
|
Querying tags of a specified cluster | Y | Y | Y |
|
Querying all tags | Y | Y | Y |
|
Loading a custom word dictionary | Y | x | Y | Depends on OBS and IAM permissions |
Querying the status of a custom word dictionary | Y | Y | Y |
|
Deleting a custom word dictionary | Y | x | Y |
|
Automatically setting basic configurations of a cluster snapshot | Y | x | Y | Depends on OBS and IAM permissions |
Modifying basic configurations of a cluster snapshot | Y | x | Y | Depends on OBS and IAM permissions |
Setting the automatic snapshot creation policy | Y | x | Y |
|
Querying the automatic snapshot creation policy | Y | Y | Y |
|
Manually creating a snapshot | Y | x | Y |
|
Querying the snapshot list | Y | Y | Y |
|
Restoring a snapshot | Y | x | Y |
|
Deleting a snapshot | Y | x | Y |
|
Disabling the snapshot function | Y | x | Y |
|
Modifying specifications | Y | x | Y |
|
Scaling in clusters | Y | x | Y |
|