Resource Access Management:How to troubleshoot access permission errors?

Diagnose an access denied error

Both the access denied pop-up message in the console and the AccessDeniedDetail field in the API error response provide error details. Use these details to identify the cause of the access denied error and how to resolve it.

1. Identify the identity of the operator.

   The auth subject field in the console pop-up provides the details of the operator identity. In an API error response, the corresponding fields are in AccessDeniedDetail.

   • Identity Type (AuthPrincipalType in the API response): the type of the operator identity, which is a RAM user, a RAM role, or a federated identity. In the API response, SubUser indicates a RAM user, AssumedRoleUser indicates a RAM role, and Federated indicates a federated identity.

   • Identity Information (AuthPrincipalDisplayName in the API response): the identity identifier. A RAM user provides the UID. A RAM role provides the role name and the role session name, for example, RoleName:RoleSessionName. A federated identity provides the type and the name of the identity provider, for example, saml-provider/AzureAD.

   • Account ID (AuthPrincipalOwnerId in the API response): the UID of the Alibaba Cloud account to which the identity belongs.

2. Identify the missing permission.

   The Action field (AuthAction in the API response) shows the specific action that caused the access denied error. You can use this action to troubleshoot or grant the permission.

   Also check whether the action involves a cross-product dependency when you troubleshoot an access denied error. Some console actions call the APIs of other cloud products at the underlying layer. Such a dependency cannot be inferred from the name of the product where the action entry resides. Use the authorization action in the error details, for example, oos:StartExecution, to determine the permission that is actually missing.

3. Identify the type of policy that affects the permission.

   The Policy Type field (PolicyType in the API response) shows the type of policy that caused the access denied error, including control policy, session policy, trust policy, identity-based policy at the account level, and identity-based policy at the resource group level. For more information, see Policy evaluation process.

   The policy type determines how you adjust the policy:

   • If the action is denied by a control policy (ControlPolicy), contact the management account of your resource directory to grant the permission. A control policy defines the permission boundary for member accounts in a resource directory and takes precedence over the permission decision within an account.

   • If the action is denied by a session policy (SessionPolicy), contact your account administrator to check the session policy that is attached to the AssumeRole call.

   • If the action is denied by a trust policy (AssumeRolePolicy), contact your account administrator to check the trust policy of the assumed RAM role.

   • If the action is denied by an identity-based policy (AccountLevelIdentityBasedPolicy or ResourceGroupLevelIdentityBasedPolicy), contact your account administrator to check the identity-based policies that are granted to the operator identity.

4. Determine whether the access denied error is caused by an implicit deny or an explicit deny.

   • Implicit deny: The error cause indicates that the action is not authorized, and the Denied Type field shows insufficient permissions. The NoPermissionType field in the API response shows ImplicitDeny. In this case, your account administrator must grant you the permission to perform the action by adding the Action to an Allow statement.

   • Explicit deny: The error cause indicates that the action is explicitly denied, and the Denied Type field shows explicit deny. The NoPermissionType field in the API response shows ExplicitDeny. In this case, your account administrator must review the granted permissions and check whether a Deny statement includes the Action.

     If the policy type is a control policy, an explicit deny is also returned when the authorization action is not included in an Allow statement.

After you adjust the permission, repeat the operation that failed. The access denied error should no longer occur. If the error persists, check whether the target product supports RAM-based authorization and review the policy type again.

The permission diagnosis feature is a post-hoc diagnostic tool. You must first make an API call and trigger a denial, and then use the diagnostic message (EncodedDiagnosticMessage) or the RequestId to trace the reason for the denial in reverse. Both values come from the response of the denied API call. This feature does not support simulating the effective permissions of a RAM identity in a resource group without a real call. To pre-check permissions, use one of the following methods:

• To audit the existing permissions of your RAM identities and identify excessive privileges, use the Access Analysis feature to create an analyzer.

• To verify whether the permissions are sufficient before a single call, add the DryRun parameter to the API call.

Console access

Most access denied pop-up messages in the console provide additional error details in addition to the error cause. Read the error details and follow the steps in Diagnose an access denied error to identify the cause and how to resolve it. If the pop-up does not show the error details, reproduce the same operation by calling the API operation by using an SDK or the CLI to obtain AccessDeniedDetail, or use the RequestId of the denied call to trace the reason for the denial on the RAM permission diagnosis page.

In addition, for products that support permission diagnosis, you can click Troubleshooting in the error pop-up to view the error cause and the solution directly.

The Solution section of the permission diagnosis pop-up recommends the system policies that you can attach, such as AliyunRAMFullAccess and AliyunRAMReadOnlyAccess, and provides quick actions such as View Authorization, Create Policy, and Add permission.

API calls

When you call an API operation directly by using an Alibaba Cloud software development kit (SDK), the command-line interface (CLI), or the OpenAPI Developer Portal, the error response provides detailed error information. The following example shows an error response that is returned during debugging in the OpenAPI Developer Portal.

{
  "RequestId": "1090E608-D26F-5A08-BAE3-80D350E9FE20",
  "HostId": "ram.aliyuncs.com",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. resource: acs:ram:*:xxx:user/* Action: ram:ListUsers",
  "Recommend": "https://next.api.alibabacloud.com/troubleshoot?q=NoPermission&product=Ram",
  "AccessDeniedDetail": {
    "PolicyType": "AccountLevelIdentityBasedPolicy",
    "AuthPrincipalOwnerId": "xxx",
    "EncodedDiagnosticMessage": "AQIBIAAAAMDAbkn...jHF4TLvjT8hp17I0RFKObkV4=",
    "AuthPrincipalType": "SubUser",
    "AuthPrincipalDisplayName": "xxx",
    "NoPermissionType": "ExplicitDeny",
    "AuthAction": "ram:ListUsers"
  }
}

The AccessDeniedDetail field in the error response shows the details of the access denied error. Follow the steps in Diagnose an access denied error to identify the cause of the error and how to resolve it.

In addition, for products that support permission diagnosis, you can provide the entire content of the EncodedDiagnosticMessage field to your account administrator. The account administrator can then go to the RAM permission diagnosis page, enter the complete EncodedDiagnosticMessage value, and view the decoded error cause and solution. The decoded result provides the same information as the permission diagnosis pop-up in the console. The account administrator must have the ram:DecodeDiagnosticMessage permission.

Grant cloud product permissions to a RAM user

When a RAM user operates a cloud product such as ECS, OSS, or RDS, the console displays permission denied or an API call returns the Forbidden.RAM error. This usually occurs because the RAM user is not granted the permissions to operate the corresponding cloud product.

Complete this procedure by using the Alibaba Cloud account to which the RAM user belongs. If you are the RAM user that receives the error, send this procedure to your account administrator.

1. Log on to the RAM console with your Alibaba Cloud account.

2. In the left-side navigation pane, choose Identities > Users.

3. In the user list, find the target RAM user and click the logon name of the user.

4. Click the Permissions tab, and then click Grant Permission.

5. In the policy search box, enter the name of the target cloud product, such as ECS. Select the corresponding system policy and confirm the authorization.

The following table lists common cloud products and their corresponding system policies.

For more information about system policies, see Manage permissions for RAM users.

The system policies in the preceding table apply only to the products that support RAM-based authorization. If the access denied error persists after you grant the permissions, check the documentation of the corresponding product to confirm whether the product supports RAM-based authorization.

Insufficient permissions when exporting the instance list in the ECS console

Symptom

A RAM user is granted the ReadOnlyAccess system policy. After the RAM user clicks Export Instance List in the ECS console, an access denied error is still displayed, or the User.NoPermission error is returned. In the error details, the authorization action is oos:StartExecution and the permission decision is insufficient permissions.

Cause

The export instance list feature in the ECS console uses CloudOps Orchestration Service (OOS) for operations management and runs the export task asynchronously, and this action requires the oos:StartExecution permission. ReadOnlyAccess includes only the read-only query permissions on the resources of cloud products and does not include the execution permissions of CloudOps Orchestration Service. Therefore, a RAM user that is granted only read-only permissions cannot trigger the export.

Solution

Attach the AliyunOOSFullAccess system policy to the RAM user, or create a custom policy that grants the oos:StartExecution permission. Then, export the instance list again. This scenario is an example of the cross-product dependency described in Diagnose an access denied error: the missing permission belongs to OOS, not to ECS.