All Products
Search
Document Center

STAROps:Cross-account access permission practices

Last Updated:Sep 20, 2026

Create a custom Digital Employee in a management account and allow it to assume a Resource Access Management (RAM) role in a business account to query and manage Simple Log Service (SLS) and CloudMonitor resources in the business account. This enables resource sharing across accounts and centralized permission control. Before you read this topic, read Permission configuration to learn the basic concepts of the permission system, the differences between user operation permissions and Digital Employee access permissions, and the standard templates for different types of permission policies.

Scenario

Enterprises typically use the STAROps platform from a centralized management account, while production resources are distributed across multiple business accounts. O&M engineers want to troubleshoot logs and monitoring data in business accounts directly from the conversation entry point of the management account. However, a Digital Employee in the management account can access only resources in the current account by default. Cross-account queries therefore fail because credentials for the destination account are unavailable. This topic uses a management account (Account A) and a business account (Account B) to demonstrate an end-to-end cross-account authorization process.

How it works

image

STAROps allows you to create custom Digital Employees. A custom Digital Employee works based on the configured RoleArn. You can configure multiple connectors for a custom Digital Employee, and Alibaba Cloud connectors support cross-account RoleArns.

When a Digital Employee runs, it uses its configured RoleArn to assume a role in another account and obtain permissions to access cloud resources in that account.

Limits

  • To ensure optimal performance, we recommend that you configure no more than 10 cross-account connectors for a Digital Employee.

  • The role in the destination account must have a trust policy that trusts the RoleArn of the Digital Employee. Otherwise, cross-account access cannot be implemented.

Prerequisites

  1. STAROps is activated.

  2. A custom Digital Employee is created and a RoleArn is configured for the Digital Employee.

Configuration procedure

The variables used in this topic are described in the following table.

Variable

Description

Example

{uid-a}

ID of the Alibaba Cloud account to which the Digital Employee belongs

1234567890

{role-a}

ID of the role configured for the Digital Employee.

  • If the default AliyunServiceRolePolicyForSTAROps role is configured, enter aliyunserviceroleforstarops.

aliyunserviceroleforstarops

{uid-b}

ID of the destination Alibaba Cloud account

1800000000

{role-b}

ID of the role in the destination account

starops-cross-account-for-a

Step 1: Create a cross-account access role (Digital Employee role) in Account B

Create a RAM role in the business account (Account B) and allow the role in Account A to assume the RAM role.

Create a RAM role

  1. Log on to the RAM console by using Account B.

  2. Choose Identities > Roles and click Create Role.

  3. Set the role type to Alibaba Cloud Account.

  4. Set the trusted entity name to Other Alibaba Cloud Account and enter the ID {uid-a} of Account A.

  5. Enter the role name {role-b}, such as starops-cross-account-for-a.

Configure the trust policy

On the trust policy page, edit the trust policy based on the following example to trust only {role-a}.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "RAM": "acs:ram::{uid-a}:role/{role-a}"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Grant permissions to the role

Alibaba Cloud supports multiple types of policies for role authorization. For more information, see Manage permissions for a RAM role. Grant permissions based on the task type and the principle of least privilege. For example, you can attach system policies that grant read-only permissions on SLS and CloudMonitor.

Step 2: Create a connector for the Digital Employee in Account A

The built-in CloudMonitor, SLS, and Alibaba Cloud resource connectors of STAROps support cross-account access. The following procedure uses an Alibaba Cloud resource connector as an example. For more information about how to create a connector for a Digital Employee, see System connectors.

1. Choose Settings > Connectors > Resources.

2. Click Add Resource Connection, select Alibaba Cloud Resources, and then click Next.

3. Configure the connection.

  • Connector ID: The unique identifier of the connector. It cannot be modified after the connector is created. The ID must be 1 to 64 characters in length, can contain lowercase letters, digits, and hyphens (-), must start with a letter, and must end with a letter or digit.

  • Name: The name that distinguishes the connection in the list. The name can be up to 128 characters in length.

  • Alibaba Cloud Role: Select Cross-account Role and enter the Role ARN in the acs:ram::{uid-b}:role/{role-b} format. Then, click Check Permissions.

Verify the cross-account connection

After the configuration is complete, use one of the following methods to verify that the cross-account connection takes effect:

  • Method 1: On the Digital Employee configuration page, click the connector and check whether the connection is normal.

  • Method 2: Start a conversation with the Digital Employee and ask it to access the connector. Example: Access connector B and check whether the connection works as expected.

FAQ

Cross-account access works by allowing the Digital Employee role {role-a} to assume the destination role {role-b}. The Check Permissions operation on a connector uses the same authorization chain. If the check fails, open the connector details, view the error code and message, and troubleshoot the issue based on the following sections.

The Role ARN format is invalid, or the error code is AUTH_ROLE_INVALID

We recommend that you copy the Role ARN from the RAM role details page in Account B and paste it into the Role ARN field of the connector. The format is acs:ram::{uid-b}:role/{role-b}. The account segment specifies the destination account ID, and the role segment specifies the role name.

The error code is AUTH_TOKEN_UNAVAILABLE

This error usually indicates an issue with the RoleArn configured for the Digital Employee. Perform the following checks:

  1. Make sure that the current Digital Employee is a custom Digital Employee and that a RoleArn is configured for it.

  2. Make sure that {role-a} exists in Account A. The default service role is acs:ram::{uid-a}:role/aliyunserviceroleforstarops.

  3. Make sure that the trust policy of {role-a} allows STAROps-related services to assume the role.

  4. Make sure that the current RAM user has the ram:PassRole permission on {role-a}.

The error code is AUTH_ASSUME_ROLE_FAILED, or sts:AssumeRole Forbidden is reported

This error usually indicates that the Digital Employee has obtained {role-a} but cannot assume {role-b}. Perform the following checks:

  1. Make sure that the role exists in Account B and that its Role ARN is exactly the same as the value entered for the connector.

  2. Make sure that the Principal in the trust policy of {role-b} is acs:ram::{uid-a}:role/{role-a}. If the default service role is used, replace {role-a} with aliyunserviceroleforstarops.

  3. Make sure that the current RoleArn of the Digital Employee matches {role-a} in the trust policy. If you change the role, update the trust policy accordingly.

  4. Make sure that {role-a} has the sts:AssumeRole permission. You can attach the AliyunSTSAssumeRoleAccess policy to a custom role.

For cross-account access through a connector, the Digital Employee role assumes the destination role. Therefore, set the trusted principal of {role-b} to the Role ARN of the Digital Employee.

The error code is WORKSPACE_NOT_FOUND or PROJECT_NOT_FOUND

The role is assumed, but the selected Workspace or Project cannot be accessed. Make sure that the name and region belong to Account B, grant {role-b} the required read permissions on the corresponding service, and then click Check Permissions again.