STAROps:Cross-account access permission practices

Scenario

Enterprises usually use the platform from a single management account, while production resources are spread across multiple business accounts. An O&M engineer then needs to investigate the logs and monitoring data of a business account directly from a conversation in the management account. By default, a Digital Employee in the management account accesses only the resources of its own account. A cross-account query therefore fails, because the Digital Employee has no credentials for the target account.

This tutorial uses a management account (Account A) and a business account (Account B) as the example. After you complete the configuration, an O&M engineer in Account A can query the SLS and CMS data of Account B in a single conversation, without switching accounts.

Solution architecture

Cross-account access works only when the following three sets of configuration operate together:

• User permissions in Account A — The RAM user in Account A holds the starops:*, cms:*, and log:* operation permissions, and uses ram:PassRole to pass a role to the services identified by operation-platform.aliyuncs.com and cloudmonitor.aliyuncs.com. These permissions are the prerequisite for a user to create and drive a Digital Employee in Account A.

• Cross-account access role in Account B — The RAM role in Account B carries the actual resource access permissions. Its trust policy declares that the operation-platform.aliyuncs.com and cloudmonitor.aliyuncs.com services of Account A can assume the role. Its access policy determines which resources the Digital Employee reads in Account B.

• Digital Employee binding in Account A — The custom Digital Employee in Account A is bound to the role ARN of Account B, and uses sts:AssumeRole to assume that role during a conversation.

  User permissions and Digital Employee access permissions are two independent authorization chains. User permissions determine who operates the platform. Digital Employee access permissions determine which cloud resources a Digital Employee reaches. For the difference between the two, and for the standard templates of each type of access policy, see Permission configuration.

Prerequisites

• Two Alibaba Cloud accounts: a management account (Account A) and a business account (Account B) that holds the SLS and CMS resources you want to query.

• Permissions in Account A to create a RAM user, create an access policy, and attach the policy to the user.

• Permissions in Account B to create a RAM role, create an access policy, and attach the policy to the role.

• The account ID of Account A. You use it both as the trusted entity of the role in Account B and in the trust policy of that role.

• The name of the target Workspace that the Digital Employee is allowed to query.

Permission scope of the sample policies

The sample access policies in this tutorial grant the starops:*, cms:*, and log:* actions with "Resource": "*". These are broad permissions that make the configuration easy to verify. Review the scope before you apply either policy in your own accounts.

For policy templates that narrow the permission scope by role, such as administrator, general O&M engineer, and read-only auditor, see Best practices for custom permission policies.

Step 1: Configure user permissions in Account A

User permissions determine whether a RAM user can create a Digital Employee in Account A, and whether that user can pass the role of Account B to the operation-platform.aliyuncs.com and cloudmonitor.aliyuncs.com services.

1. Log on to the Resource Access Management (RAM) console by using Account A, and create a RAM user, such as xxxxxxxx.

2. Create an access policy, such as starops-read, as described in Create a custom policy. On the Script Editor tab, replace the policy content with the following template.

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "starops:*",
           "cms:*",
           "log:*"
         ],
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": "ram:PassRole",
         "Resource": "*",
         "Condition": {
           "StringEquals": {
             "acs:Service": "operation-platform.aliyuncs.com"
           }
         }
       },
       {
         "Effect": "Allow",
         "Action": "ram:PassRole",
         "Resource": "*",
         "Condition": {
           "StringEquals": {
             "acs:Service": "cloudmonitor.aliyuncs.com"
           }
         }
       }
     ]
   }

   ram:PassRole statements pass the role to operation-platform.aliyuncs.com and to cloudmonitor.aliyuncs.com respectively. If either statement is missing, the Digital Employee cannot assume the role of Account B on the corresponding service side.

   This template applies the broad action scope described in Permission scope of the sample policies.

3. On the details page of the RAM user, attach the access policy that you created in the previous step, as described in Manage RAM user permissions.

Step 2: Create a cross-account access role in Account B

This role is the identity that the Digital Employee uses in Account B. The trust policy controls who assumes the role, and the access policy controls what the role accesses after it is assumed.

You define the trust relationship in two passes. First you create the role with Account A as the trusted entity, and then you replace the trust policy so that only two services of Account A — not every identity in Account A — can assume the role. Complete both passes in the order shown below.

1. Log on to the RAM console by using Account B. In the left-side navigation pane, choose Identities > Roles, and then click Create Role.

2. Set the role type to Alibaba Cloud Account, set the trusted entity name to Other Alibaba Cloud Account, and enter the account ID of Account A.

3. Enter a role name, such as StarOpsCrossAccountRole.

4. Replace the trust policy of the role with the following content, and replace <Account-A-ID> with the account ID of Account A.

   {
     "Statement": [
       {
         "Action": "sts:AssumeRole",
         "Effect": "Allow",
         "Principal": {
           "Service": [
             "<Account-A-ID>@operation-platform.aliyuncs.com",
             "<Account-A-ID>@cloudmonitor.aliyuncs.com"
           ]
         }
       }
     ],
     "Version": "1"
   }

   <Account-A-ID>@operation-platform.aliyuncs.com and <Account-A-ID>@cloudmonitor.aliyuncs.com means that only those two services of Account A assume the role, not every identity in Account A.

5. Create an access policy, such as StarOpsCrossAccountRole, by using the same procedure as in Step 1. On the Script Editor tab, replace the policy content with the following template.

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "starops:*",
           "cms:*",
           "log:*"
         ],
         "Resource": "*"
       }
     ]
   }

   ram:PassRole. The role only reads resources in Account B, and does not pass a role to another service. The action scope is the same broad scope described in Permission scope of the sample policies.

6. Attach the access policy to the custom RAM role that you created in the previous steps, as described in Manage permissions for a RAM role.

7. In the RAM console of Account B, open the details page of the custom role and copy the role ARN. The role ARN is the unique identifier that the Digital Employee of Account A uses to locate and assume the role. You enter it in the next section, when you create the custom Digital Employee.

Step 3: Create a custom Digital Employee in Account A

The custom Digital Employee is the component that runs the cross-account query. Binding it to the role ARN of Account B puts every query it runs under the role identity of Account B.

1. Create a custom Digital Employee in Account A, and bind it to the role ARN that you copied in Step 2.

2. In default rules, limit the Digital Employee to the target Workspace. In a cross-account scenario, the Digital Employee sees more than one Workspace, and this limit keeps queries from reaching an unrelated Workspace.

   The following example restricts the Digital Employee to a single Workspace. Replace xxxxx with the name of the target Workspace.

   # Role definition
   You are a senior consulting assistant for cross-account queries.
   
   # Constraints
   - Query only the resources in Workspace `xxxxx`. Ignore all other Workspaces and never query them.
   
   # Query steps
   1. Confirm the query intent, including the time range, metrics, and keywords. Ask for clarification first if the intent is unclear.
   2. Generate an accurate, executable query statement.
   3. Provide a conclusion and an interpretation of the data.

Step 4: Start the first cross-account conversation

A cross-account conversation does not inherit the context that the page supplies in a same-account conversation. Name the target objects in the question itself.

1. Name the target Workspace explicitly in your question. A cross-account conversation does not inherit the Workspace that is currently selected on the page. Without an explicit Workspace, the Digital Employee first lists all Workspaces and then waits for your confirmation, which lengthens the query path.

2. Name the target entity explicitly in your question.

Differences between cross-account and same-account conversations

Once the configuration is complete, a cross-account conversation behaves differently from a same-account conversation in two respects: