Permission Management

If you need to assign different permissions to employees in your enterprise to access your DataArts Studio 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 Huawei Cloud resources. If your Huawei Cloud account does not require IAM for permissions management, you can skip this section.

IAM can be used free of charge. You pay only for the resources in your account. For more information about IAM, see IAM Service Overview.

With IAM, you can use your Huawei 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, if you want to allow some software developers in your enterprise to use DataArts Studio resources but disallow them to delete workspaces or perform any high-risk operations, you can create IAM users for the software developers and grant them only the permissions required for using DataArts Studio resources.

IAM supports role/policy-based authorization and identity policy-based authorization. The following table describes their differences.

**Table 1** Differences between role/policy-based and identity policy-based authorization
Authorization Model	Core Relationship	Permissions	Authorization Method	Scenario
Role/Policy	User-permission-authorization scope	System-defined roles System-defined policies Custom policies NOTE: DataArts Studio supports system-defined roles (DAYU Administrator, DAYU User, and DataArts Studio User) but does not support system-defined policies and custom policies.	Assigning roles or policies to principals	To authorize a user, you need to add it to a user group first and then specify the scope of authorization. It provides a limited number of condition keys and cannot meet the requirements of fine-grained permissions control. This method is suitable for small- and medium-sized enterprises.
Identity policy	User-policy	System-defined policies Custom identity policies	Assigning identity policies to principals Attaching identity policies to principals	You can authorize a user by attaching an identity policy to it. User-specific authorization and a variety of key conditions allow for more fine-grained permissions control. However, this model can be hard to set up. It requires a certain amount of expertise and is suitable for medium- and large-sized enterprises.

Assume that you want to grant IAM users permission to create ECSs in CN North-Beijing4 and OBS buckets in CN South-Guangzhou. With role/policy-based authorization, the administrator needs to create two custom policies and assign both to the IAM users. With identity policy-based authorization, the administrator only needs to create one custom identity policy and configure the condition key g:RequestedRegion for the policy, and then attach the policy to the users or grant the users the access permissions to the specified regions. Identity policy-based authorization is more flexible than role/policy-based authorization.

Figure 1 shows the permission system. The Role/Policy-based Permissions Management and Identity Policy-based Permissions Management authorization models are supported, but system-defined policies and custom policies in the former model are not supported. Policies, identity policies, and actions in the two authorization models are not interoperable. Figure 2 compares the two models. You are advised to use attribute-based access control (ABAC) for fine-grained authorization to ensure that minimum permissions are assigned. For details about how to assign permissions, see Creating an IAM User and Assigning DataArts Studio Permissions.

If you assign both a role/policy-based permission (DAYU Administrator, DAYU User, or DataArts Studio User) and an identity policy-based permission (DataArtsStudioFullAccessPolicy, DataArtsStudioOperatorPolicy, DataArtsStudioReadOnlyPolicy, or custom identity policies) to an IAM user, the IAM user will have the following permissions:

If both permissions contain the deny action, the deny policy prevails.
The allow actions in the two permissions both take effect.

Figure 1 Permission system
Click to enlarge

Figure 2 Two authorization models
Click to enlarge

Role/Policy-based Permissions Management

By default, new IAM users do not have any permissions. To assign permissions to a user, add the user to one or more groups and assign permissions policies or roles to these groups. The user then inherits permissions from the groups it is a member of After authorization, the users can perform specified operations.

Role/Policy-based authorization is a role-based access control (RBAC) model supported by IAM. It assigns permissions to users based on their roles. It provides two authorization mechanisms: system-defined roles and system-defined policies. Users assigned roles can quickly obtain permissions. This model is inflexible and cannot meet fine-grained permission control requirements. DataArts Studio supports system-defined roles (DAYU Administrator and DAYU User) but does not support system-defined policies or custom policies. DAYU Administrator grants all operation permissions to users. DAYU User grants permissions of instances, workspaces, and dependent services to users. Workspace roles grant operation permissions in a workspace. In this way, fine-grained permission control is available through system-defined roles and workspace roles.

IAM provides the following two authorization mechanisms: Note that DataArts Studio supports only the IAM role-based authorization and does not support the IAM policy-based authorization.

IAM Roles: IAM initially provides a coarse-grained authorization mechanism to define permissions based on users' job responsibilities. This mechanism provides only a limited number of service-level roles for authorization. However, traditional IAM roles are not an ideal choice for fine-grained authorization and secure access control.
IAM Policies: A type of fine-grained authorization mechanism 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.

DataArts Studio is a project-level service deployed 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 DataArts Studio, users need to switch to a region where they are authorized to use cloud services.

DataArts Studio provides two system-defined roles: DAYU Administrator and DAYU User. Workspace roles are granted based on the IAM role DAYU User, as shown in Table 2. Permissions lists the common operations supported by DataArts Studio and the permissions granted to each workspace role. You can select roles as required.

**Table 2** DataArts Studio system-defined roles
Role	Description	Category	Dependency
DAYU Administrator	Instance administrator who has all management permissions on a DataArts Studio instance and its workspaces, permissions of dependent services, and service operation permissions in all workspaces. NOTE: Users assigned the Tenant Administrator role have all permissions for all services except IAM. In other words, users with the Tenant Administrator role can perform all operations in DataArts Studio.	System-defined role	None
DAYU User	Common user who has permissions to view a DataArts Studio instance and its workspaces, and the permissions of dependent services. After assigned a role, a common user has permissions of the role to perform service operations. Workspace roles include the preset admin, developer, deployer, operator, and viewer, and other custom roles. For details about the operation permissions of each role, see Permissions. Admin: This role has all operation permissions in a workspace. You are advised to assign the admin role to the project owner, development owner, and O&M administrator. Developer: This role has permissions to create and manage resources in a workspace. You are advised to assign this role to users who develop and process tasks. Operator: This role has the operation permissions of services such as O&M and scheduling in a workspace, but cannot modify resources or configurations. You are advised to assign this role to users responsible for O&M management and status monitoring. Viewer: This role can view data in a workspace but cannot perform any other operation. You are advised to assign this role to users who only need to view data in a workspace but do not need to perform operations. Deployer: This role is unique to the enterprise mode and has permissions to release task packages in a workspace. In enterprise mode, when a developer submits a script or job version, the system generates a release task. After the developer confirms the release and the deployer approves the release request, the modified job is synchronized to the production environment. Custom roles: If the preset roles cannot meet your requirements, you can create custom roles. You can configure permissions for such roles to meet the principle of least privilege (PoLP).	System-defined role	None
DataArts Studio User	Common user who has permissions to view a DataArts Studio instance and its workspaces, but does not have the permissions of dependent services. After assigned a role and the permissions of dependent services, a common user has permissions of the role to perform service operations. For details about the permissions of dependent services, see Table 4. Workspace roles include the preset admin, developer, deployer, operator, and viewer, and other custom roles. For details about the operation permissions of each role, see Permissions. Admin: This role has all operation permissions in a workspace. You are advised to assign the admin role to the project owner, development owner, and O&M administrator. Developer: This role has permissions to create and manage resources in a workspace. You are advised to assign this role to users who develop and process tasks. Operator: This role has the operation permissions of services such as O&M and scheduling in a workspace, but cannot modify resources or configurations. You are advised to assign this role to users responsible for O&M management and status monitoring. Viewer: This role can view data in a workspace but cannot perform any other operation. You are advised to assign this role to users who only need to view data in a workspace but do not need to perform operations. Deployer: This role is unique to the enterprise mode and has permissions to release task packages in a workspace. In enterprise mode, when a developer submits a script or job version, the system generates a release task. After the developer confirms the release and the deployer approves the release request, the modified job is synchronized to the production environment. Custom roles: If the preset roles cannot meet your requirements, you can create custom roles. You can configure permissions for such roles to meet the principle of least privilege (PoLP).	System-defined role	None

Identity Policy-based Permissions Management

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. After authorization, the users can perform specified operations.

Identity policy-based authorization is the latest ABAC authorization model supported by IAM. Administrators can customize access control policies for fine-grained and flexible permission control. supports identity policy-based authorization. System-defined identity policies provide users with permissions of instances and workspaces. After the permissions of dependent services are configured, the service operation permissions in specific workspaces are provided by workspace roles. In this way, fine-grained permission control is available through system-defined identity policies, dependent service permissions, and workspace roles.

provides the following system-defined identity policies: DataArtsStudioFullAccessPolicy, DataArtsStudioOperatorPolicy, and DataArtsStudioOperatorPolicy. Identity policies only include the permissions of instances and workspaces. Users must also be assigned the permissions of dependent services and workspace roles so that they can perform service operations. In addition, policies define permissions based on APIs. For the actions supported by , see Permissions and Supported Actions.

**Table 3** DataArts Studio system-defined identity policies
Identity Policy Name	Description	Type
DataArtsStudioFullAccessPolicy	Permissions for managing DataArts Studio instances and workspaces, except service operation permissions in workspaces and permissions of dependent services. After users are assigned this policy, they must also be assigned any workspace role and dependent service permissions so that they can perform service operations. For details, see Table 5.	System-defined identity policy
DataArtsStudioOperatorPolicy	Permissions for performing common operations on DataArts Studio instances and workspaces, except service operation permissions in workspaces and permissions of dependent services. After users are assigned this policy, they must also be assigned any workspace role and dependent service permissions so that they can perform service operations. For details, see Table 5.	System-defined identity policy
DataArtsStudioReadOnlyPolicy	Permissions for viewing DataArts Studio instances and workspaces, except service operation permissions in workspaces and permissions of dependent services. After users are assigned this policy, they must also be assigned any workspace role and dependent service permissions so that they can perform service operations. For details, see Table 5.	System-defined identity policy

Table 5 lists the permissions of dependent services. You must grant these permissions to IAM users to whom a system-defined identity policy has been applied. In addition, you must assign workspace roles to IAM users so that they can perform service operations. Workspace roles include the preset admin, developer, deployer, operator, and viewer, and other custom roles. For details about the operation permissions of each role, see Permissions.

Admin: This role has all operation permissions in a workspace. You are advised to assign the admin role to the project owner, development owner, and O&M administrator.
Developer: This role has permissions to create and manage resources in a workspace. You are advised to assign this role to users who develop and process tasks.
Operator: This role has the operation permissions of services such as O&M and scheduling in a workspace, but cannot modify resources or configurations. You are advised to assign this role to users responsible for O&M management and status monitoring.
Viewer: This role can view data in a workspace but cannot perform any other operation. You are advised to assign this role to users who only need to view data in a workspace but do not need to perform operations.
Deployer: This role is unique to the enterprise mode and has permissions to release task packages in a workspace. In enterprise mode, when a developer submits a script or job version, the system generates a release task. After the developer confirms the release and the deployer approves the release request, the modified job is synchronized to the production environment.
Custom roles: If the preset roles cannot meet your requirements, you can create custom roles. You can configure permissions for such roles to meet the principle of least privilege (PoLP).

Roles or Policies for DataArts Studio Console

Table 4 lists the permissions for the services on which DataArts Studio components depend. You are advised to configure the minimum permissions for developers on the services on which DataArts Studio depends. Table 5 lists the permissions.

The DAYU Administrator and DAYU User already have the administrator permissions of dependent services. If the DAYU User role is assigned to a common user or user group, the common user or user group may have more permissions of dependent services than required. To prevent this risk, you can manually delete the permissions of dependent services from the user group after assigning the DAYU User role to the user group, and then assign the minimum permissions of dependent services to the user group.

**Table 4** Roles or policies for the services on which the DataArts Studio console depends on
Console Function	Dependent Service	Role/Policy Required	Function
Management Center	BSS	bss:coupon:view bss:renewal:update bss:discount:view bss:order:view bss:order:pay bss:order:update	Create incremental packages or DataArts Studio instances.
	KMS	kms:cmk:get kms:cmk:list kms:cmk:create kms:cmk:decrypt kms:cmk:encrypt kms:dek:create kms:dek:encrypt kms:dek:decrypt	Encrypt and decrypt data during data connection creation.
	DWS	dws:cluster:list dws:cluster:getDetail dws:openAPICluster:getDetail	Create DWS connections.
	MRS	mrs:cluster:get mrs:cluster:list	Create MRS connections.
	VPC	vpc:publicIps:get vpc:publicIps:list vpc:vpcs:get vpc:subnets:get	Create MRS connections.
	RDS	rds::get rds::list	Create RDS connections.
DataArts Migration	VPC	vpc:publicIps:get vpc:publicIps:list vpc:vpcs:get vpc:vpcs:list vpc:subnets:get vpc:securityGroups:get vpc:firewalls:list vpc:routeTables:list vpc:subNetworkInterfaces:list	Create CDM clusters or DataArts Studio instances.
	ECS	ecs:flavors:get ecs:cloudServerFlavors:get ecs:availabilityZones:list	Create CDM clusters or DataArts Studio instances.
	CDM	cdm:cluster:create	Create CDM clusters.
	KMS	kms:cmk:get kms:cmk:list kms:cmk:create kms:cmk:decrypt kms:cmk:encrypt kms:dek:create kms:dek:encrypt kms:dek:decrypt	Encrypt and decrypt data during data connection creation.
	MRS	mrs:cluster:get mrs:cluster:list mrs:job:get mrs:job:list	Create MRS connections.
	DWS	dws:cluster:list dws:cluster:getDetail dws:openAPICluster:getDetail	Create DWS connections.
	CDM	cdm:cluster:get cdm:cluster:list cdm:link:operate cdm:job:operate	Perform operations on the CDM console.
	CES	ces::get ces::list	View monitoring data in Cloud Eye.
	CSS	css::get css::list	Create CSS connections.
	CloudTable	cloudtable::get cloudtable::list	Create CloudTable connections.
	RDS	rds::get rds::list	Create RDS connections.
	Config	rms:resources:list	Create CDM clusters.
DataArts Factory	OBS	obs:object:GetObject obs:object:PutObject obs:bucket:GetBucketLocation obs:bucket:ListAllMyBuckets obs:bucket:ListBucket obs:bucket:CreateBucket	Run scripts, run jobs, and back up jobs.
	SMN	smn:topic:publish smn:topic:list	Send job notifications.
	KMS	kms:cmk:get kms:cmk:list kms:cmk:create kms:cmk:decrypt kms:cmk:encrypt kms:dek:create kms:dek:encrypt kms:dek:decrypt	Encrypt and decrypt data during data connection creation.
	MRS	mrs:cluster:get mrs:cluster:list mrs:job:submit mrs:job:delete mrs:job:stop mrs:sql:execute mrs:sql:cancel mrs:job:get mrs:job:list	Run the following MRS job nodes: MRS Presto SQL, MRS Spark, MRS Spark Python, MRS Flink Job, and MRS MapReduce MRS Spark SQL and MRS Hive SQL
	DLI	dli:queue:submitJob dli:jobs:create dli:jobs:update dli:jobs:get dli:jobs:list dli:jobs:listAll	Run the following DLI job nodes: DLI SQL and DLI Spark
	OBS	obs:object:GetObject obs:object:PutObject obs:object:DeleteObject obs:bucket:GetBucketLocation obs:bucket:ListAllMyBuckets obs:bucket:ListBucket obs:bucket:ListBucketVersions obs:bucket:CreateBucket obs:bucket:DeleteBucket	Run the following OBS job nodes: Create OBS, Delete OBS, and OBS Manager
	DWS	dws:cluster:list dws:cluster:getDetail dws:openAPICluster:getDetail	Create DWS connections.
	CDM	cdm:cluster:get cdm:cluster:list cdm:job:operate	Run the Agent-related scripts and jobs required by data connections and run CDM jobs: RDS SQL, DWS SQL, Hive SQL, SPARK SQL, Shell, and Python
	CES	ces:metricData:list	Query the CPU usage of the DLI queue on the Overview page.
	GES	ges:graph:access ges:graph:operate ges:graph:list ges:graph:getDetail ges:metadata:create ges:metadata:operate ges:metadata:delete ges:metadata:list ges:metadata:getDetail ges:jobs:list ges:jobs:getDetail	Run the Import GES job node.
	ECS	ecs:servers:list ecs:servers:get ecs:servers:stop ecs:servers:start ecs:cloudServers:list	Run the Open/Close Resource job node and create host connections.
	DLI	dli:queue:submitJob dli:queue:cancelJob dli:group:useGroup dli:group:getGroup dli:group:updateGroup dli:group:deleteGroup dli:group:listAllGroup dli:database:createDatabase dli:database:dropDatabase dli:database:displayDatabase dli:database:displayAllDatabases dli:database:explain dli:database:createView dli:database:createTable dli:database:displayAllTables dli:database:createFunction dli:database:describeFunction dli:database:showFunctions dli:database:dropFunction dli:table:select dli:table:update dli:table:delete dli:table:dropTable dli:table:describeTable dli:table:showCreateTable dli:table:showPartitions dli:table:showSegments dli:table:showTableProperties dli:table:insertOverwriteTable dli:table:insertIntoTable dli:table:compaction dli:table:truncateTable dli:table:alterView dli:table:alterTableRename dli:table:alterTableAddColumns dli:table:alterTableDropColumns dli:table:alterTableChangeColumn dli:table:alterTableSetLocation dli:table:alterTableAddPartition dli:table:alterTableRenamePartition dli:table:alterTableSetProperties dli:table:alterTableRecoverPartition dli:table:alterTableDropPartition dli:column:select dli:jobs:create dli:jobs:delete dli:jobs:start dli:jobs:stop dli:jobs:update dli:jobs:export dli:jobs:get dli:jobs:list dli:jobs:listAll dli:resource:useResource dli:resource:updateResource dli:resource:deleteResource dli:resource:getResource dli:resource:listAllResource dli:variable:update dli:variable:delete	Run DLI jobs/scripts.
	IAM	iam:agencies:listAgencies	Obtain job agencies.
	DIS	DIS Operator DIS User	Run the following DIS job nodes: DIS Stream, DIS Dump, and DIS Client
	SWR	SWR Admin	The image read permission in SWR is required only when a custom image is selected for a DLI Spark node of a job in DataArts Factory. You are advised to add the read permission of the image by referring to User Permissions. You are not advised to directly assign the SWR Admin system role to users because this may result in excessive permissions.
DataArts Catalog	OBS	obs:object:GetObject obs:bucket:GetBucketStorage obs:bucket:GetBucketLocation obs:bucket:ListAllMyBuckets obs:bucket:ListBucket	Collect OBS metadata.
	DIS	dis:streams:list dis:transferTasks:list	Collect DIS metadata.
	CSS	css:cluster:list	Collect CSS metadata.
	GES	ges:graph:list ges:graph:getDetail ges:metadata:list ges:metadata:getDetail	Collect GES metadata.
	DLI	dli:database:displayDatabase dli:database:displayAllDatabases dli:table:select dli:table:describeTable dli:table:showPartitions dli:table:showTableProperties dli:jobs:create dli:jobs:get	Collect DLI metadata and analyze data in summary.
	CDM	cdm:cluster:list	Collect CSS metadata.
DataArts Quality	SMN	smn:topic:publish smn:topic:list	Configure job notifications.
	OBS	obs:object:GetObject obs:object:PutObject obs:bucket:GetBucketLocation obs:bucket:ListAllMyBuckets obs:bucket:ListBucket obs:bucket:CreateBucket	Export quality reports.
	MRS	mrs:job:submit mrs:sql:execute mrs:sql:cancel mrs:job:get	Run MRS quality jobs.
	DLI	dli:queue:submitJob dli:jobs:get dli:jobs:listAll	Run DLI quality jobs.
DataArts Security	DLI	dli:queue:submitJob dli:queue:cancelJob dli:database:displayDatabase dli:database:displayAllDatabases dli:database:displayAllTables dli:table:describeTable dli:jobs:create dli:jobs:stop dli:jobs:get dli:resource:deleteResource dli:resource:getResource dli:resource:listAllResource	Manage DLI permissions.
	DWS	dws:cluster:list dws:cluster:getDetail dws:openAPICluster:getDetail	Manage DWS permissions.
	MRS	mrs:cluster:list mrs:job:submit mrs:job:stop	Manage MRS permissions.
	KMS	kms:cmk:list kms:cmk:encrypt kms:cmk:decrypt	Encrypt and decrypt data using KMS.
	CDM	Any CDM permission, for example, cdm:cluster:get	Manage DWS and MRS permissions.

**Table 5** Minimum permissions for developers on the services on which DataArts Studio depends
Permission Type	Role/Policy-based permissions–system role	Role/Policy-based permissions–custom policy	Role/Policy-based permissions–custom policy
Mandatory	Mandatory	Mandatory	Mandatory
Permission	DIS Operator DIS User (Optional and not recommended) SWR Admin NOTE: The image read permission in SWR is required only when a custom image is selected for a DLI Spark node of a job in DataArts Factory. You are advised to add the read permission of the image by referring to User Permissions. You are not advised to directly assign the SWR Admin system role to users because this may result in excessive permissions.	DataArtsStudio_PermissionsOfDependentServices_global: custom policy for a global dependent cloud service { "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "obs:object:GetObject", "obs:object:PutObject", "obs:object:DeleteObject", "obs:bucket:GetBucketStorage", "obs:bucket:GetBucketLocation", "obs:bucket:ListAllMyBuckets", "obs:bucket:ListBucket", "obs:bucket:ListBucketVersions", "obs:bucket:CreateBucket", "obs:bucket:DeleteBucket", "rms:resources:list", "iam:agencies:listAgencies" ] } ]}	DataArtsStudio_PermissionsOfDependentServices_region: custom policy for a regional dependent cloud service { "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "cdm:cluster:get", "cdm:cluster:list", "cdm:cluster:create", "cdm:link:operate", "cdm:job:operate", "ces::get", "ces::list", "cloudtable::get", "cloudtable::list", "css::get", "css::list", "dis:streams:list", "dis:transferTasks:list", "dli:queue:submitJob", "dli:queue:cancelJob", "dli:table:insertOverwriteTable", "dli:table:insertIntoTable", "dli:table:alterView", "dli:table:alterTableRename", "dli:table:compaction", "dli:table:truncateTable", "dli:table:alterTableDropColumns", "dli:table:alterTableSetProperties", "dli:table:alterTableChangeColumn", "dli:table:showSegments", "dli:table:alterTableRecoverPartition", "dli:table:dropTable", "dli:table:update", "dli:table:alterTableDropPartition", "dli:table:alterTableAddPartition", "dli:table:alterTableAddColumns", "dli:table:alterTableRenamePartition", "dli:table:delete", "dli:table:alterTableSetLocation", "dli:table:describeTable", "dli:table:showPartitions", "dli:table:showCreateTable", "dli:table:showTableProperties", "dli:table:select", "dli:resource:updateResource", "dli:resource:useResource", "dli:resource:getResource", "dli:resource:listAllResource", "dli:resource:deleteResource", "dli:database:explain", "dli:database:createDatabase", "dli:database:dropFunction", "dli:database:createFunction", "dli:database:displayAllDatabases", "dli:database:displayAllTables", "dli:database:displayDatabase", "dli:database:describeFunction", "dli:database:createView", "dli:database:createTable", "dli:database:showFunctions", "dli:database:dropDatabase", "dli:group:useGroup", "dli:group:updateGroup", "dli:group:listAllGroup", "dli:group:getGroup", "dli:group:deleteGroup", "dli:column:select", "dli:jobs:start", "dli:jobs:export", "dli:jobs:update", "dli:jobs:list", "dli:jobs:listAll", "dli:jobs:get", "dli:jobs:delete", "dli:jobs:create", "dli:jobs:stop", "dli:variable:update", "dli:variable:delete", "dws:cluster:list", "dws:cluster:getDetail", "dws:openAPICluster:getDetail", "ecs:servers:get", "ecs:servers:list", "ecs:servers:stop", "ecs:servers:start", "ecs:flavors:get", "ecs:cloudServerFlavors:get", "ecs:cloudServers:list", "ecs:availabilityZones:list", "ges:graph:access", "ges:metadata:create", "ges:jobs:list", "ges:graph:operate", "ges:jobs:getDetail", "ges:graph:getDetail", "ges:graph:list", "ges:metadata:list", "ges:metadata:getDetail", "ges:metadata:delete", "ges:metadata:operate", "kms:cmk:get", "kms:cmk:list", "kms:cmk:create", "kms:cmk:decrypt", "kms:cmk:encrypt", "kms:dek:create", "kms:dek:encrypt", "kms:dek:decrypt", "mrs:cluster:get", "mrs:cluster:list", "mrs:job:get", "mrs:job:list", "mrs:job:submit", "mrs:job:stop", "mrs:job:delete", "mrs:sql:execute", "mrs:sql:cancel", "rds::get", "rds::list", "smn:topic:publish", "smn:topic:list", "vpc:publicIps:list", "vpc:publicIps:get", "vpc:vpcs:get", "vpc:vpcs:list", "vpc:subnets:get", "vpc:securityGroups:get", "vpc:firewalls:list", "vpc:routeTables:list", "vpc:subNetworkInterfaces:list" ] } ]}

Table 5 Minimum permissions for developers on the services on which DataArts Studio depends

Permission Type

Role/Policy-based permissions–system role

Role/Policy-based permissions–custom policy

Mandatory

Mandatory

Permission

DIS Operator
DIS User
(Optional and not recommended) SWR Admin
NOTE:

The image read permission in SWR is required only when a custom image is selected for a DLI Spark node of a job in DataArts Factory.

You are advised to add the read permission of the image by referring to User Permissions. You are not advised to directly assign the SWR Admin system role to users because this may result in excessive permissions.

DataArtsStudio_PermissionsOfDependentServices_global: custom policy for a global dependent cloud service

{    "Version": "1.1",    "Statement": [        {            "Effect": "Allow",            "Action": [                "obs:object:GetObject",                "obs:object:PutObject",                "obs:object:DeleteObject",                "obs:bucket:GetBucketStorage",                "obs:bucket:GetBucketLocation",                "obs:bucket:ListAllMyBuckets",                "obs:bucket:ListBucket",                "obs:bucket:ListBucketVersions",                "obs:bucket:CreateBucket",                "obs:bucket:DeleteBucket",                "rms:resources:list",                "iam:agencies:listAgencies"            ]        }    ]}

DataArtsStudio_PermissionsOfDependentServices_region: custom policy for a regional dependent cloud service

{    "Version": "1.1",    "Statement": [        {            "Effect": "Allow",            "Action": [                "cdm:cluster:get",                "cdm:cluster:list",                "cdm:cluster:create",                "cdm:link:operate",                "cdm:job:operate",                "ces:*:get",                "ces:*:list",                "cloudtable:*:get",                "cloudtable:*:list",		"css:*:get",                "css:*:list",                "dis:streams:list",                "dis:transferTasks:list",                "dli:queue:submitJob",                "dli:queue:cancelJob",                "dli:table:insertOverwriteTable",                "dli:table:insertIntoTable",                "dli:table:alterView",                "dli:table:alterTableRename",                "dli:table:compaction",                "dli:table:truncateTable",                "dli:table:alterTableDropColumns",                "dli:table:alterTableSetProperties",                "dli:table:alterTableChangeColumn",                "dli:table:showSegments",                "dli:table:alterTableRecoverPartition",                "dli:table:dropTable",                "dli:table:update",                "dli:table:alterTableDropPartition",                "dli:table:alterTableAddPartition",                "dli:table:alterTableAddColumns",                "dli:table:alterTableRenamePartition",                "dli:table:delete",                "dli:table:alterTableSetLocation",                "dli:table:describeTable",                "dli:table:showPartitions",                "dli:table:showCreateTable",                "dli:table:showTableProperties",                "dli:table:select",                "dli:resource:updateResource",                "dli:resource:useResource",                "dli:resource:getResource",                "dli:resource:listAllResource",                "dli:resource:deleteResource",                "dli:database:explain",                "dli:database:createDatabase",                "dli:database:dropFunction",                "dli:database:createFunction",                "dli:database:displayAllDatabases",		"dli:database:displayAllTables",                "dli:database:displayDatabase",                "dli:database:describeFunction",                "dli:database:createView",                "dli:database:createTable",                "dli:database:showFunctions",                "dli:database:dropDatabase",                "dli:group:useGroup",                "dli:group:updateGroup",                "dli:group:listAllGroup",                "dli:group:getGroup",                "dli:group:deleteGroup",                "dli:column:select",                "dli:jobs:start",                "dli:jobs:export",                "dli:jobs:update",                "dli:jobs:list",                "dli:jobs:listAll",                "dli:jobs:get",                "dli:jobs:delete",                "dli:jobs:create",                "dli:jobs:stop",		"dli:variable:update",		"dli:variable:delete",                "dws:cluster:list",                "dws:cluster:getDetail",                "dws:openAPICluster:getDetail",                "ecs:servers:get",		"ecs:servers:list",	                "ecs:servers:stop",                "ecs:servers:start",		"ecs:flavors:get",                "ecs:cloudServerFlavors:get",                "ecs:cloudServers:list",                "ecs:availabilityZones:list",                 "ges:graph:access",                "ges:metadata:create",                "ges:jobs:list",                "ges:graph:operate",                "ges:jobs:getDetail",                "ges:graph:getDetail",                "ges:graph:list",                "ges:metadata:list",                "ges:metadata:getDetail",                "ges:metadata:delete",                "ges:metadata:operate",                "kms:cmk:get",                "kms:cmk:list",                "kms:cmk:create",                "kms:cmk:decrypt",                "kms:cmk:encrypt",                "kms:dek:create",                "kms:dek:encrypt",                "kms:dek:decrypt",                "mrs:cluster:get",                "mrs:cluster:list",                "mrs:job:get",                "mrs:job:list",                "mrs:job:submit",                "mrs:job:stop",                "mrs:job:delete",                "mrs:sql:execute",                "mrs:sql:cancel",                "rds:*:get",                "rds:*:list",                "smn:topic:publish",                "smn:topic:list",		"vpc:publicIps:list",                "vpc:publicIps:get",                "vpc:vpcs:get",                "vpc:vpcs:list",                "vpc:subnets:get",                "vpc:securityGroups:get",                "vpc:firewalls:list",                "vpc:routeTables:list",                "vpc:subNetworkInterfaces:list"            ]        }    ]}

Previous topic: Certificates

Next topic: Permissions