STAROps 操作 ECS：角色、命令与变更权限

STAROps 自定义数字员工通过 RAM Role 查询 ECS、执行云助手命令和修改安全组。遇到 Forbidden.RAM 时，分别检查使用者权限、角色信任、角色访问权限和执行策略。

确认资源与四层权限

自定义数字员工通过绑定的 RAM Role 访问资源。需要分别检查四处：

系统内置员工与自定义员工的权限路径不同，不能混用配置。以下讨论的是绑定自定义 RAM Role 的数字员工。

ram:PassRole 授予使用者，资源范围指向数字员工绑定的 Role ARN。它允许把该角色交给服务使用，不会自动赋予角色 ECS 权限。

配置信任策略和 PassRole

信任策略回答“谁可以扮演角色”。STAROps 官方模板中的服务主体包括：

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

给使用者的 PassRole 示例，资源应替换为实际绑定角色：

{
  "Version": "1",
  "Statement": [{
    "Effect": "Allow",
    "Action": "ram:PassRole",
    "Resource": "acs:ram::<ACCOUNT_ID>:role/starops-demo-ecs-curl",
    "Condition": {
      "StringEquals": {
        "acs:Service": [
          "operation-platform.aliyuncs.com",
          "cloudmonitor.aliyuncs.com"
        ]
      }
    }
  }]
}

访问权限则按任务拆开：实例、云助手状态和执行结果查询，命令执行，安全组变更，分别授权。资源能否收敛到指定实例或安全组，要逐项核对 API 的可授权资源类型与条件，不要直接复制一份 ecs:* 策略长期使用。

绑定角色，检查数字员工执行策略

在数字员工设置中选择自定义角色并核对 ARN，再进入执行策略检查云 CLI 工具和审批规则。

需要的 API 可分为三组，不要把全部操作放到同一份宽权限策略中：

验证实例查询与命令执行

首次验证可以按这个顺序进行：

1. 在数字员工配置中核对实际 Role ARN。
2. 使用目标 ECS 所在地域调用实例查询。
3. 确认实例运行中，云助手 Agent 在线。
4. 提交经过检查的测试命令。
5. 查询执行结果，核对状态、退出码和输出。

STAROps 控制台的当前地域，不一定是目标 ECS 的地域。查询杭州实例时，应使用实例对应的地域参数。

云助手在实例内部执行命令，不需要为这条运维路径额外开放公网 SSH。可以先让数字员工执行一个明确的测试请求：

查询指定地域、指定 ECS 的状态及云助手在线状态。
确认在线后，在该实例执行 curl -I https://www.aliyun.com。
返回 InvokeId、执行状态、ExitCode 和实际输出，不修改实例配置。

命令提交成功也不等于执行成功，要继续读取结果。HTTP 测试还要查看响应码和返回内容，不能只看命令已经发出。

RunCommand 可以执行 Shell，风险取决于命令内容和实例内权限。即使 RAM 只允许操作一台实例，也无法靠实例 ID 限制脚本中的每个动作；生产命令需要配合审批、系统权限和审计。

安全组变更与验证

一次入站规则变更至少包含目标安全组、协议、端口、来源 CIDR 和用途。/32 只代表一个 IPv4 地址，与向所有公网地址开放不同。

例如测试需求“允许指定来源访问 TCP 888”，应先读取现有规则，确认不存在相同配置，再提交差异供审批。新增需要相应的授权 API，撤销也需要事先准备权限。

变更后重新读取规则，逐项比较方向、协议、端口和来源。安全组规则正确，也不保证应用可访问：还要检查监听地址、实例内防火墙和网络路径。

权限错误排查

保留任务 ID、RequestId、命令 InvokeId、审批记录及变更前后配置，后续才能还原一次操作。巡检、实例命令与网络变更可以拆成不同角色，减少长期积累的权限。

参考

• STAROps 权限配置
• 数字员工权限配置