STAROps：STAROps 跨帳號存取權限實踐

業務情境

企業通常統一在一個管理帳號使用 STAROps 平台，而生產資源分散在多個業務帳號。營運人員希望在管理帳號的對話入口直接排查業務帳號的日誌與監控資料，但管理帳號中的數字員工預設只能訪問本帳號資源，跨帳號查詢會因缺少目標帳號的訪問憑據而失敗。

本文以管理帳號（帳號 A）和業務帳號（帳號 B）兩個帳號為例，給出端到端的跨帳號授權路徑：帳號 A 的使用者許可權、帳號 B 的跨帳號訪問角色與信任策略、角色 ARN 與自訂數字員工的綁定關係，以及跨帳號對話與本帳號對話在使用方式上的差異。配置完成後，帳號 A 的營運人員無需切換帳號即可查詢帳號 B 的Log Service與CloudMonitor資料。

方案架構

跨帳號訪問由三部分配置協同完成。帳號 A 的 RAM 使用者持有 STAROps 平台、CloudMonitor和Log Service的操作許可權，並通過 ram:PassRole 把角色傳遞給 STAROps 服務與CloudMonitor服務，這是使用者在帳號 A 建立並驅動數字員工的前提。帳號 B 中的 RAM 角色承載真正的資源存取權限：信任策略聲明該角色允許被帳號 A 的 STAROps 服務與CloudMonitor服務扮演，權限原則決定數字員工在帳號 B 能讀取哪些資源。帳號 A 的自訂數字員工綁定帳號 B 的角色 ARN，對話時通過 sts:AssumeRole 扮演該角色訪問帳號 B 的資源。

使用者許可權與數字員工存取權限是兩條獨立的授權鏈路，前者決定誰能操作 STAROps 平台，後者決定數字員工能觸達哪些雲資源。兩者的區別以及各類權限原則的標準模板參見STAROps 許可權配置。

前提條件

整條授權鏈路橫跨兩個帳號，開始配置前先確認下列許可權與資訊就位，避免執行到中途回頭申請：

• 具備帳號 A 與帳號 B 兩側的 RAM 操作許可權：步驟一在帳號 A 建立 RAM 使用者並授權，步驟二在帳號 B 建立 RAM 角色並授權。

• 已取得帳號 A 的帳號 ID：步驟二選擇信任主體和替換信任策略時都需要填入。

• 已確定目標 Workspace 名稱：步驟三配置數字員工的預設規則、步驟四發起對話時都需要寫明。

步驟一：在帳號 A 配置使用者許可權

使用者許可權決定 RAM 使用者能否在帳號 A 建立數字員工，並把帳號 B 的角色傳遞給 STAROps 服務與CloudMonitor服務。

1. 使用帳號 A 登入 RAM 控制台，建立 RAM 使用者，例如 xxxxxxxx。

2. 按建立自訂權限原則建立一條自訂權限原則，例如命名為 starops-read。在指令碼編輯頁簽，將策略內容替換為以下模板。

   {
     "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 語句分別把角色傳遞給 STAROps 服務（operation-platform.aliyuncs.com）和CloudMonitor服務（cloudmonitor.aliyuncs.com）。缺少任意一條，數字員工在對應服務側都無法扮演帳號 B 的角色。模板第一條語句即前文提示的寬範圍許可權，僅用於驗證配置。

3. 按為 RAM 使用者授權，在該 RAM 使用者的詳情頁添加上一步建立的自訂權限原則。

步驟二：在帳號 B 建立跨帳號訪問角色並擷取角色 ARN

該角色是數字員工在帳號 B 中的身份載體，信任策略控制“誰可以扮演”，權限原則控制“扮演後能訪問什麼”。角色建立嚮導先按雲帳號維度建立信任關係，隨後再由第 4 步的信任策略把可扮演方收窄到具體服務，兩個動作前後銜接、以最終的信任策略為準。

1. 使用帳號 B 登入 RAM 控制台，在左側導覽列選擇身份管理 > 角色，單擊建立角色。

2. 角色類型選擇雲帳號，信任主體名稱選擇其他雲帳號，並輸入帳號 A 的帳號 ID。此時的信任範圍是帳號 A 這一個帳號，尚未限定到具體服務。

3. 輸入角色名稱，例如 StarOpsCrossAccountRole。

4. 將該角色的信任策略替換為以下內容，並把 <帳號A-ID> 替換為帳號 A 的帳號 ID。替換後的信任策略是本方案最終生效的版本。

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

   <帳號A-ID>@operation-platform.aliyuncs.com 與 <帳號A-ID>@cloudmonitor.aliyuncs.com，表示只有帳號 A 下的 STAROps 服務與CloudMonitor服務可以扮演該角色，而不是帳號 A 的全部身份都可以扮演。這一替換不可省略：沿用第 2 步的帳號級信任範圍，角色不滿足“允許被帳號 A 的 STAROps 服務與CloudMonitor服務扮演”這一要求。

5. 按建立自訂權限原則建立一條自訂權限原則，例如命名為 StarOpsCrossAccountRole。在指令碼編輯頁簽，將策略內容替換為以下模板。

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

   ram:PassRole：角色只需在帳號 B 讀取資源，不需要再向其他服務傳遞角色。該模板同樣屬於前文提示的寬範圍許可權。

6. 按為 RAM 角色授權，將該權限原則綁定到本步驟建立的自訂 RAM 角色。

7. 在該角色的詳情頁複製角色 ARN。角色 ARN 是帳號 A 的數字員工定位並扮演該角色的唯一標識，下一步建立自訂數字員工時需要填入。

步驟三：在帳號 A 建立自訂數字員工

在帳號 A 建立自訂數字員工，並綁定步驟二擷取的角色 ARN，使該數字員工的每次查詢都在帳號 B 的角色身份下執行。跨帳號情境中，數字員工可見的 Workspace 不止一個，因此在預設規則中限定目標 Workspace 可以避免查詢落到無關的 Workspace 上。預設規則的樣本內容如下，其中的 Workspace 約束對應上文的跨帳號差異，需要保留：

# 角色定義
你是一名資深的跨帳號查詢諮詢助手。

# 約束
- 僅查詢 Workspace `xxxxx` 下的資源，其他 Workspace 一律不關心、不查詢。

# 查詢步驟
1. 確認查詢意圖（時間範圍、指標、關鍵字），不清晰則先澄清。
2. 產生準確、可執行檔查詢語句。
3. 給出結論 + 資料解讀。

步驟四：發起跨帳號對話時顯式指定 Workspace

與該自訂數字員工對話時，在提問時顯式寫出目標 Workspace 的名稱。跨帳號對話不繼承頁面上當前選中的 Workspace，缺少顯式指定時，數字員工會先列出全部 Workspace 並等待選定，查詢鏈路因此被拉長。

結論

帳號 A 的使用者許可權與 ram:PassRole 委派、帳號 B 的跨帳號訪問角色及其信任策略、數字員工與角色 ARN 的綁定，三者齊備後，帳號 A 的營運人員即可在一次對話中查詢帳號 B 的Log Service與CloudMonitor資源。樣本中的許可權範圍仍偏寬，進入日常使用前按角色收斂許可權是這套配置的下一步改進方向。