Cloud Service Engine (CSE)

The Organizations service provides Service Control Policies (SCPs) to set access control policies.

SCPs do not actually grant any permissions to a principal. They only set the permissions boundary for the principal. 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.

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

For details about how to use these elements to create a custom SCP, see Creating an SCP.

Actions

Actions are specific operations that are allowed or denied in an SCP.

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 SCP.
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 SCP statements.
- If this column includes a resource type, you must specify the URN in the Resource element of your 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 SCP 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 following table lists the actions that you can define in SCP statements for CSE.

**Table 1** Supported Actions
Action	Description	Access Level	Resource Type (*: required)	Condition Key
cse:config:upload	Assigning permissions to upload microservice configurations	write	-	g:EnterpriseProjectId
cse:config:download	Assigning permissions to download microservice configurations	write	-	g:EnterpriseProjectId
cse:namespace:list	Assigning permissions to view the namespace resource list	list	-	-
cse:namespace:get	Assigning permissions to view namespaces	read	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:namespace:create	Assigning permissions to create a namespace	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId g:TagKeys
cse:namespace:update	Assigning permissions to modify namespace resources	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:namespace:delete	Assigning permissions to delete a namespace	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:policy:list	Assigning permissions to view the governance policy list	list	-	-
cse:policy:get	Assigning permissions to view governance policies	read	-	-
cse:policy:create	Assigning permissions to create a governance policy	write	-	-
cse:policy:update	Assigning permissions to modify governance policies	write	-	-
cse:policy:delete	Assigning permissions to delete a governance policy	write	-	-
cse:engine:get	Assigning permissions to view engines	read	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:engine:list	Assigning permissions to view the engine list	list	-	-
cse:engine:modify	Assigning permissions to change engine permissions	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:engine:create	Assigning permissions to create an engine	write	-	g:ResourceTag/<tag-key> g:EnterpriseProjectId g:TagKeys
cse:engine:upgrade	Assigning permissions to upgrade engine permissions	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:engine:delete	Assigning permissions to deleting an engine	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:engine:tagResource	Assigning permissions to add engine tags	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:engine:unTagResource	Assigning permissions to delete engine tags	write	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:engine:listTags	Assigning permissions to view all engine tags of a project	list	-	-
cse:engine:listTagsForResource	Assigning permissions to view engine tags	list	engine	g:ResourceTag/<tag-key> g:EnterpriseProjectId
cse:engine:listResourcesByTag	Assigning permissions to query the engine list by tag	list	-	g:TagKeys

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:modify	-
PUT /v2/{project_id}/enginemgr/engines/{engine_id}/config	cse:engine:modify	-
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 SCP applies to. If you specify a resource type for any action in Table 3, the resource URN must be specified in the SCP statements using that action, and the SCP applies only to resources of this type. If no resource type is specified, the Resource element is marked with an asterisk (*) and the SCP 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>