Permissions
If you need to assign different permissions for IAM to employees in your organization, 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 resources.
With IAM, you can create IAM users under your account, and assign permissions to these users to control their access to specific resources. For example, you can grant permissions to allow certain project planners in your enterprise to view IAM data but disallow them to perform any high-risk operations, for example, deleting IAM users and projects. For all permissions of the services supported by IAM, see "Permissions".
IAM Permissions
New IAM users do not have any permissions assigned by default. You need to first add them to one or more groups and attach policies or roles to these groups. The users then inherit permissions from the groups and can perform specified operations on cloud services based on the permissions they have been assigned.
IAM is a global service deployed for all regions. When you set the authorization scope to Global services, users have permission to access IAM in all regions.
You can grant permissions by using roles and policies.
- Roles: A coarse-grained authorization strategy provided by IAM to assign permissions based on users' job responsibilities. Only a limited number of service-level roles are available for authorization. Cloud services depend on each other. When you grant permissions using roles, you also need to attach any existing role dependencies. Roles are not ideal for fine-grained authorization and least privilege access.
- Policies: A fine-grained authorization strategy that defines permissions required to perform operations on specific cloud resources under certain conditions. This type of authorization is more flexible and is ideal for least privilege access. For example, you can grant users only permission to manage ECSs of a certain type. A majority of fine-grained policies contain permissions for specific APIs, and permissions are defined using API actions. For the API actions supported by IAM, see "Identity and Access Management API Reference > Permissions Policies and Supported Actions."
Table 1 lists all the system-defined permissions for IAM.
Role/Policy Name |
Description |
Type |
Content |
---|---|---|---|
FullAccess |
Full permissions for all services that support policy-based authorization. Users with these permissions can perform operations on all services. |
System-defined policy |
|
IAM ReadOnlyAccess |
Read-only permissions for IAM. Users with these permissions can only view IAM data. |
System-defined policy |
|
Security Administrator |
IAM administrator with full permissions, including permissions to create and delete IAM users. |
System-defined role |
|
Agent Operator |
IAM operator (delegated party) with permissions to switch roles and access resources of a delegating party. |
System-defined role |
|
Tenant Guest |
Read-only permissions for all services except IAM. |
System-defined policy |
|
Tenant Administrator |
Administrator permissions for all services except IAM. |
System-defined policy |
Table 2 lists the common operations supported by system-defined permissions for IAM.
Tenant Guest and Tenant Administrator are basic roles provided by IAM and do not contain any specific permissions for IAM. Therefore, the two roles are not listed in the following table.
Operation |
Security Administrator |
Agent Operator |
FullAccess |
IAM ReadOnlyAccess |
---|---|---|---|---|
Creating IAM users |
Supported |
Not supported |
Supported |
Not supported |
Querying IAM user details |
Supported |
Not supported |
Supported |
Supported |
Modifying IAM user information |
Supported |
Not supported |
Supported |
Not supported |
Querying security settings of IAM users |
Supported |
Not supported |
Supported |
Supported |
Modifying security settings of IAM users |
Supported |
Not supported |
Supported |
Not supported |
Deleting IAM users |
Supported |
Not supported |
Supported |
Not supported |
Creating user groups |
Supported |
Not supported |
Supported |
Not supported |
Querying user group details |
Supported |
Not supported |
Supported |
Supported |
Modifying user group information |
Supported |
Not supported |
Supported |
Not supported |
Adding users to user groups |
Supported |
Not supported |
Supported |
Not supported |
Removing users from user groups |
Supported |
Not supported |
Supported |
Not supported |
Deleting user groups |
Supported |
Not supported |
Supported |
Not supported |
Assigning permissions to user groups |
Supported |
Not supported |
Supported |
Not supported |
Removing permissions of user groups |
Supported |
Not supported |
Supported |
Not supported |
Creating custom policies |
Supported |
Not supported |
Supported |
Not supported |
Modifying custom policies |
Supported |
Not supported |
Supported |
Not supported |
Deleting custom policies |
Supported |
Not supported |
Supported |
Not supported |
Querying permission details |
Supported |
Not supported |
Supported |
Supported |
Creating agencies |
Supported |
Not supported |
Supported |
Not supported |
Querying agencies |
Supported |
Not supported |
Supported |
Supported |
Modifying agencies |
Supported |
Not supported |
Supported |
Not supported |
Switching roles |
Not supported |
Supported |
Supported |
Not supported |
Deleting agencies |
Supported |
Not supported |
Supported |
Not supported |
Granting permissions to agencies |
Supported |
Not supported |
Supported |
Not supported |
Removing permissions of agencies |
Supported |
Not supported |
Supported |
Not supported |
Creating projects |
Supported |
Not supported |
Supported |
Not supported |
Querying projects |
Supported |
Not supported |
Supported |
Supported |
Modifying projects |
Supported |
Not supported |
Supported |
Not supported |
Deleting projects |
Supported |
Not supported |
Supported |
Not supported |
Creating identity providers |
Supported |
Not supported |
Supported |
Not supported |
Importing metadata files |
Supported |
Not supported |
Supported |
Not supported |
Querying metadata files |
Supported |
Not supported |
Supported |
Supported |
Querying identity providers |
Supported |
Not supported |
Supported |
Supported |
Querying protocols |
Supported |
Not supported |
Supported |
Supported |
Querying mappings |
Supported |
Not supported |
Supported |
Supported |
Updating identity providers |
Supported |
Not supported |
Supported |
Not supported |
Updating protocols |
Supported |
Not supported |
Supported |
Not supported |
Updating mappings |
Supported |
Not supported |
Supported |
Not supported |
Deleting identity providers |
Supported |
Not supported |
Supported |
Not supported |
Deleting protocols |
Supported |
Not supported |
Supported |
Not supported |
Deleting mappings |
Supported |
Not supported |
Supported |
Not supported |
Querying quotas |
Supported |
Not supported |
Supported |
Not supported |
Access key management is disabled by default. When access key management is enabled, only administrators can manage access keys. If IAM users need to create, enable, disable, or delete their own access keys, they need to ask the administrator to disable access key management.
If an IAM user wants to manage the access keys of other IAM users, see Table 3. For example, if IAM user A wants to create an access key for IAM user B, IAM user A must have the Security Administrator or FullAccess permission.
Operation |
Security Administrator |
Agent Operator |
FullAccess |
IAM ReadOnlyAccess |
---|---|---|---|---|
Creating access keys (for other IAM users) |
Supported |
Not supported |
Supported |
Not supported |
Querying access keys (of other IAM users) |
Supported |
Not supported |
Supported |
Supported |
Modifying access keys (for other IAM users) |
Supported |
Not supported |
Supported |
Not supported |
Deleting access keys (for other IAM users) |
Supported |
Not supported |
Supported |
Not supported |
Content of the FullAccess Policy
{ "Version": "1.1", "Statement": [ { "Action": [ "*:*:*" ], "Effect": "Allow" } ] }
Content of the IAM ReadOnlyAccess Policy
{ "Version": "1.1", "Statement": [ { "Action": [ "iam:*:get*", "iam:*:list*", "iam:*:check*" ], "Effect": "Allow" } ] }
Content of the Security Administrator Role
{ "Version": "1.0", "Statement": [ { "Action": [ "iam:agencies:*", "iam:credentials:*", "iam:groups:*", "iam:identityProviders:*", "iam:mfa:*", "iam:permissions:*", "iam:projects:*", "iam:quotas:*", "iam:roles:*", "iam:users:*", "iam:securitypolicies:*" ], "Effect": "Allow" } ] }
Content of the Agent Operator Role
{ "Version": "1.0", "Statement": [ { "Action": [ "iam:tokens:assume" ], "Effect": "Allow" } ] }
Content of the Tenant Guest Role
{ "Version": "1.1", "Statement": [ { "Action": [ "obs:*:get*", "obs:*:list*", "obs:*:head*" ], "Effect": "Allow" }, { "Condition": { "StringNotEqualsIgnoreCase": { "g:ServiceName": [ "iam" ] } }, "Action": [ "*:*:get*", "*:*:list*", "*:*:head*" ], "Effect": "Allow" } ] }
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot