ixCSP 店中店 RBAC 互動預覽 — 使用手冊

0 這是什麼

「店中店」= 你向平台租算力,自用一部分、把剩下分租給你的客戶;你的客戶(若為經銷身分)還能再往下分租。這個預覽把該模型的 RBAC / 租戶樹 / 可見性 / 代管 做進真正的 ixCSP 畫面。

1 角色與登入(必讀:誰、登哪一端、做什麼)

第一關是 Cloudflare OTP(輸入你的 @infinitix.co email 收驗證碼);第二關是應用程式登入。兩種身分、兩個入口、兩組帳號,不可互用(最常見的「進不去」就是拿平台端帳號登租戶端)。

1.1 你是誰?→ 登哪一端

1.2 「登入帳號」vs「RBAC 角色」是兩件事(別混)

• 登入帳號(入口)決定你站在哪一端:OC = 平台視角(看全樹)、DC = 租戶視角(只看自己子樹)。
• RBAC 角色(owner / admin / member / super_admin / 自訂角色)決定在該視角內「能做什麼」:這是畫面裡 Roles / 綁定 / 模擬器管的東西。
• ⚠ 預覽限制:RBAC 角色資料是 mock —— 登入帳號不會真的綁到某個 RBAC 角色;要驗證「某角色能不能做某事」,用 Permission Simulator(選帳號 × 動作 × 資源 → Allow/Deny + 理由)。

1.3 常用操作 × 誰做 × 在哪裡

登入後,RBAC 功能都在左側選單的 Access Control 群組:Roles / Tenants & Organizations / Permission Simulator / Audit Log / Delegated Access。

2 核心概念 3 分鐘

• Scope 樹(在哪)vs 角色(能幹嘛)是兩種階層:scope 是容器樹 platform → tenant → organization → project;角色是繼承鏈(owner ⊃ admin ⊃ member)。
• 店中店 = tenant 可以包 tenant:經銷商(reseller)租戶底下可再開子租戶(子經銷或終端客戶)。上線政策預設 最多 2 層租戶(平台→經銷商→終端),超過會被擋(depth cap)。
• 可見性三層:① 匯總恆可見 —— 上線永遠看得到下線的 Scope Rollup(子租戶數/啟停/配額/結算,治理與分潤所需);② 明細預設黑箱 —— 下線的成員名單/角色是它的商業機密,看不到;③ 委派破例 —— 有效的 Delegated Access grant 才解鎖明細,且全程稽核、有期限(GDAP 式)。
• 隔離走血緣(ancestry):你只看得到自己子樹;直接輸入別家租戶的網址會得到 not found。

2.5 帳號生命週期 × 金流 × 客戶歸屬(DC/OC 分工總表)

從「創建帳號」到「收錢」,每個動作歸哪一端。圖例:✅ 預覽已可操作 · 🔧 設計已拍板、待後續子專案 · ❓ 尚未拍板。

2.5.1 生命週期:誰在哪一端做什麼

一句話:「開店、管店東、抽成」在 OC;「開自己的店、分租、管自己人」在 DC。

2.5.2 二房東金流怎麼設(🔧 SP-3,設計已定)

資金流:客戶付二房東(在地幣別)→ 平台 USD 帳本記帳 + 匯率快照 → 平台抽 take-rate → 依週期結算。現況誠實:ixCSP 既有金流為平台級單租戶設定;per-經銷商金流整套為 SP-3 新建,目前預覽沒有。

2.5.3 大房東客戶 vs 二房東客戶:註冊/登入怎麼分

核心原則(已拍板):帳號是全域的;「你是誰的客戶」不寫在帳號上,寫在 membership(帳號→租戶的綁定)上。

登入階段不需要分辨:同一入口、同一全域帳號;登入後由 membership 決定你落在哪個租戶 context(只見自己子樹),多重歸屬 → tenant switcher。此為 Azure CSP 同款模式,並避開「每個二房東一套帳號系統」的合併地獄。

3 DC 租戶端功能導覽

3.1 Roles — 角色清單與權限矩陣

系統角色(owner/admin/member)+ 自訂角色。點任一角色進詳情:繼承鏈、有效權限矩陣(分類頁籤、繼承/gated 標示)、影響範圍。頂部的灰色條是 context-strip,隨時顯示你目前所在的租戶。

3.2 Tenants & Organizations — 檔案總管式租戶/組織樹

你子樹的階層總覽:子經銷(Tenant)、部門(Organization)、專案(Project)可展開收合;點任一列下鑽進該 scope 的詳情。注意「子經銷 A-停用」帶 Suspended 標籤 —— 狀態一目瞭然。

3.3 New Tenant — 開通子租戶(店中店的「開店」)

樹頁右上 New Tenant 開通子租戶:名稱、Kind(Reseller 可再往下分租 / Customer 終端)、配額引用、第一位管理員。平台守則在服務端強制:depth cap(2 層)、單一經銷商的子租戶數上限、審核旗標(開啟時新租戶為 pending)——超限會被擋並顯示原因。旁邊的 New Organization 則是建內部部門/專案。

3.4 Scope Detail — 下鑽詳情 + Scope Rollup(恆可見匯總)

點進任一租戶:Overview(父層/子 scope/角色/綁定數)、Child Scopes、Scope Rollup 匯總卡(子租戶數、啟用/停用、配額、結算、事件 —— 配額與結算目前為 demo 佔位數字,已標註)。租戶明細區(成員/角色)預設顯示「Detail is protected」上鎖卡 —— 這就是可見性模型的黑箱層,要解鎖請看下一章。

3.5 Permission Simulator / Audit Log

模擬器:選 帳號 × 動作 × 資源 × 範圍 → 引擎給出 Allow/Deny + 理由 + 繼承鏈(驗證「權限真的有生效」)。稽核:所有寫入動作(建租戶/角色/授權/委派使用)自動記錄,可依動作/結果/時間篩選。

4 委派代管完整流程(break-glass)

情境:下線租戶需要你(上線)進去幫忙看/處理 —— 但明細預設黑箱。做法:建立一張有期限的 Delegated Access grant → 進入代管 session → 明細解鎖 → 離開。全程稽核。

1. 左側選單進 Delegated Access。清單已有一張示範 grant(對象 op-concierge,Active)。也可自建:選對象、勾權限、給到期日 → Grant Access。
2. 對 Active 的 grant 按列尾 ⋯ → Enter Session。頂部立即出現黃色代管條:「Acting as 〈租戶名〉 · Expires: 〈到期〉 · Exit Delegation」——只要在代管中,這條在每一頁都提醒你「你正站在別人的租戶裡」。
3. 代管中回到 租戶與組織 → 點進 子經銷 A:原本上鎖的明細區已解鎖(顯示成員/自訂角色)。每次解鎖讀取都會寫入 delegated_use 稽核。
4. 按代管條右側 Exit Delegation 離開:黃條消失,再看明細 → 重新上鎖。

5 OC 平台端(INFINITIX 視角)

同一組畫面掛在 /system/access-control,差別是視角:平台看整棵樹(所有經銷商),角色/稽核/模擬器都是 platform scope。

• OC 開最上層經銷商(New Tenant @ platform,可選 Reseller)。
• DC 只見自己子樹;OC 全見 —— 對照著開兩個分頁看,隔離語意最直觀。

6 建議 Demo 動線(10 分鐘)

1. 登入 DC(seltestpods4)→ Access Control → Roles:看角色 + 點進 owner 看繼承鏈與矩陣。
2. Tenants & Organizations:展開樹,認出「Tenant 包 Tenant」的巢狀(子經銷 A)。
3. New Tenant 建一個終端客戶(例:北京GB200分租客)→ 樹上立即出現。注意 drawer 的 Kind 只剩 Customer 可選 —— 你在第 2 層,再往下開經銷商會超過 2 層 cap,守則直接反映在選項上。
4. 連開幾個子租戶到達你的名額上限 → 會跳「無法建立租戶:已達子租戶數量上限」—— maxChildren 守則生效。
5. 點進 子經銷 A:看 Scope Rollup(恆可見)與下方上鎖的明細區(黑箱)。
6. Delegated Access → 對示範 grant Enter Session → 黃色代管條出現。
7. 回到 子經銷 A → 明細解鎖。
8. Exit Delegation → 再看 → 重新上鎖。Audit Log 裡找到整串紀錄。
9. Permission Simulator:任挑一組帳號×動作×資源,看 Allow/Deny + 理由。
10. 換 OC(ixcspadm)→ 租戶與組織:平台全樹對照。

7 Mock 邊界與已知限制(誠實清單)

• RBAC 資料 in-memory:重新整理(F5)會重置新建租戶/grant/代管 session(需重按 Enter Session)。後端 RBAC API 就緒後換真資料、畫面不變(API-shaped)。
• 配額 / 結算為佔位數字(已在畫面標註)—— 屬 SP-1 / SP-3 後續子專案。
• 解鎖後的明細目前顯示成員/角色「數量」,完整名單表格為 follow-up。
• 角色/綁定的 per-scope 過濾為 follow-up(詳情頁有註記)。
• 此為 branch build(未併 main),請勿當正式環境操作依據。

8 疑難排解