If you need to assign different permissions to employees in your enterprise to access your AS 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 to your resources.

With IAM, you can create IAM users and assign permissions to the users to control their access to specific resources. For example, you can assign permissions to allow some software developers to use AS resources but disallow them to delete or perform any high-risk operations on the resources.

If your account does not need individual IAM users for permissions management, 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.

AS Permissions

By default, new IAM users do not have any permissions assigned. You need to add them to one or more groups and attach policies or roles to these groups. Users inherit permissions from the groups to which they are added and can perform specified operations on cloud services based on the permissions.

When you grant AS permissions to a user group, set Scope to Region-specific projects and then select projects for the permissions to take effect. If you select All projects, the permissions will take effect for the user group in all region-specific projects. When accessing AS, the users need to switch to a region where they have been authorized to use this 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 also also need to attach any existing role dependencies. 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 AS users only the permissions for managing a certain type of ECSs. Most policies define permissions based on APIs. For the API actions supported by AS, see "Permissions Policies and Supported Actions" in Auto Scaling API Reference.

Table 1 lists all the system policies supported by AS.

**Table 1** System-defined permissions supported by AS
Policy Name	Description	Category	Dependency
AutoScaling FullAccess	Full permissions for all AS resources	System-defined policy	None
AutoScaling ReadOnlyAccess	Read-only permissions for all AS resources	System-defined policy	None
AutoScaling Administrator	Full permissions for all AS resources	System role	The ELB Administrator, CES Administrator, Server Administrator, and Tenant Administrator roles need to be assigned in the same project.

Table 2 lists the common operations supported by each system-defined policy of AS. Select the policies as required.

**Table 2** Common operations supported by each system-defined policy of AS
Operation	AutoScaling FullAccess	AutoScaling ReadOnlyAccess	AutoScaling Administrator
Creating an AS group	√	x	√
Modifying an AS group	√	x	√
Querying details about an AS group	√	√	√
Deleting an AS group	√	x	√
Creating an AS configuration	√	x	√
Creating an AS policy	√	x	√
Creating a bandwidth scaling policy	√	x	√

Permissions Management

AS Permissions