Permission configuration
This topic describes the STAROps permission model, typical configuration paths, and permission documentation navigation.
In STAROps, users can initiate conversations with Digital Employees, query data, run Long-Term Missions, and manage Skills or MCP services. Permission configuration must control both of the following:
Who can use and manage STAROps.
What data, resources, and O&M capabilities Digital Employees can access at runtime.
To quickly complete configuration, see Quick start: Configure STAROps permissions. To create custom Digital Employees, see Digital Employee permission configuration. To configure inspections, reports, alert analysis, and other Long-Term Missions, see Mission permission configuration.
Target audience
This topic applies to RAM users who configure Digital Employee RAM roles for custom Digital Employees.
If you use an Alibaba Cloud account (primary account), the account has built-in administrative permissions for all resources and does not require additional user permission configuration. In production environments, we recommend that you use RAM users and grant permissions based on job responsibilities to avoid using the primary account for daily O&M.
If you use a RAM user, the primary account or a RAM administrator must complete the authorization. Common authorization targets include:
STAROps administrator: Configures Digital Employees, Long-Term Missions, Skills, MCP services, and permission policies.
O&M user: Initiates conversations with Digital Employees, views sessions, tasks, and reports.
Security administrator: Defines Digital Employee RAM roles, PassRole scope, least-privilege policies, and audit boundaries.
Read-only auditor: Views Digital Employees, sessions, Long-Term Missions, and artifacts without modifying configurations.
STAROps permission model
The STAROps permission model involves the following key elements:
Digital Employees: Divided into built-in employees and custom employees. Built-in employees inherit the caller's account permissions. Custom employees use RAM role permissions.
Alibaba Cloud accounts: Divided into primary accounts and RAM users. RAM user permissions must be configured.
RAM roles: Custom Digital Employees are bound to RAM roles. RAM role permissions control data access (CMS/ARMS/SLS/others) and resource access (cloud resources/other resources).
Other STAROps resources: Conversations, Long-Term Missions, reports, MCP, Skills, and more.
PassRole permissions: Control whether a user can pass a specific Digital Employee RAM role to the STAROps service.
Traditional cloud service permissions determine whether a user can call a specific API operation. STAROps also needs to determine which identity a Digital Employee uses to access data or perform actions at runtime.
STAROps permission configuration involves two objects:
Configuration object | Configuration content | Purpose |
User (primary account or RAM user) | STAROps operation permissions (Digital Employees and other resources), ram:PassRole, and data viewing permissions as needed | Controls whether the user can use and manage Digital Employees, sessions, Long-Term Missions, reports, Skills, and MCP services, and whether the user can pass a Digital Employee RAM role to STAROps |
Digital Employee RAM role | Trust policy, data access permissions, resource access permissions | Controls what data and resources a custom Digital Employee can access at runtime |
When using built-in employees, you mainly configure user permissions. When using custom Digital Employees, you must configure both user permissions and Digital Employee RAM role permissions.
How the Digital Employee type determines permission behavior
STAROps Digital Employees are divided into built-in employees and custom Digital Employees. The two types have different permission sources.
Comparison item | Built-in employee | Custom Digital Employee |
Runtime identity | Not bound to a separate Digital Employee RAM role | Bound to a Digital Employee RAM role, identified by RoleArn |
Permission source | Inherits caller account permissions, limited by built-in capability boundaries | Runtime access scope is determined by the Digital Employee RAM role permission policy |
PassRole requirement | PassRole configuration is not required for built-in employees | PassRole is required when conversing with the Digital Employee |
Extensibility | Limited capabilities | Can be extended with Skills, MCP, AliyunCLI, and other capabilities |
Use case | Quick trial, controlled Q&A, lightweight queries | Business-line isolation, enterprise data integration, dedicated O&M expert configuration |
Built-in employees are restricted employees preset by STAROps. Custom Digital Employees use a Digital Employee RAM role to carry runtime permissions, regardless of whether you select a service-linked role or manually create a custom role. When creating a custom Digital Employee, you can select the service-linked role AliyunServiceRoleForSTAROps (corresponding to RAM role AliyunServiceRoleForSTAROps) to quickly obtain read permissions for observability data sources, including SLS, ARMS, and CMS. This service-linked role does not include permissions for cloud service updates or resource changes.
Configure user permissions
A user can be a primary account or a RAM user. In production environments, we recommend that you use RAM users and grant permissions based on job responsibilities.
User permissions control what operations a user can perform in STAROps. Common capabilities include:
View the Digital Employee list and details.
Create, update, and delete custom Digital Employees.
Initiate sessions, and view and manage session records.
Create, view, update, and delete Long-Term Missions.
View Long-Term Mission artifacts and reports.
Manage Digital Employee Skills, MCP services, and tool configurations.
View or configure quotas, usage, and other operational information.
User permissions only control whether a user can operate STAROps resources. They do not represent the data access permissions of Digital Employees at runtime.
Configure PassRole for custom Digital Employees
ram:PassRole is granted to users to control whether a user can pass a specific Digital Employee RAM role to the STAROps service.
When a user creates, updates, or uses a custom Digital Employee that is bound to a Digital Employee RAM role, the following conditions must all be met:
The user has the operation permissions for the corresponding Digital Employee or Long-Term Mission.
The user has ram:PassRole permission for the target Digital Employee RAM role.
The trust policy of the target Digital Employee RAM role allows the STAROps-related services to assume the role.
The permission policy of the target Digital Employee RAM role allows access to the data and resources required by the task.
ram:PassRole does not grant data access permissions to Digital Employees. It determines whether a user has the right to pass a specified Digital Employee RAM role to STAROps. The data that a Digital Employee can access is still determined by the permission policy of the Digital Employee RAM role.
We recommend that you restrict the Resource field of ram:PassRole to STAROps-dedicated Digital Employee RAM roles. We do not recommend using Resource: "*" in the long term.
The following example allows a user to pass the service-linked role AliyunServiceRoleForSTAROps to STAROps. If you use a custom role, replace the Resource value with the corresponding RoleArn.
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "ram:PassRole",
"Resource": "acs:ram::*:role/aliyunserviceroleforstarops",
"Condition": {
"StringEquals": {
"acs:Service": [
"operation-platform.aliyuncs.com",
"cloudmonitor.aliyuncs.com"
]
}
}
}
]
}Configure data viewing permissions for users
Data access by Digital Employees and data viewing by users in the console are two separate paths.
Built-in employees inherit caller account permissions, so the user must have the corresponding data or resource permissions.
Custom Digital Employees use Digital Employee RAM role permissions at runtime. When users verify results in the SLS, CMS, or ARMS console, they still need their own data viewing permissions.
We recommend that you configure read-only permissions for target data sources as needed, so that users can verify log, metric, or resource analysis results returned by Digital Employees.
Configure permissions for the Digital Employee RAM role
Custom Digital Employees obtain runtime permissions through the Digital Employee RAM role. RoleArn is the identifier for this runtime identity.
The Digital Employee RAM role requires two types of configurations:
Trust policy: Allows the STAROps-related services to assume the Digital Employee RAM role.
Permission policy: Allows the Digital Employee RAM role to access specified data and resources.
For example, if a Digital Employee needs to query logs, the Digital Employee RAM role must have the corresponding SLS read-only permissions. If the Digital Employee needs to read workspace, entity storage, or cloud resource data, the Digital Employee RAM role must have the corresponding CMS/ARMS or other service permissions.
If you only want the Digital Employee to read CloudMonitor 2.0 scenario data, you can select the service-linked role AliyunServiceRoleForSTAROps when creating a custom Digital Employee. This role is suitable for quickly configuring data query capabilities for logs, metrics, and application monitoring. It does not grant permissions for modifying cloud service configurations or changing resource states. To perform update operations, create a custom role and configure the corresponding cloud service operation permissions based on the least-privilege principle.
In production environments, we recommend that you follow the least-privilege principle and restrict authorization based on Digital Employee responsibilities, business lines, Workspaces, log projects, and resource scopes.
When using built-in employees, you do not need to configure a separate Digital Employee RAM role.
Typical configuration paths
Use built-in employees
Suitable for quick trials, controlled Q&A, and lightweight queries.
Required configurations:
Grant STAROps usage permissions to RAM users, such as viewing Digital Employees, initiating sessions, and viewing session records.
Grant read-only viewing permissions for target data sources to RAM users as needed for console verification.
You do not need to configure a separate Digital Employee RAM role or ram:PassRole for built-in employees.
Create and use custom Digital Employees
Suitable for creating dedicated O&M experts by business line, or for scenarios that require Skills, MCP, AliyunCLI, and other extensions.
Create a Digital Employee
Select a Digital Employee RAM role. For read-only queries and quick verification, you can select the service-linked role AliyunServiceRoleForSTAROps. To customize the data scope or perform cloud service update operations, create a dedicated custom role for STAROps.
If you selected a service-linked role, skip to step 4. If you selected a custom role, configure the trust policy of the Digital Employee RAM role to allow the STAROps-related services to assume the role.
If you selected a custom role, grant the Digital Employee RAM role the data, resource, or O&M operation permissions required at runtime.
Create the Digital Employee.
Grant permissions to RAM users
Grant user permissions for Digital Employee creation, viewing, updating, and conversations to RAM users.
Grant ram:PassRole permission for the target Digital Employee RAM role to RAM users.
Initiate a session and verify the data access results.
For detailed steps, see Digital Employee permission configuration.
Create Long-Term Missions
Suitable for periodic inspections, alert analysis, report generation, and continuous monitoring.
Grant Mission operation permissions to RAM users, including creation, viewing, updating, and deletion of Long-Term Missions.
Grant permissions to RAM users to view Mission artifacts and reports.
Confirm that the Digital Employee selected for the Long-Term Mission has the data access permissions required at runtime.
If the Long-Term Mission uses a custom Digital Employee, confirm that the user has ram:PassRole permission for the corresponding Digital Employee RAM role.
For detailed steps, see Mission permission configuration.
Configure least-privilege policies
Suitable for multi-user collaboration, security compliance, and business-line isolation.
We recommend that you first split users by job responsibility, and then select the appropriate policy template:
STAROps administrator.
Digital Employee configuration administrator.
General O&M user.
Long-Term Mission operator.
Read-only auditor.
For detailed templates, see Best practices for STAROps custom permission policies.
FAQ
After granting permissions to the Digital Employee RAM role, can I use the Digital Employee directly?
No. Digital Employee RAM role permissions alone are not sufficient. The Digital Employee RAM role only determines what data and resources the Digital Employee can access at runtime. The user must also have usage permissions for the Digital Employee. If the Digital Employee is a custom Digital Employee, the user must also have ram:PassRole permission for the target Digital Employee RAM role.
The user can see data in the console. Why might the Digital Employee still be unable to access it?
When a user views data in the console, the user's own permissions are used. When a custom Digital Employee runs, the bound Digital Employee RAM role permissions are used. These are different identities and must be authorized separately. Check whether the Digital Employee RAM role has access permissions for the target data source or cloud resource.
The Digital Employee can access data. Why might the user still be unable to verify it in the console?
Custom Digital Employees access data using the Digital Employee RAM role. Users view data in the SLS, CMS, or ARMS console using their own RAM user permissions. If the user needs to verify the results returned by the Digital Employee, configure the necessary read-only permissions for the data sources for that user.
After selecting AliyunServiceRoleForSTAROps, can the Digital Employee perform cloud service update operations?
No. The AliyunServiceRoleForSTAROps role corresponding to AliyunServiceRoleForSTAROps is primarily used for data reading in CloudMonitor 2.0 scenarios. It is suitable for queries, diagnostics, inspections, and report generation. It does not include permissions for modifying cloud service configurations or changing resource states. To perform update O&M actions, use a custom role and grant permissions separately.
What is the difference between PassRole and AssumeRole?
ram:PassRole controls whether a RAM user can pass a specific Digital Employee RAM role to the STAROps service. sts:AssumeRole is the action the service uses to assume the role at runtime. The fact that a trust policy allows a service to assume a role does not mean that any RAM user can pass that role to the service.
Why do I need to check Digital Employee permissions when creating a Long-Term Mission?
Mission permissions only control whether a user can create and manage Long-Term Missions. Long-Term Missions are still executed by Digital Employees at runtime. Therefore, you must confirm that the selected Digital Employee has the required data access permissions. If the Long-Term Mission uses a custom Digital Employee, you must also confirm that the user has ram:PassRole permission for the corresponding Digital Employee RAM role.