Permissions Management
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
By default, new IAM users do not have permissions. To assign permissions to new users, add them to one or more groups, and grant permissions to these groups. The users then inherit permissions from the groups to which the users belong, and can perform specific operations on cloud services.
IAM is a global service that you can access from all regions. You can assign IAM permissions to users in the global service project. In this way, users do not need to switch regions when they access IAM.
You can grant permissions by using roles and policies.
- Roles: A type of coarse-grained authorization mechanism that defines service-level permissions based on user responsibilities. There are only a limited number of roles for granting permissions to users. When you grant permissions using roles, you need to also assign dependency roles.
- 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 secure access control. For example, you can grant ECS users only the permissions required for managing a certain type of ECS resources. Most 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 roles and policies supported by 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 for creating and deleting IAM users. |
System-defined role |
|
Agent Operator |
IAM operator (delegated party) with permissions for switching 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 each system-defined policy or role of IAM. Choose appropriate policies or roles as required.
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 |
Yes |
No |
Yes |
No |
Querying IAM user details |
Yes |
No |
Yes |
Yes |
Modifying IAM user information |
Yes |
No |
Yes |
No |
Querying security settings of IAM users |
Yes |
No |
Yes |
Yes |
Modifying security settings of IAM users |
Yes |
No |
Yes |
No |
Deleting IAM users |
Yes |
No |
Yes |
No |
Creating user groups |
Yes |
No |
Yes |
No |
Querying user group details |
Yes |
No |
Yes |
Yes |
Modifying user group information |
Yes |
No |
Yes |
No |
Adding users to user groups |
Yes |
No |
Yes |
No |
Removing users from user groups |
Yes |
No |
Yes |
No |
Deleting user groups |
Yes |
No |
Yes |
No |
Assigning permissions to user groups |
Yes |
No |
Yes |
No |
Removing permissions of user groups |
Yes |
No |
Yes |
No |
Creating custom policies |
Yes |
No |
Yes |
No |
Modifying custom policies |
Yes |
No |
Yes |
No |
Deleting custom policies |
Yes |
No |
Yes |
No |
Querying permission details |
Yes |
No |
Yes |
Yes |
Creating agencies |
Yes |
No |
Yes |
No |
Querying agencies |
Yes |
No |
Yes |
Yes |
Modifying agencies |
Yes |
No |
Yes |
No |
Switching roles |
No |
Yes |
Yes |
No |
Deleting agencies |
Yes |
No |
Yes |
No |
Granting permissions to agencies |
Yes |
No |
Yes |
No |
Removing permissions of agencies |
Yes |
No |
Yes |
No |
Creating projects |
Yes |
No |
Yes |
No |
Querying projects |
Yes |
No |
Yes |
Yes |
Modifying projects |
Yes |
No |
Yes |
No |
Deleting projects |
Yes |
No |
Yes |
No |
Creating identity providers |
Yes |
No |
Yes |
No |
Importing metadata files |
Yes |
No |
Yes |
No |
Querying metadata files |
Yes |
No |
Yes |
Yes |
Querying identity providers |
Yes |
No |
Yes |
Yes |
Querying protocols |
Yes |
No |
Yes |
Yes |
Querying mappings |
Yes |
No |
Yes |
Yes |
Updating identity providers |
Yes |
No |
Yes |
No |
Updating protocols |
Yes |
No |
Yes |
No |
Updating mappings |
Yes |
No |
Yes |
No |
Deleting identity providers |
Yes |
No |
Yes |
No |
Deleting protocols |
Yes |
No |
Yes |
No |
Deleting mappings |
Yes |
No |
Yes |
No |
Querying quotas |
Yes |
No |
Yes |
No |
Only administrators can manage access keys when access key management is enabled. 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. Access key management is disabled by default.
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) |
Yes |
No |
Yes |
No |
Querying access keys (for other IAM users) |
Yes |
No |
Yes |
Yes |
Modifying access keys (for other IAM users) |
Yes |
No |
Yes |
No |
Deleting access keys (for other IAM users) |
Yes |
No |
Yes |
No |
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