Overview

DLI has a comprehensive permission control mechanism and supports fine-grained authentication through Identity and Access Management (IAM). You can create policies in IAM to manage DLI permissions. You can use both the DLI's permission control mechanism and the IAM service for permission management.

Application Scenarios of IAM Authentication

When using DLI on the public cloud, enterprise users need to manage DLI resources (queues) used by employees in different departments, including creating, deleting, using, and isolating resources. In addition, data of different departments needs to be managed, including data isolation and sharing.

DLI uses IAM for refined enterprise-level multi-tenant 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 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, 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.

For a new user, you need to log in for the system to record the metadata before using DLI.

IAM is free to use, and you only need to pay for the resources in your account. For more information about IAM, see the IAM Service Overview.

If your Huawei Cloud account does not need individual IAM users for permissions management, skip over this section.

DLI System Permissions

Table 1 lists all the system-defined roles and policies supported by DLI.

Type: There are roles and policies.

Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. Only a limited number of service-level roles are available. When using roles to grant permissions, you also need to assign other roles on which the permissions depend. However, roles are not an ideal choice for fine-grained authorization and secure access control.
Policies: A type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization, meeting requirements for secure access control. For example, you can grant DLI users only the permissions for managing a certain type of ECSs.

For details about the system policies you need to perform common SQL operations, see Common Operations Supported by DLI System Policy.

**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

For details, see Creating an IAM User and Granting Permissions, How Do I Create an IAM user? and How Do I Modify a User Policy?

DLI Permission Types

Table 2 lists the DLI service permissions. For details about the resources that can be controlled by DLI, see Table 4.

**Table 2** DLI permission types
Permission Type	Subtype	Console Operations	SQL Syntax
Queue Permissions	Queue management permissions	For details, see Queue Permission Management.	None
Queue Permissions	Queue usage permission	For details, see Queue Permission Management.	None
Data Permissions	Database permissions	For details, see Configuring Database Permissions on the DLI Console and Configuring Table Permissions on the DLI Console.	For details, see Data Permissions List.
	Table permissions
	Column permissions
Job Permissions	Flink job permissions	For details, see Configuring Flink Job Permissions.	None
Package Permissions	Package group permissions	For details, see Configuring Package Permissions.	None
Package Permissions	Package permissions	For details, see Configuring Package Permissions.	None
Datasource Connection Permissions	Datasource connection permissions	For details, see Datasource Authentication Permission Management.	None

Examples

An Internet company mainly provides game and music services. DLI is used to analyze user behaviors and assist decision making.

As shown in Figure 1, the Leader of the Basic Platform Team has applied for a Tenant Administrator account to manage and use public cloud services. The Leader of the Basic Platform Team creates a subaccount with the DLI Service Administrator permission to manage and use DLI, as the Big Data Platform Team requires DLI for data analysis. The Leader of the Basic Platform Team creates a Queue A and assigns it to Data Engineer A to analyze the gaming data. A Queue B is also assigned to Data Engineer B to analyze the music data. Besides granting the queue usage permission, the Leader of the Basic Platform Team grants data (except the database) management and usage permissions to the two engineers.

Figure 1 Granting permissions

The Data Engineer A creates a table named gameTable for storing game prop data and a table named userTable for storing game user data. The music service is a new service. To explore potential music users among existing game users, the Data Engineer A assigns the query permission on the userTable to the Data Engineer B. In addition, Data Engineer B creates a table named musicTable for storing music copyrights information.

Table 3 describes the queue and data permissions of Data Engineer A and Data Engineer B.

**Table 3** Permission description
User	Data Engineer A (game data analysis)	Data Engineer B (music data analysis)
Queues	Queue A (queue usage permission)	Queue B (queue usage permission)
Data (Table)	gameTable (table management and usage permission)	musicTable (table management and usage permission)
Data (Table)	userTable (table management and usage permission)	userTable (table query permission)