Updated on 2024-01-09 GMT+08:00

IAM

This section describes the IAM permission configurations for all ModelArts functions.

IAM Permissions

If you need to assign different permissions to employees in your enterprise to access your ModelArts resources, Identity and Access Management (IAM) is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, helping you securely access Huawei Cloudcloud resources. If your Huawei accountaccount can meet your requirements and you do not need an IAM account to manage user permissions, skip this chapter.

IAM is a free service. You only pay for the resources in your account.

With IAM, you can control access to specific Huawei Cloudcloud resources. For example, if the software developers in your enterprise need to own permissions to use ModelArts, yet you do not want them to own high-risk operation permissions such as deleting ModelArts, you can grant permissions using IAM to limit their permission on ModelArts.

For details about IAM, see What is IAM?What is IAM?.

Role/Policy-based Authorization

ModelArts supports role/policy-based authorization. By default, new IAM users do not have any permissions. You need to add a user to one or more groups, and assign permissions policies or roles to these groups. Users inherit permissions of the groups to which they are added. This process is called authorization. The users then inherit permissions from the groups and can perform specified operations on cloud services.

ModelArts is a project-level service deployed for specific regions. When you set Scope to Region-specific projects and select the specified projects (for example, ap-southeast-2) in the specified regions (for example, AP-Bangkok), the users only have permissions for APIG resources in the selected projects. If you set Scope to All resources, the users have permissions for APIG resources in all region-specific projects. When accessing ModelArts, the users need to switch to a region where they have been authorized to use cloud services.

Table 1 lists all system-defined policies supported by ModelArts. If preset ModelArts permissions cannot meet your requirements, create a custom policy by referring to Policy Fields in JSON Format.

Table 1 System-defined policies supported by ModelArts

Policy

Description

Type

ModelArts FullAccess

All permissions for ModelArts administrators

System-defined policy

ModelArts CommonOperations

All operation permissions for ModelArts common users, which does not include managing dedicated resource pools.

System-defined policy

ModelArts Dependency Access

Permissions on dependent services for ModelArts

System-defined policy

ModelArts depends on other cloud services. To check or view the cloud services, configure the corresponding permissions on the ModelArts console, as shown in the following table.

Table 2 Roles or policies that are required for performing operations on the ModelArts console

Console Function

Dependency

Role/Policy Required

Data management

Object Storage Service (OBS)

OBS Administrator

Data Lake Insight (DLI)

DLI FullAccess

MapReduce Service (MRS)

MRS Administrator

GaussDB(DWS)

DWS Administrator

Cloud Trace Service (CTS)

CTS Administrator

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

Development environment

OBS

OBS Administrator

Cloud Secret Management Service (CSMS)

CSMS ReadOnlyAccess

CTS

CTS Administrator

Elastic Cloud Server (ECS)

ECS FullAccess

Software Repository for Container (SWR)

SWR Administrator

Scalable File Service (SFS)

SFS Turbo FullAccess

Application Operations Management (AOM)

AOM FullAccess

Key Management Service (KMS)

KMS CMKFullAccess

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

Training management

OBS

OBS Administrator

Simple Message Notification (SMN)

SMN Administrator

CTS

CTS Administrator

SFS Turbo

SFS Turbo ReadOnlyAccess

SWR

SWR Administrator

AOM

AOM FullAccess

KMS

KMS CMKFullAccess

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

Workflow

OBS

OBS Administrator

CTS

CTS Administrator

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

ExeML

OBS

OBS Administrator

CTS

CTS Administrator

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

AI application management

OBS

OBS Administrator

Enterprise Project Management Service (EPS)

EPS FullAccess

CTS

CTS Administrator

SWR

SWR Administrator

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

Service deployment

OBS

OBS Administrator

Cloud Eye Service (CES)

CES ReadOnlyAccess

SMN

SMN Administrator

EPS

EPS FullAccess

CTS

CTS Administrator

Log Tank Service (LTS)

LTS FullAccess

Virtual Private Cloud (VPC)

VPC FullAccess

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

AI Gallery

OBS

OBS Administrator

CTS

CTS Administrator

SWR

SWR Administrator

ModelArts

ModelArts CommonOperations

ModelArts Dependency Access

Dedicated resource pool

CTS

CTS Administrator

Cloud Container Engine (CCE)

CCE Administrator

Bare Metal Server (BMS)

BMS FullAccess

Image Management Service (IMS)

IMS FullAccess

Data Encryption Workshop (DEW)

DEW KeypairReadOnlyAccess

VPC

VPC FullAccess

ECS

ECS FullAccess

SFS

SFS Turbo FullAccess

OBS

OBS Administrator

AOM

AOM FullAccess

ModelArts

ModelArts FullAccess

Billing Center

BSS Administrator

If system-defined policies cannot meet your requirements, you can create a custom policy. For details about the actions supported by custom policies, see ModelArts Resource Permissions.

You can create custom policies in either of the following ways:

  • Visual editor: Select cloud services, actions, resources, and request conditions without the need to know policy syntax.
  • JSON: Create a JSON policy or edit an existing one.

For details, see Creating a Custom Policy. The following lists examples of common ModelArts custom policies.

  • Example 1: Grant permission to manage images.
    {
        "Version": "1.1",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "modelarts:image:register",
                    "modelarts:image:listGroup"
                ]
            }
        ]
    }
  • Example 2: Grant permission to deny creating, updating, and deleting a dedicated resource pool.

    A policy with only "Deny" permissions must be used together with other policies. If the permissions granted to an IAM user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.

    {
        "Version": "1.1",
        "Statement": [
            {
                "Action": [
                    "modelarts:*:*"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "swr:*:*"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "smn:*:*"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "modelarts:pool:create",
                    "modelarts:pool:update",
                    "modelarts:pool:delete"
                ],
                "Effect": "Deny"
            }
        ]
    }
  • Example 3: Create a custom policy containing multiple actions.

    A custom policy can contain actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:

    {
        "Version": "1.1",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "modelarts:service:*"
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "lts:logs:list"
                ]
            }
        ]
    }

Policy Fields in JSON Format

Policy Structure

A policy consists of a version and one or more statements (indicating different actions).

Figure 1 Policy structure

Policy Parameters

The following describes policy parameters. You can create custom policies by specifying the parameters. For details, see Custom Policy Use Cases.

Table 3 Policy parameters

Parameter

Description

Value

Version

Policy version

1.1: indicates policy-based access control.

Statement: authorization statement of a policy

Effect

Whether to allow or deny the operations defined in the action

  • Allow: indicates the operation is allowed.
  • Deny: indicates the operation is not allowed.
    NOTE:

    If the policy used to grant user permissions contains both Allow and Deny for the same action, Deny takes precedence.

Action

Operation to be performed on the service

Format: "Service name:Resource type:Action". Wildcard characters (*) are supported, indicating all options.

Example:

modelarts:notebook:list: indicates the permission to view a notebook instance list. modelarts indicates the service name, notebook indicates the resource type, and list indicates the operation.

View all actions of a service in its API Reference.

Condition

Condition for a policy to take effect, including condition keys and operators

Format: "Condition operator:{Condition key:[Value 1,Value 2]}"

If you set multiple conditions, the policy takes effect only when all the conditions are met.

Example:

StringEndWithIfExists":{"g:UserName":["specialCharacter"]}: The statement is valid for users whose names end with specialCharacter.

Resource

Resources on which a policy takes effect

Format: Service name:<Region>:<Account ID>:Resource type:Resource path. Asterisks (*) are supported for resource type, indicating all resources.

NOTE:

ModelArts authorization does not allow you to specify a resource path.

ModelArts Resource Types

Administrators can specify the scope based on ModelArts resource types. The following table lists the resource types supported by ModelArts:

Table 4 Resource types supported by ModelArts role/policy-based authorization

Resource Type

Description

notebook

Notebook instances in DevEnviron

exemlProject

ExeML projects

exemlProjectInf

ExeML-powered real-time inference service

exemlProjectTrain

ExeML-powered training jobs

exemlProjectVersion

ExeML project version

workflow

Workflow

pool

Dedicated resource pool

network

Networking of a dedicated resource pool

trainJob

Training job

trainJobLog

Runtime logs of a training job

trainJobInnerModel

Preset model

trainJobVersion

Version of a training job (supported by old-version training jobs that will be discontinued soon)

trainConfig

Configuration of a training job (supported by old-version training jobs that will be discontinued soon)

tensorboard

Visualization job of training results (supported by old-version training jobs that will be discontinued soon)

model

Models

service

Real-time service

nodeservice

Edge service

workspace

Workspace

dataset

Dataset

dataAnnotation

Dataset labels

aiAlgorithm

Algorithm for training jobs

image

Image

devserver

Elastic BMS

ModelArts Resource Permissions

For details, see "Permissions Policies and Supported Actions" in ModelArts API Reference.