Permissions Management

To assign different permissions to employees in your enterprise to access your FunctionGraph 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 your 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 FunctionGraph 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 FunctionGraph resources.

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

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.

Why Is "Insufficient Permission" Displayed After Enterprise Project Authorization?

IAM project/Enterprise project: A custom policy can be applied to IAM projects or enterprise projects or both. Policies that contain actions supporting both IAM and enterprise projects can be assigned to user groups and take effect in both IAM and Enterprise Management. Policies that only contain actions supporting IAM projects can be assigned to user groups and only take effect for IAM. Such policies will not take effect if they are assigned to user groups in Enterprise Management. For details, see Differences Between IAM Projects and Enterprise Projects.

In FunctionGraph, only function resource APIs support enterprise project authorization. For other APIs that support only IAM project authorization:

Click By IAM Project during authorization.
Figure 1 Viewing authorization records by IAM project
When selecting the authorization scope, select Region-specific projects according to the minimum authorization principle.

FunctionGraph Permissions

By default, new IAM users do not have any permissions assigned. You need to add a user to one or more groups, and assign permissions policies to these groups. The user then inherits permissions from the groups it is a member of. This process is called authorization. After authorization, the user can perform specified operations on FunctionGraph based on the permissions.

FunctionGraph is a project-level service deployed and accessed in specific physical regions. To assign FunctionGraph permissions to a user group, specify the scope as region-specific projects and select projects (such as cn-north-1) in relevant regions (such as CN North-Beijing1) 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 FunctionGraph, the users need to switch to a region where they have been authorized to use the FunctionGraph service.

You can grant users permissions by using roles and policies.

Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. This mechanism provides only a limited number of service-level roles for authorization. When using roles to grant permissions, you may 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.

Table 1 lists all the system policies supported by FunctionGraph.

**Table 1** Permissions description
Role/Policy Name	Description	Category	Dependency
FunctionGraph Administrator	This role has the permissions to manage functions, flows, and triggers, and invoke functions. (It will be unavailable soon and therefore not recommended.)	System-defined role	Tenant Guest
FunctionGraph Invoker	This role has the permissions to query functions, flows, triggers, and invoke functions.	System-defined role	N/A
FunctionGraph FullAccess	This policy grants all permissions for FunctionGraph.	System-defined policy	N/A
FunctionGraph ReadOnlyAccess	This policy grants read-only permissions for FunctionGraph.	System-defined policy	N/A
FunctionGraph CommonOperations	This policy grants permissions to query functions and triggers, and invoke functions.	System-defined policy	N/A

If an IAM user granted the FunctionGraph FullAccess permission has no permission to create a certain type of trigger or use a certain function, the relevant service or function does not support fine-grained authentication. In this case, grant the admin permission for this service or function to the user. These services and functions include:

CTS, APIG, and DIS: These do not support fine-grained authentication. Add the admin permission for them.
SMN: This supports fine-grained authentication in some regions. If needed, add the admin permission for this service.
IoTDA: This is a new trigger type and is not covered in FullAccess. When you create an IoTDA trigger, you will be prompted to create an agency and add the iam:agencies:list and iam:agencies:createAgency permissions.
TMS, DNS, BSS, Cloud Eye, EG, and DMS: These are new functions and are not covered in FullAccess. Add the permissions for them as required.

For more information about the permissions required to use these triggers and relevant functions, see Table 2.

**Table 2** Permissions required to use triggers and relevant functions
Trigger/Function	Permission
APIG	apig:groups:get apig:groups:list apig:apis:create apig:apis:delete apig:apis:update apig:apis:publish apig:apis:list apig:apis:get apig:apis:offline apig:apps:list apig:envs:list
APIG (dedicated)	apig:instances:get apig:instances:create apig:instances:update apig:instances:list apig:sharedInstance:operate
CTS	cts:notification:create cts:notification:delete cts:notification:update cts:operation:list cts:tracker:list cts:trace:list
DDS	dds:instance:get dds:instance:list
DIS	dis:streams:list
IoTDA	iotda:routingrules:create iotda:routingrules:delete iotda:routingrules:queryList iotda:routingrules:query iotda:routingactions:create iotda:routingactions:delete iotda:routingactions:query iotda:routingactions:queryList iotda:subscriptions:queryList iotda:rules:modifyStatus iotda:apps:queryList
LTS	lts:groups:create lts:groups:get lts:groups:list lts:groups:put lts:logstreams:delete lts:logstreams:list lts:topics:get lts:subscriptions:create lts:subscriptions:delete lts:subscriptions:put lts:structConfig:create lts:structConfig:get
OBS	obs:bucket:GetBucketLocation obs:bucket:GetBucketNotification obs:bucket:PutBucketNotification obs:bucket:ListBucket
SMN	smn:topic:list smn:topic:update
TMS	tms:predefineTags:list tms:tagValues:list
DNS	dns:recordset:create, dns:recordset:list, dns:recordset:update, dns:zone:create, dns:zone:delete, dns:zone:get, dns:zone:list
BSS	bss:bill:view bss:renewal:view
CES	ces:alarms:get ces:alarms:list ces:alarms:create
DMS	dms:instance:get
EG	eg:subscriptions:get eg:subscriptions:list eg:sources:list eg:sources:get eg:agency:create eg:subscriptions:create eg:subscriptions:delete eg:subscriptions:operate

Table 3 lists the common operations supported by each system-defined policy of FunctionGraph. Please choose proper system-defined policies according to this table.

**Table 3** Common operations supported by each system-defined policy
Operation	FunctionGraph Invoker	FunctionGraph Administrator	FunctionGraph ReadOnlyAccess	FunctionGraph CommonOperations	FunctionGraph FullAccess
Creating functions	×	√	×	×	√
Querying functions	√	√	√	√	√
Modifying functions	×	√	×	×	√
Deleting functions	×	√	×	×	√
Invoking functions	√	√	×	√	√
Querying function logs	√	√	√	√	√
Viewing function metrics	√	√	√	√	√