Updated on 2023-01-13 GMT+08:00

Permissions Management

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

With IAM, you can use your account to create IAM users for your employees, and assign permissions to control their access to specific resource types. For example, some software developers in your enterprise need to use SA resources but must not delete them or perform any high-risk operations. To this end, you can create IAM users for the software developers and grant them only the permissions required for using SA resources.

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

SA Permissions

By default, new IAM users do not have any permissions assigned. You can add a user to one or more groups to allow them to inherit the permissions from the groups to which they are added.

You can create IAM users in any region. SA is a global service for all geographic regions. SA permissions are assigned to IAM users in the global project, so IAM users can access SA in any region without having to switch over among regions.

You can grant users permissions by using roles and policies.

  • Roles: A type of coarse-grained authorization mechanism that defines permissions related to users responsibilities. Only a limited number of service-level roles for authorization are available. If one role has a dependency role required for accessing SA, assign both roles to the users. Roles are not ideal 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 and meets secure access control requirements. For example, you can grant SA users only the permissions for managing a certain type of resources. For the API actions supported by SA, see SA Permissions and Supported Actions.

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

Table 1 System-defined permissions supported by SA

Policy Name

Description

Type

Dependency

SA FullAccess

All permissions for SA

System-defined policy

None

SA ReadOnlyAccess

Read-only permission for SA. Users with the read-only permission can only query SA information but cannot perform configuration in SA.

System-defined policy

None

Currently, the SA FullAccess or SA ReadOnlyAccess permission can be used only when you have the Tenant Guest permission. The details are as follows:

  • Configure all SA permissions: SA FullAccess and Tenant Guest.

    To use SA Resource Manager and Baseline Inspection, configure the following permissions:

  • Configure SA read-only permissions: Configure SA ReadOnlyAccess and Tenant Guest.