Permissions Management
If you need to assign different permissions to employees in your enterprise to access your ServiceStage resources, IAM is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, helping you secure access to your resources.
With IAM, you can use your cloud service account to create IAM users for your employees, and assign permissions to the users to control their access to specific resource types. For example, some software developers in your enterprise need to use ServiceStage resources but must not delete them or perform any high-risk operations. To achieve this result, you can create IAM users for the software developers and grant them only the permissions required for using ServiceStage resources.
If your cloud service account does not need individual IAM users for permissions management, you may skip over this chapter.
IAM can be used free of charge. You pay only for the resources in your account. For details, see IAM Service Overview
ServiceStage Permissions
By default, new IAM users do not have any permissions assigned. You need to add a user to one or more groups, and assign permissions policies to these groups. The user then inherits permissions from the groups it is a member of. This process is called authorization. After authorization, the user can perform specified operations on ServiceStage based on the granted permissions policies.
ServiceStage is a project-level service deployed and accessed in specific physical regions. To assign ServiceStage permissions to a user group, specify the scope as region-specific projects and select projects for the permissions to take effect. If All projects is selected, the permissions will take effect for the user group in all region-specific projects. When accessing ServiceStage, the users need to switch to a region where they have been authorized to use cloud services.
You can grant users permissions by using roles and policies.
- Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. This mechanism provides only a limited number of service-level roles for authorization. When using roles to grant permissions, you also need to assign other roles on which the permissions depend to take effect. However, roles are not an ideal choice for fine-grained authorization and secure access control.
- Policies are a type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization, meeting requirements for secure access control.
Table 1 lists all the system policies supported by ServiceStage. System policies are recommended. System roles are used only for compatibility with existing permission configurations.
Role/Policy Name |
Description |
Type |
Depended System Permissions |
---|---|---|---|
ServiceStage FullAccess |
Full permissions for ServiceStage. |
System-defined policy |
None |
ServiceStage ReadOnlyAccess |
Read-only permissions for ServiceStage. |
System-defined policy |
None |
ServiceStage Developer |
ServiceStage developer, who has permissions for operating applications, components, and environments, but excluding permissions for creating basic resources. |
System-defined policy |
None |
CSE Admin |
Administrator permissions for CSE. |
System-defined policy |
None |
CSE Viewer |
View permissions for CSE. |
System-defined policy |
None |
ServiceStage Administrator |
ServiceStage administrator, who has full permissions for this service. |
System-defined role |
CCE administrator, VPC administrator, SWR administrator, Server administrator, and OBS administrator. |
ServiceStage Operator |
ServiceStage operator, who has the read-only permission for this service. |
System-defined role |
CCE administrator, VPC administrator, SWR administrator, Server administrator, and OBS administrator. |
ServiceStage Developer |
ServiceStage developer, who has full permissions for this service. |
System-defined role |
CCE administrator, VPC administrator, SWR administrator, Server administrator, and OBS administrator. |
If these policies do not meet actual requirements, you can customize policies based on Table 2 and Table 3. For more information, see Creating a Custom Policy.
Operation |
ServiceStage ReadOnlyAccess |
ServiceStage Developer |
ServiceStage FullAccess |
---|---|---|---|
Creating an application |
x |
√ |
√ |
Modifying an application |
x |
√ |
√ |
Querying an application |
√ |
√ |
√ |
Deleting an application |
x |
√ |
√ |
Creating a component |
x |
√ |
√ |
Searching for a component |
√ |
√ |
√ |
Deploying a component |
x |
√ |
√ |
Maintaining a component |
x |
√ |
√ |
Deleting a component |
x |
√ |
√ |
Creating a build job |
x |
√ |
√ |
Modifying a build job |
x |
√ |
√ |
Querying a build job |
√ |
√ |
√ |
Starting a build job |
x |
√ |
√ |
Deleting a build job |
x |
√ |
√ |
Creating a pipeline |
x |
√ |
√ |
Modifying a pipeline |
x |
√ |
√ |
Querying a pipeline |
√ |
√ |
√ |
Starting a pipeline |
x |
√ |
√ |
Cloning a pipeline |
x |
√ |
√ |
Deleting a pipeline |
x |
√ |
√ |
Creating repository authorization |
x |
√ |
√ |
Modifying repository authorization |
x |
√ |
√ |
Querying repository authorization |
√ |
√ |
√ |
Deleting repository authorization |
x |
√ |
√ |
Operation |
CSE Viewer |
CSE Admin |
---|---|---|
Creating a microservice engine |
x |
√ |
Maintaining a microservice engine |
x |
√ |
Querying a microservice engine |
√ |
√ |
Deleting a microservice engine |
x |
√ |
Creating a microservice |
x |
√ |
Querying a microservice |
√ |
√ |
Maintaining a microservice |
x |
√ |
Deleting a microservice |
x |
√ |
Creating microservice configurations |
x |
√ |
Querying microservice configurations |
√ |
√ |
Editing microservice configurations |
x |
√ |
Deleting microservice configurations |
x |
√ |
Creating a microservice governance policy |
x |
√ |
Querying a microservice governance policy |
√ |
√ |
Editing a microservice governance policy |
x |
√ |
Deleting a microservice governance policy |
x |
√ |
Fine-grained permissions
- SWR does not support fine-grained permissions. Related permissions need to be authorized separately.
To use a custom fine-grained policy, log in to the IAM console as an administrator and select the desired fine-grained permissions for ServiceStage and CSE.
- Table 4 describes fine-grained permission dependencies of CSE.
- Table 5 describes fine-grained permission dependencies of ServiceStage.
Permission Name |
Description |
Permission Dependency |
Application Scenario |
---|---|---|---|
cse:engine:list |
Lists all microservice engines. |
None |
Engine list view |
cse:engine:get |
Views engine information. |
cse:engine:list |
Engine details view (supported by only exclusive microservice engines) |
cse:engine:modify |
Modifies an engine. |
|
Engine modification, including enabling or disabling public access, enabling or disabling security authentication, and retrying failed tasks, supported by only exclusive microservice engines |
cse:engine:upgrade |
Upgrades an engine. |
|
Engine upgrade, including upgrading the engine version, supported by only exclusive microservice engines. |
cse:engine:delete |
Deletes an engine. |
|
Engine deletion (supported by only exclusive microservice engines.) |
cse:engine:create |
Creates an engine. |
|
Engine creation, including creating an engine and creating a backup or restoration task, supported by only exclusive microservice engines. |
cse:config:modify |
Modifies configuration and management functions. |
|
Modification on global and governance configurations |
cse:config:get |
Views configuration and management functions. |
|
Service configuration view |
cse:governance:modify |
Modifies the governance center. |
|
Service governance creation and modification |
cse:governance:get |
Views the governance center. |
|
Service governance view |
cse:registry:modify |
Modifies service registry and management. |
|
Service modification |
cse:dashboard:modify |
Modifies the dashboard. |
|
Dashboard modification |
cse:dashboard:get |
Views the dashboard. |
|
Dashboard view |
cse:registry:get |
Views service registry and management. |
|
Service catalog view |
The dashboard does not need to be authenticated but requires registry permissions, because it uses the service catalog function to distinguish services.
Permission Name |
Description |
Permission Dependency |
Application Scenario |
---|---|---|---|
servicestage:app:get |
Views application information. |
servicestage:app:list |
Application information view |
servicestage:app:create |
Creates an application. |
|
Application creation |
servicestage:app:modify |
Updates an application. |
|
Application update |
servicestage:app:delete |
Deletes an application. |
|
Application deletion |
servicestage:app:list |
Views the environment and application list. |
None |
Environment and application list view |
servicestage:environment:create |
Creates an environment. |
|
Environment creation |
servicestage:environment:modify |
Updates an environment. |
|
Environment update |
servicestage:environment:delete |
Deletes an environment. |
|
Environment deletion |
servicestage:assembling:get |
Views the build information. |
servicestage:assembling:list |
Build information view |
servicestage:assembling:create |
Creates a build job. |
|
Build job creation. |
servicestage:assembling:modify |
Modifies a build job. |
|
Build job modification |
servicestage:assembling:delete |
Deletes a build job. |
|
Build job deletion |
servicestage:assembling:list |
Views the build list. |
None |
Build list view |
Helpful Links
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