Help Center/ ServiceStage/ Service Overview/ Permissions Management
Updated on 2024-12-16 GMT+08:00

Permissions Management

If you need to grant your enterprise personnel permission to access your ServiceStage resources, use Identity and Access Management (IAM). IAM provides identity authentication, fine-grained permissions management, and access control. IAM helps you secure access to your cloud resources.

With IAM, you can create IAM users and grant them permission to access only specific resources. For example, if you want some software developers in your enterprise to be able to use ServiceStage resources but do not want them to be able to delete ServiceStage resources or perform any other high-risk operations, you can create IAM users and grant permission to use ServiceStage resources but not permission to delete them.

If your cloud account does not require individual IAM users for permissions management, you can skip this section.

IAM is free of charge. You pay only for the resources in your account. For details, see IAM Service Overview

System Permissions

New IAM users do not have any permissions assigned by default. You need to first add them to one or more groups and then 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.

ServiceStage is a project-level service deployed for specific 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 the authorized region.

You can grant permissions by using roles and policies.

  • Roles: A coarse-grained authorization strategy that defines permissions by job responsibility. Only a limited number of service-level roles are available for authorization. When you grant permissions using roles, you also need to attach any existing role dependencies. Roles are not ideal for fine-grained authorization and least privilege access.
  • Policies: A fine-grained authorization strategy that defines permissions required to perform operations on specific cloud resources under certain conditions. This type of authorization is more flexible and is ideal for least privilege access.

Table 1 lists all the system-defined policies for ServiceStage. System policies are recommended. System roles are used only for compatibility with existing permission configurations.

Table 1 ServiceStage system permissions

Role/Policy Name

Description

Type

Dependency

ServiceStage FullAccess

Full permissions for ServiceStage.

System-defined policy

None

ServiceStage ReadOnlyAccess

Read-only permissions for ServiceStage.

System-defined policy

None

ServiceStage Development

ServiceStage developer,

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

System-defined policy

None

CSE FullAccess

Administrator permissions for microservice engines.

System-defined policy

None

CSE ReadOnlyAccess

View permissions for microservice engines.

System-defined policy

None

ServiceStage Administrator

ServiceStage administrator, who has full permissions for this service.

System-defined role

Permissions to create Tenant Guest, Server Administrator, CCE Administrator, , and APM Administrator.

ServiceStage Operator

ServiceStage operator, who has the read-only permission for this service.

System-defined role

Tenant Guest

ServiceStage Developer

ServiceStage developer, who has full permissions for this service but does not have the permission for creating infrastructure.

System-defined role

Tenant Guest

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. √: supported; x: not supported.

Table 2 Common ServiceStage operations supported by each system policy

Operation

ServiceStage ReadOnlyAccess

ServiceStage Development

ServiceStage FullAccess

Create an application

x

Modify an application

x

Query an application

Delete an application

x

Create a component

x

Search for a component

Deploy a component

x

Maintain a component

x

Delete a component

x

Create a build job

x

Modify a build job

x

Query a build job

Start a build job

x

Delete a build job

x

Create a pipeline

x

Modify a pipeline

x

Query a pipeline

Start a pipeline

x

Clone a pipeline

x

Delete a pipeline

x

Create repository authorization

x

Modify repository authorization

x

Query repository authorization

Delete repository authorization

x

Table 3 Common CSE operations supported by each system policy

Operation

CSE ReadOnlyAccess

CSE FullAccess

Create a microservice engine

x

Maintain a microservice engine

x

Query a microservice engine

Delete a microservice engine

x

Create a microservice

x

Query a microservice

Maintain a microservice

x

Delete a microservice

x

Create microservice configurations

x

Query microservice configurations

Edit microservice configurations

x

Delete microservice configurations

x

Create a microservice governance policy

x

Query a microservice governance policy

Edit a microservice governance policy

x

Delete a microservice governance policy

x

Fine-grained Permissions

  • SWR does not support fine-grained permissions. Related permissions need to be authorized separately.
  • When an exclusive microservice engine is created and its Billing Mode is set to Yearly/monthly:
    • If you do not pay for orders, you must have the BSS Operator permission (queries cost analysis, budget details, and cost tags in the Cost Center).
    • If you pay for orders, you must have the BSS Administrator permission (performs all operations in the Cost Center).

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.
Table 4 Fine-grained permission dependencies of CSE

Permission Name

Description

Dependencies

Scenario

cse:engine:list

List all microservice engines

None

View engine list

cse:engine:get

View engine information

cse:engine:list

View engine details (supported by only exclusive microservice engines)

cse:engine:modify

Modify an engine

  • cse:engine:list
  • cse:engine:get

Modify an engine, including enabling or disabling public access, enabling or disabling security authentication, and retrying failed tasks, supported by only exclusive microservice engines

cse:engine:upgrade

Upgrade an engine

  • cse:engine:list
  • cse:engine:get

Engine upgrade, including upgrading the engine version, supported by only exclusive microservice engines.

cse:engine:delete

Delete an engine

  • cse:engine:list
  • cse:engine:get
  • vpc:ports:get
  • vpc:ports:delete

Delete an engine (supported by only exclusive microservice engines)

cse:engine:create

Create an engine

  • cse:engine:get
  • cse:engine:list
  • ecs:cloudServerFlavors:get
  • vpc:vpcs:get
  • vpc:vpcs:list
  • vpc:subnets:get
  • vpc:ports:get
  • vpc:ports:create

Create an engine, including creating an engine and creating a backup or restoration task, supported by only exclusive microservice engines

cse:config:modify

Modify configuration management

  • cse:engine:list
  • cse:engine:get
  • cse:config:get

Modify global and governance configurations

cse:config:get

View configuration and management functions

  • cse:engine:list
  • cse:engine:get

View service configurations

cse:governance:modify

Modify the governance center

  • cse:engine:list
  • cse:engine:get
  • cse:config:get
  • cse:config:modify
  • cse:registry:get
  • cse:registry:modify
  • cse:governance:get

Create and modify a governance policy

cse:governance:get

View the governance center

  • cse:engine:list
  • cse:engine:get
  • cse:config:get
  • cse:registry:get

View service governance

cse:registry:modify

Modify service registry and management

  • cse:engine:list
  • cse:engine:get
  • cse:registry:get

Modify a service

cse:dashboard:modify

Modify dashboard management

  • cse:engine:list
  • cse:engine:get
  • cse:registry:get
  • cse:dashboard:get
  • cse:registry:modify

Modify dashboard

cse:dashboard:get

View dashboard management

  • cse:engine:list
  • cse:engine:get
  • cse:registry:get

View dashboard

cse:registry:get

View service registry and management

  • cse:engine:list
  • cse:engine:get

View service catalog

The dashboard does not need to be authenticated but requires registry permissions, because it uses the service catalog function to distinguish services.

Table 5 Fine-grained permission dependencies of ServiceStage

Permission Name

Description

Dependencies

Scenario

servicestage:app:get

View application information

servicestage:app:list

View application information

servicestage:app:create

Create an application

  • servicestage:app:get
  • servicestage:app:list
  • servicestage:assembling:get
  • servicestage:assembling:list
  • servicestage:assembling:create

Create an application

servicestage:app:modify

Update an application

  • servicestage:app:get
  • servicestage:app:list
  • servicestage:assembling:get
  • servicestage:assembling:list
  • servicestage:assembling:modify

Update an application

servicestage:app:delete

Delete an application

  • servicestage:app:get
  • servicestage:app:list
  • servicestage:assembling:delete

Delete an application

servicestage:app:list

View the environment and application list

None

View the environment and application list

servicestage:environment:create

Create an environment

  • servicestage:app:get
  • servicestage:app:list

Create an environment

servicestage:environment:modify

Update an environment

  • servicestage:app:get
  • servicestage:app:list

Update an environment

servicestage:environment:delete

Delete an environment

  • servicestage:app:get
  • servicestage:app:list

Delete an environment

servicestage:pipeline:get

View pipeline information

  • servicestage:pipeline:list
  • servicestage:assembling:get
  • servicestage:assembling:list

View pipeline information

servicestage:pipeline:create

Create a pipeline

  • servicestage:pipeline:list
  • servicestage:pipeline:get
  • servicestage:assembling:create
  • servicestage:assembling:get
  • servicestage:assembling:list

Create a pipeline

servicestage:pipeline:modify

Modify a pipeline

  • servicestage:pipeline:get
  • servicestage:pipeline:list
  • servicestage:assembling:modify
  • servicestage:assembling:get
  • servicestage:assembling:list

Modify a pipeline

servicestage:pipeline:delete

Delete a pipeline

  • servicestage:pipeline:get
  • servicestage:pipeline:list
  • servicestage:assembling:get
  • servicestage:assembling:list
  • servicestage:assembling:delete

Delete a pipeline

servicestage:pipeline:list

View the pipeline list

  • servicestage:assembling:get
  • servicestage:assembling:list

View the pipeline list

servicestage:pipeline:execute

Execute a pipeline

  • servicestage:pipeline:get
  • servicestage:pipeline:list
  • servicestage:assembling:modify
  • servicestage:assembling:get
  • servicestage:assembling:list
  • servicestage:app:get
  • servicestage:app:list
  • servicestage:app:modify

Execute a pipeline

servicestage:assembling:get

View the build information

servicestage:assembling:list

View the build information

servicestage:assembling:create

Create a build job

  • servicestage:assembling:get
  • servicestage:assembling:list

Create a build job

servicestage:assembling:modify

Modify a build job

  • servicestage:assembling:get
  • servicestage:assembling:list

Modify a build job

servicestage:assembling:delete

Delete a build job

  • servicestage:assembling:get
  • servicestage:assembling:list

Delete a build job

servicestage:assembling:list

View the build list

None

View the build list

Roles/Policies Dependencies of ServiceStage Console

To grant an IAM user the permissions to view or use resources of other cloud services on the ServiceStage console, you must first grant the ServiceStage Administrator, ServiceStage FullAccess, or ServiceStage ReadOnlyAccess policy to the user group to which the user belongs and then grant the dependency policies listed in Table 6 to the user. These dependency policies will allow the IAM user to access resources of other cloud services.

Table 6 Roles/Policies dependencies of ServiceStage console

Console Function

Dependent Services

Policy/Role Required

  • Dashboard
  • Alarms
  • O&M and monitoring

Application Operations Management (AOM)

  • An IAM user with the ServiceStage Administrator permission assigned can use this function only after the AOM FullAccess permission is assigned.
  • IAM users with IAM ReadOnlyAccess, ServiceStage FullAccess, or ServiceStage ReadOnlyAccess assigned can directly use this function.

Performance management

Application Performance Management (APM)

To use a Java probe, you must have the AOM FullAccess and APM FullAccess permissions assigned.

Component management

Auto Scaling (AS)

To use AS resources to deploy components in the VM environment, you must have the AutoScaling FullAccess permissions assigned.

Cloud Container Engine (CCE)

To use CCE resources to deploy components in the container environment, you must have the CCE FullAccess permissions assigned.

Elastic Cloud Server (ECS)

To use ECS resources to deploy components in the VM environment, you must have the ECS ReadOnlyAccess permissions assigned.

Object Storage Service (OBS)

If the component to be deployed comes from the software package stored in OBS, you must have the OBS ReadOnlyAccess permissions assigned.

Microservice engine

Cloud Service Engine (CSE)

To bind CSE to microservice components for service registration, service governance, and configuration management, you must have the CSE FullAccess permissions assigned.

Distributed cache

Distributed Cache Service (DCS)

To bind DCS to a component deployed in a container environment to read environment variables to obtain distributed cache information during application running, you must have the DCS ReadOnlyAccess permissions assigned.

Data storage

EVS

If the components deployed in the container environment need to use EVS disks to store data, you must have the EVS ReadOnlyAccess permissions assigned.

SFS

If components deployed in a container environment need to use SFS to store data, you must have the SFS Turbo ReadOnlyAccess permissions assigned.

OBS

If components deployed in a container environment need to store data in object storage mode, you must have the OBS ReadOnlyAccess permissions assigned.

Cloud database

Relational Database Service (RDS)

To bind RDS to components deployed in a container environment for persistent storage of application data, you must have the RDS ReadOnlyAccess permissions assigned.

  • Intra-VPC access of components
  • Domain name access of components

Elastic Load Balance (ELB)

To set intra-VPC access or domain name access for a component to use its services, you must have the ELB ReadOnlyAccess permissions assigned.

Public network access of components

NAT Gateway

To set NAT public network access for a component to use its services, you must have the NAT ReadOnlyAccess permissions assigned.

Elastic IP (EIP)

To set EIP public network access for a component to use its services, you must have the EIP ReadOnlyAccess permissions assigned.

Elastic Load Balance (ELB)

To set ELB public network access for a component to use its services, you must have the ELB ReadOnlyAccess permissions assigned.

Component logs

Log Tank Service (LTS)

To interconnect with LTS to view, search for, and export LTS logs for troubleshooting and resolving problems that occur during component running, you must have the LTS FullAccess permissions assigned.

Threshold rules

Simple Message Notification (SMN)

To enable SMN to send threshold alarm messages generated by components deployed in a container environment to users, you must have the SMN ReadOnlyAccess permissions assigned.

Image repositories

SoftWare Repository for Container (SWR)

If the components deployed in the container environment come from the image package stored in SWR, you must have the SWR FullAccess permissions assigned.

Tag management

Tag Management Service (TMS)

To use TMS to set tags for managed objects such as components for management and selection, you must have the TMS ReadOnlyAccess permissions assigned.

Environment management

Virtual Private Cloud (VPC)

A VPC is used to isolate basic resources, such as computing, network, and middleware resources, used for component deployment and running in the same virtual network environment during environment creation. The VPC ReadOnlyAccess permission needs to be set.