Using IAM Identity Policies to Grant Access to AOM
Identity policy-based authorization provided by IAM let you control access to AOM. With IAM, you can:
- Create IAM users or user groups for personnel based on your enterprise's organizational structure. Each IAM user has their own identity credentials for accessing AOM resources.
- Grant users only the permissions required to perform a given task based on their job responsibilities.
- Entrust an account or a cloud service to perform efficient O&M on your AOM resources.
If your account meets your permissions requirements, you can skip this section.
The following shows the process flow of identity policy-based authorization. For details, see Figure 1.
Prerequisites
Before granting permissions, learn about the AOM system-defined identity policies in Identity Policy-based Authorization. To grant permissions for other services, learn about Service Authorization Reference.
Process Flow
- On the IAM console, create an IAM user or create a user group.
Create a user or user group on the IAM console.
- Attach a system-defined identity policy (AOMReadOnlyPolicy as an example) to the user or user group.
- Log in as the IAM user and verify permissions.
Example Custom Identity Policies
You can create custom identity policies to supplement the system-defined identity policies of AOM. For details about the actions supported in custom identity policies, see Actions Supported by Identity Policy-based Authorization.
To create a custom identity policy, choose either visual editor or JSON.
- Visual editor: Select cloud services, actions, resources, and request conditions. This does not require knowledge of policy syntax.
- JSON: Create a JSON policy or edit an existing one.
For details, see Creating a Custom Identity Policy and Attaching It to a Principal. The following provides examples of custom AOM identity policies.
- Example 1: Grant permission to create alarm rules.
{ "Version": "5.0", "Statement": [ { "Effect": "Allow", "Action": [ "aom:alarmRule:create" ] } ] } - Example 2: Grant permission to deny deletion of application discovery rules.
A policy with only "Deny" permissions must be used together with other policies. If the permissions granted to an IAM user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.
Assume that you want to grant the permissions of the AOM FullAccess policy to a user but want to prevent them from deleting application discovery rules. You can create a custom policy for denying deletion of such rules, and attach this policy together with the AOM FullAccess policy to the user. As an explicit deny in any policy overrides any allows, the user can perform all operations on AOM excepting deleting application discovery rules. Example policy denying deletion of application discovery rules:
{ "Version": "5.0", "Statement": [ { "Effect": "Deny", "Action": [ "aom:discoveryRule:delete" ] } ] } - Example 3: Create a custom policy containing multiple actions.
A custom policy can contain the actions of one or multiple services that are of the same type (project-level). Example policy containing multiple actions:
{ "Version": "5.0", "Statement": [ { "Effect": "Allow", "Action": [ "aom:*:list", "aom:*:get", "apm:*:list", "apm:*:get" ] }, { "Effect": "Allow", "Action": [ "cce:cluster:get", "cce:cluster:list", "cce:node:get", "cce:node:list" ] } ] }
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
