Updated on 2025-09-15 GMT+08:00

Permission Management

If you need to assign different permissions to employees in your enterprise to access your DLI resources, IAM is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, helping you securely access to your public cloud resources.

With IAM, you can use your 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 DLI 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 DLI resources.

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

IAM is a free service. You only pay for the resources in your account. For more information about IAM, see IAM Service Overview.

DLI Permissions

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

DLI 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 DLI, the users need to switch to a region where they have been authorized to use cloud services.

Permission types: Based on the granularity of authorization, they are divided into roles and policies.
  • Roles: A coarse-grained authorization strategy that defines permissions by job responsibility. This strategy offers limited service-level roles for authorization. If one role has a dependency role required for accessing SA, assign both roles to the users. Roles are not suitable 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 strategy is more flexible and ideal for least privilege access. For example, you can grant DLI users only the permissions for managing a certain type of ECSs. For the actions supported by DLI APIs, Permissions Policies and Supported Actions.
Table 1 DLI system permissions

Role/Policy Name

Description

Category

Dependency

DLI FullAccess

Full permissions for DLI.

System-defined policy

This role depends on other roles in the same project.

  • Creating a datasource connection: VPC ReadOnlyAccess
  • Creating yearly/monthly resources: BSS Administrator
  • Creating a tag: TMS FullAccess and EPS EPS FullAccess
  • Using OBS for storage: OBS OperateAccess
  • Creating an agency: Security Administrator

DLI ReadOnlyAccess

Read-only permissions for DLI.

With read-only permissions, you can use DLI resources and perform operations that do not require fine-grained permissions. For example, create global variables, create packages and package groups, submit jobs to the default queue, create tables in the default database, create datasource connections, and delete datasource connections.

System-defined policy

None

Tenant Administrator

Tenant administrator

  • Job execution permissions for DLI resources. After a database or a queue is created, the user can use the ACL to assign rights to other users.
  • Scope: project-level service

System-defined role

None

DLI Service Administrator

DLI administrator.

  • Job execution permissions for DLI resources. After a database or a queue is created, the user can use the ACL to assign rights to other users.
  • Scope: project-level service

System-defined role

None

Table 2 lists the common operations supported by each system policy. You can choose required system policies according to this table.

For details about how to grant permissions using SQL syntax, see Data Permissions List.

Table 2 Common operations supported by each system permission

Resource

Operation

Description

DLI FullAccess

DLI ReadOnlyAccess

Tenant Administrator

DLI Service Administrator

Queue

DROP_QUEUE

Deleting a Queue

×

SUBMIT_JOB

Submitting a job

×

CANCEL_JOB

Terminating a Job

×

RESTART

Restarting a queue

×

GRANT_PRIVILEGE

Granting permissions to a queue

×

REVOKE_PRIVILEGE

Revoking permissions from a queue

×

SHOW_PRIVILEGES

Viewing the queue permissions of other users

×

Database

DROP_DATABASE

Deleting a database

×

CREATE_TABLE

Creating a table

×

CREATE_VIEW

Creating a view

×

EXPLAIN

Explaining SQL statements as an execution plan

×

CREATE_ROLE

Creating a role

×

DROP_ROLE

Deleting a role

×

SHOW_ROLES

Showing a role

×

GRANT_ROLE

Binding a role

×

REVOKE_ROLE

Unbinding a role

×

SHOW_USERS

Showing the binding relationships between all roles and users

×

GRANT_PRIVILEGE

Granting permissions to the database

×

REVOKE_PRIVILEGE

Revoking permissions from the database

×

SHOW_PRIVILEGES

Viewing database permissions of other users

×

DISPLAY_ALL_TABLES

Showing tables in a database

DISPLAY_DATABASE

Showing a database

CREATE_FUNCTION

Creating a function

×

DROP_FUNCTION

Deleting a function

×

SHOW_FUNCTIONS

Showing all functions

×

DESCRIBE_FUNCTION

Showing function details

×

Table

DROP_TABLE

Dropping a table

×

SELECT

Querying tables

×

INSERT_INTO_TABLE

Inserting table data

×

ALTER_TABLE_ADD_COLUMNS

Adding a column

×

INSERT_OVERWRITE_TABLE

Overwriting a table

×

ALTER_TABLE_RENAME

Renaming a table

×

ALTER_TABLE_ADD_PARTITION

Adding partitions to a partitioned table

×

ALTER_TABLE_RENAME_PARTITION

Renaming a table partition

×

ALTER_TABLE_DROP_PARTITION

Deleting partitions from a partitioned table

×

SHOW_PARTITIONS

Showing all partitions

×

ALTER_TABLE_RECOVER_PARTITION

Restoring table partitions

×

ALTER_TABLE_SET_LOCATION

Setting the partition path

×

GRANT_PRIVILEGE

Granting table permissions

×

REVOKE_PRIVILEGE

Revoking table permissions

×

SHOW_PRIVILEGES

Viewing table permissions of other users

×

DISPLAY_TABLE

Showing a table

DESCRIBE_TABLE

Showing table information

×

Elastic resource pool

DROP

Deleting an elastic resource pool

×

RESOURCE_MANAGEMENT

Managing elastic resource pools

×

SCALE

Scaling an elastic resource pool

×

UPDATE

Updating an elastic resource pool

×

CREATE

Creating an elastic resource pool

×

SHOW_PRIVILEGES

Viewing elastic resource pool permissions of other users

×

GRANT_PRIVILEGE

Granting elastic resource pool permissions

×

REVOKE_PRIVILEGE

Revoking elastic resource pool permissions

×

Enhanced datasource connection

BIND_QUEUE

Binding an enhanced datasource connection to a queue

It is only used to grant permissions across projects.

×

×

×

×

You can create custom policies to supplement system-defined policies and implement more refined access control. For details about how to create a custom policy, see Creating a Custom Policy.