Help Center> ServiceStage> Service Overview> Permissions Management
View PDF

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 public cloud 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 public cloud 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 more information about IAM, see the 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 need to also 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.

Table 1 Permissions description

Role/Policy Name

Description

Type

Dependencies

ServiceStage FullAccess

Full permissions for ServiceStage.

System-defined policy

None

ServiceStage Development

Developer permissions for ServiceStage, including permissions for operating applications, components, and environments, but excluding permissions for approving and for creating infrastructure.

System-defined policy

None

ServiceStage ReadOnlyAccess

Read-only permissions for ServiceStage.

System-defined policy

None

CSE FullAccess

Administrator permissions for CSE

System-defined policy

None

CSE ReadOnlyAccess

View permissions for CSE

System-defined policy

None

ServiceStage FullAccess has the administrator permissions and is responsible for asset management (involving charging).

ServiceStage Development has the developer permissions and is responsible for application management. However, this role cannot create or delete basic resources (charged).

ServiceStage ReadOnlyAccess has the read-only permissions. If these policies do not meet actual requirements, you can customize policies. For more information, see Creating a Custom Policy.

Table 2 lists the common operations supported by each system-defined policy of ServiceStage. Please choose proper system-defined policies according to this table.

Table 2 Common operations supported by each system policy

Operation

ServiceStage ReadOnlyAccess

ServiceStage Development

ServiceStage FullAccess

CSE ReadOnlyAccess

CSE FullAccess

Creating an application

x

√

√

x

x

Modifying an application

x

√

√

x

x

Querying an application

√

√

√

x

x

Deleting an application

x

√

√

x

x

Creating a component

x

√

√

x

x

Searching for a component

√

√

√

x

x

Deploying a component

x

√

√

x

x

Maintaining a component

x

√

√

x

x

Deleting a component

x

√

√

x

x

Creating a build job

x

√

√

x

x

Modifying a build job

x

√

√

x

x

Querying a build job

√

√

√

x

x

Starting a build job

x

√

√

x

x

Deleting a build job

x

√

√

x

x

Creating a pipeline

x

√

√

x

x

Modifying a pipeline

x

√

√

x

x

Querying a pipeline

√

√

√

x

x

Starting a pipeline

x

√

√

x

x

Cloning a pipeline

x

√

√

x

x

Deleting a pipeline

x

√

√

x

x

Creating repository authorization

x

√

√

x

x

Modifying repository authorization

x

√

√

x

x

Querying repository authorization

√

√

√

x

x

Deleting repository authorization

x

√

√

x

x

Creating a microservice engine

x

x

√

x

√

Maintaining a microservice engine

x

x

√

x

√

Querying a microservice engine

√

√

√

√

√

Deleting a microservice engine

x

x

√

x

√

Registering a microservice

√

√

√

√

√

Configuring a microservice

√

√

√

√

√

Governing a microservice

x

√

√

x

x

SWR does not support fine-grained permissions. Related permissions need to be authorized separately.

Helpful Links