Updated on 2025-11-06 GMT+08:00

Cloud Service Engine CSE

IAM provides system-defined identity policies to define common actions supported by cloud services. You can also create custom identity policies using the actions supported by cloud services for more refined access control.

In addition to IAM, the Organizations service provides Service Control Policies (SCPs) to set access control policies.

SCPs do not actually grant any permissions to an entity. They only set permissions boundaries for the entity. When SCPs are attached to a member account or an organizational unit (OU), they do not directly grant permissions to that member account or OU. Instead, the SCPs just determine what permissions are available for that member account or the member accounts under that OU. The granted permissions can be applied only if they are allowed by the SCPs.

To learn more about how IAM is different from Organizations for access control, see What Are the Differences in Access Control Between IAM and Organizations?

This section describes the elements used by IAM custom identity policies and Organizations SCPs. The elements include actions, resources, and conditions.

Actions

Actions are specific operations that are allowed or denied in an identity policy.

  • The Access Level column describes how the action is classified (List, Read, or Write). This classification helps you understand the level of access that an action grants when you use it in an identity policy.
  • The Resource Type column indicates whether the action supports resource-level permissions.
    • You can use a wildcard (*) to indicate all resource types. If this column is empty (-), the action does not support resource-level permissions and you must specify all resources ("*") in your identity policy statements.
    • If this column includes a resource type, you must specify a URN for the Resource element in your identity policy statements.
    • Required resources are marked with asterisks (*) in the table. If you specify a resource in a statement using this action, then it must be of this type.

    For details about the resource types defined by CSE, see Resources.

  • The Condition Key column contains keys that you can specify in the Condition element of an identity policy statement.
    • If the Resource Type column has values for an action, the condition key takes effect only for the listed resource types.
    • If the Resource Type column is empty (-) for an action, the condition key takes effect for all resources that action supports.
    • If the Condition Key column is empty (-) for an action, the action does not support any condition keys.

    For details about the condition keys defined by CSE, see Conditions.

  • The Alias column lists the policy actions that are configured in identity policies. With these actions, you can use APIs for policy-based authorization. For details, see Policies and Identity Policies.

The following table lists the actions that you can define in identity policy statements for CSE.

Table 1 Supported actions

Action

Description

Access Level

Resource Type (*: Required)

Condition Key

Alias

cse:config:upload

Assigning permissions to upload microservice configurations

write

-

g:EnterpriseProjectId

cse:config:modify

cse:config:download

Assigning permissions to download microservice configurations

write

-

g:EnterpriseProjectId

cse:config:modify

cse:namespace:list

Assigning permissions to view the namespace resource list

list

-

-

cse:namespace:read

cse:namespace:get

Assigning permissions to view namespaces

read

engine

cse:namespace:read

cse:namespace:create

Assigning permissions to create a namespace

write

engine

cse:namespace:write

cse:namespace:update

Assigning permissions to modify namespace resources

write

engine

cse:namespace:write

cse:namespace:delete

Assigning permissions to delete a namespace

write

engine

cse:namespace:write

cse:policy:list

Assigning permissions to view the governance policy list

list

-

-

cse:governance:get

cse:policy:get

Assigning permissions to view governance policies

read

-

-

-

cse:policy:create

Assigning permissions to create a governance policy

write

-

-

cse:governance:modify

cse:policy:update

Assigning permissions to modify governance policies

write

-

-

cse:governance:modify

cse:policy:delete

Assigning permissions to delete a governance policy

write

-

-

cse:governance:modify

cse:engine:get

Assigning permissions to view engines

read

engine

-

cse:engine:list

Assigning permissions to view the engine list

list

-

-

-

cse:engine:backupRecover

Assigning permissions to back up and restore ServiceComb engine data and change backup policies

write

engine

-

cse:engine:associatePublicips

Assigning permissions to bind or unbind a ServiceComb engine to or from a public network

write

engine

-

cse:engine:update

Assigning permissions to modify the ServiceComb engine configuration and system management

write

engine

-

cse:engine:resize

Assigning permissions to change ServiceComb engine specifications

write

engine

-

cse:engine:create

Assigning permissions to create an engine

write

-

-

cse:engine:upgrade

Assigning permissions to upgrade engine permissions

write

engine

-

cse:engine:delete

Assigning permissions to deleting an engine

write

engine

-

cse:engine:tagResource

Assigning permissions to add engine tags

write

engine

cse:engine:modify

cse:engine:unTagResource

Assigning permissions to delete engine tags

write

engine

cse:engine:modify

cse:engine:listTags

Assigning permissions to view all engine tags of a project

list

-

-

cse:engine:list

cse:engine:listTagsForResource

Assigning permissions to view engine tags

list

engine

cse:engine:get

cse:engine:listResourcesByTag

Assigning permissions to query the engine list by tag

list

-

g:TagKeys

cse:engine:list

Each API of CSE usually supports one or more actions. Table 2 lists the actions and dependencies supported by CSE APIs.

Table 2 Actions and dependencies supported by CSE APIs

API

Action

Dependencies

GET /v2/{project_id}/enginemgr/engines/{engine_id}

cse:engine:get

-

PUT /v2/{project_id}/enginemgr/engines/{engine_id}/actions

cse:engine:modify

-

GET /v2/{project_id}/enginemgr/engines/{engine_id}/jobs/{job_id}

cse:engine:get

-

GET /v2/{project_id}/enginemgr/engines

cse:engine:list

-

POST /v1/{project_id}/kie/download

cse:config:download

-

POST /v1/{project_id}/kie/file

cse:config:upload

-

GET /v1/{project_id}/kie/kv

cse:namespace:get

-

POST /v1/{project_id}/kie/kv

cse:namespace:update

-

DELETE /v1/{project_id}/kie/kv

cse:namespace:update

-

PUT /v1/{project_id}/kie/kv/{kv_id}

cse:namespace:update

-

DELETE /v1/{project_id}/kie/kv/{kv_id}

cse:namespace:update

-

GET /v1/{project_id}/nacos/v1/console/namespaces

cse:namespace:get

-

DELETE /v1/{project_id}/nacos/v1/console/namespaces

cse:namespace:delete

-

POST /v1/{project_id}/nacos/v1/console/namespaces

cse:namespace:create

-

PUT /v1/{project_id}/nacos/v1/console/namespaces

cse:namespace:update

-

POST /v2/{project_id}/enginemgr/engines

cse:engine:create

-

GET /v2/{project_id}/enginemgr/engines/{engine_id}

cse:engine:get

-

DELETE /v2/{project_id}/enginemgr/engines/{engine_id}

cse:engine:delete

-

PUT /v2/{project_id}/enginemgr/engines/{engine_id}/resize

cse:engine:resize

-

PUT /v2/{project_id}/enginemgr/engines/{engine_id}/config

cse:engine:update

-

PUT /v2/{project_id}/enginemgr/engines/{engine_id}/upgrade

cse:engine:upgrade

-

GET /v3/{project_id}/govern/governance/{kind}

cse:policy:list

-

POST /v3/{project_id}/govern/governance/{kind}

cse:policy:create

-

DELETE /v3/{project_id}/govern/governance/{kind}/{policy_id}

cse:policy:delete

-

GET /v3/{project_id}/govern/governance/{kind}/{policy_id}

cse:policy:get

-

PUT /v3/{project_id}/govern/governance/{kind}/{policy_id}

cse:policy:update

-

GET /v3/{project_id}/govern/governance/display

cse:policy:list

-

DELETE /v3/{project_id}/govern/route-rule/microservices/{service_name}

cse:policy:delete

-

PUT /v3/{project_id}/govern/route-rule/microservices/{service_name}

cse:policy:update

-

GET /v3/{project_id}/govern/route-rule/microservices/{service_name}

cse:policy:get

-

Resources

A resource type indicates the resources that an identity policy applies to. If you specify a resource type for any action in Table 3, the resource URN must be specified in the identity policy statements using that action, and the identity policy applies only to resources of this type. If no resource type is specified, the Resource element is marked with an asterisk (*) and the identity policy applies to all resources. You can also set condition keys in an SCP to define resource types.

The following table lists the resource types that you can define in SCP statements for CSE.

Table 3 Resource types supported by CSE

Resource Type

URN

namespace

cse:<region>:<account-id>:namespace:<engine-id>/<namespace-id>

policy

cse:<region>:<account-id>:policy:<namespace-id>/<policy-name>

engine

cse:<region>:<account-id>:engine:<engine-id>

Conditions

CSE does not support service-specific condition keys in policies.

It can only use global condition keys applicable to all services. For details, see Global Condition Keys.