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

0 這是什麼

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

1 痛點與解法(業務面)

先講生意,再講畫面。「店中店」要解的是四種人的痛;每個痛都對應平台的一個內建機制,並且都能在這個預覽裡實際點到。

1.1 四種人、四種痛

1.2 五個機制對症下藥

2 業務操作流程圖

四張圖看懂整條生意:開店鏈(誰先做什麼)→ 錢怎麼流 → 客戶歸誰 → 代管怎麼破例。圖中數字與 §6 截圖裡的 demo 數字一致,可對照實際畫面。

F1 · 端到端開店鏈(OC 平台 → DC 二房東 → 終端客戶)

F2 · 金流:一筆交易的三腿與結算(USD 單一帳本)

F3 · 客戶歸屬:這個新客戶算誰的?

F4 · 委派代管(GDAP 式 break-glass)生命週期

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

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

1.1 你是誰?→ 登哪一端

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

• 登入帳號(入口)決定你站在哪一端:OC = 平台視角(看全樹)、DC = 租戶視角(只看自己子樹)。
• RBAC 角色(owner / admin / member / super_admin / 自訂角色)決定在該視角內「能做什麼」:這是畫面裡 Roles / 綁定 / 模擬器管的東西。
• 租戶側三分工(拍板 2026-07-03):admin = 營運角色(企業側 OP) —— 不另設「OP 帳號」型別。owner = 商務決策(開子租戶 / 下切配額 / 設定價 / 核准委派 / 匯出結算單);admin = 日常營運(管成員 / 自訂角色 / 綁定,看得到配額・定價・結算・委派狀態,但上述六個合約級動作一律 Deny,有測試背書);member = 一般使用(唯讀匯總)。無論大房東或二房東直屬的企業用戶,營運人員就是在該企業租戶綁 admin,一律登入 DC 租戶端;要更細的營運切分用自訂角色。
• ⚠ 預覽限制:RBAC 角色資料是 mock —— 登入帳號不會真的綁到某個 RBAC 角色;要驗證「某角色能不能做某事」,用 Permission Simulator(選帳號 × 動作 × 資源 → Allow/Deny + 理由)。

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

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

4 核心概念 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。

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

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

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

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

4.5.2 二房東金流怎麼設(✅ SP-3,已可在預覽操作 mock)

資金流:客戶付二房東(在地幣別)→ 平台 USD 帳本記帳 + 匯率快照 → 平台抽 take-rate → 依週期結算。✅ 已可在預覽操作(mock):側欄 Commerce 群組 → Pricing(定價+上限)/ Ledger(三腿帳本:客戶收費/批發成本/平台抽成,可按「記一筆示範交易」)/ Settlement(OC 可產生結算單,淨額 = 總額 − 批發 − 抽成)。誠實:資料為 in-memory mock、匯率為 seed 固定值;真金流通道(ECPay/Stripe per-tenant)與真匯率仍為後端未來項。

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

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

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

5 DC 租戶端功能導覽

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

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

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

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

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

樹頁右上 New Tenant 開通子租戶:名稱、Kind(Reseller 可再往下分租 / Customer 終端)、第一位管理員,以及初始配額段(SP-1):從你持有的算力池選來源、填三軸數量,建立時先驗證再下切 —— 池不是你持有的、或任一軸超過剩餘,整個開通會被擋,不會發生「租戶建好了、配額卻切失敗」的殘局。平台守則同樣在服務端強制:depth cap(2 層)、單一經銷商的子租戶數上限、審核旗標(開啟時新租戶為 pending)——超限會被擋並顯示原因。旁邊的 New Organization 則是建內部部門/專案。

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

點進任一租戶:Overview(父層/子 scope/角色/綁定數)、Child Scopes、Scope Rollup 匯總卡(子租戶數、啟用/停用、配額、結算、事件)。統計數字的真實度(2026-07-03 起):配額(Quota used)為 EntitlementStore 即時推導的真值(僅「用量」為示範 seed 值,畫面有標註);結算(Gross charges)已接 SP-3 帳本(帳本無資料時顯示 DEMO 佔位並標示);事件(Incidents)仍為佔位。Rollup 之後還有 Entitlements 配額卡(持有池 + 下切明細,見 §7)。租戶明細區(成員/角色)預設顯示「Detail is protected」上鎖卡 —— 這就是可見性模型的黑箱層,要解鎖請看 §8。

5.5 Permission Simulator / Audit Log

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

6 Commerce 金流操作導覽(SP-3,mock)

錢的四件事:平台設條件 → 二房東定價 → 交易進帳本 → 週期結算;外加「客戶歸屬」的邀請碼演示。左側選單 Commerce 群組:Pricing / Ledger / Settlement / Join Demo。以下截圖全部是預覽真畫面、真互動產生的數字,與 §2 流程圖同一組。

6.1 商務條件 — OC 對每家經銷商設(商務設定卡)

OC → Tenants & Organizations → 點進經銷商(例:宏碁雲算經銷)→ Commercial Profile 卡:幣別區(tw)、批發折扣(20%)、take-rate(5%)、markup 上限(3x)、結算週期(monthly)。只有平台端能編輯(Edit);DC 看同一張卡是唯讀 —— 條件是平台開給你的,不是你自己填的。

6.2 定價 — DC 在上限內自訂對客價

DC → Commerce → Pricing:幣別由幣別區限定(tw → TWD);每個 SKU 顯示牌價(USD)與 Cap(對客售價上限)= 牌價 × 匯率 × markup 上限。例:gpu-hour-nvl72 牌價 10 USD × 32.5 × 3x = 975 TWD。輸入超過上限會即時標「Over cap」且不能儲存 —— 護欄在服務層 enforce,不是只有前端提示。

6.3 帳本 — 每筆交易自動拆三腿(USD SSOT)

DC → Commerce → Ledger → 按「Record demo transaction」記一筆示範交易:客戶付 TWD 500,帳本立即出現三條 USD 分錄 —— Charge +15.384615(匯率快照 32.5)、Wholesale cost −8(牌價 10 × 80%)、Platform take −0.769231(5%)。在地幣別只是收付與顯示,分潤與對帳一律以 USD 帳本為準。

6.4 結算 — OC 出結算單、算應付淨額

OC → Commerce → Settlement → 「Generate statement (demo period)」:把本期帳本彙總成結算單,淨額 = 總額 − 批發 − 抽成 = 15.384615 − 8 − 0.769231 = 6.615384 USD(應付二房東)。結算單 immutable,產生後不可改。

6.5 客戶歸屬 — 發邀請碼 → 憑碼加入(歸因演示)

兩步看懂「這客戶算誰的」:

1. DC → Tenants & Organizations → 點進 子經銷 A → Invite Management 卡按 Issue Invite → 得到邀請碼(例:INV-1)。
2. DC → Commerce → Join Demo:填顯示名稱 / Email / 邀請碼 → Join → 成功頁顯示「Tenant: 子經銷 A」—— 憑碼歸屬到發碼租戶。不填碼則歸平台直客;碼無效或過期會被退回、不會誤歸。

6.6 退款 — 三腿等比反沖(SP-3b)

客戶要退錢時,不是只沖銷收費那一條 —— 三腿一起等比反沖,分潤與對帳自動回正:Commerce → Ledger → 在 Charge 列按 ⋯ → Refund → drawer 顯示 原金額 / 已退 / 剩餘可退 → 輸入退款額送出。以截圖為例,對 15.384615 的原交易退 7.69 USD(約半額),帳本立即出現三條 refund 腿:Refund (charge) −7.69(退客戶)、Refund (wholesale) +3.9988(批發成本按比例退回)、Refund (take) +0.3845(平台按比例退抽成)。

• 匯率用原交易的 FxSnapshot:退款換算沿用當初那筆的匯率快照,不產生匯差爭議。
• 累計超退被擋:多次部分退款累計不能超過原額(服務層 enforce,超退顯示原因)。
• Refund 動作只出現在 Charge 列(批發/抽成腿是衍生分錄,不能單獨退)。
• 權限:wallet.refund = owner + super_admin(§9 的 RBAC 詞彙;operator 刻意不給)。

6.7 停機回補款 Service Credit(SP-3b)

機器停機造成客戶損失時,走 Service Credit 而不是退款:OC → Commerce → Settlement → Service Credits 區 → Issue credit,填 租戶、關聯資源池(entitlement)、停機時窗、金額與人工填報註記 → 發出(issued)→ 入帳(applied)成為帳本的 credit 腿。與退款的關鍵差異:回補款由平台承擔,不反沖批發與抽成腿。結算單同步多了 Refund / Credit 兩個調整欄(零調整時淨額公式與 §6.4 完全相同)。

• 權限:sla_policy.issue_credit = operator + owner(維運可賠;一般 admin 不行)。
• 誠實標示:預覽無監控數據源,停機時窗為人工填報(畫面原文「Downtime windows are entered manually」)。
• 上線發給下線的 pass-through credit:服務層已支援,DC 發起表單為 follow-up(目前 DC 唯讀看自己收到的 credits)。

7 Entitlement 資源配額 — 算力池與下切(SP-1,mock)

錢管完了管算力。「配額鏈」回答一個問題:二房東手上的算力是哪來的、還剩多少可以分? 平台持有實體算力池 → 逐層「下切」(allocate)給下線 → 每一層只能分自己持有的量,超量在服務層直接被擋。每個池有三軸:GPU 節點 / 儲存(TB)/ 網路(Gbps),三軸各自守各自的剩餘。

7.1 平台 4 個 root 池 — OC 的 Entitlements 頁

OC → Role-Based Access → Entitlements:上表 Held Pools 是本 scope 持有的池 —— 平台 seed 了 4 個 root 池:東京 4×NVL72、北京 2×GB200、南京 1×B200、台北 1×RTX-PRO-6000,欄位為 Capacity / Used / Allocated / Remaining(持有、已分、剩餘皆為 EntitlementStore 即時推導的真值;僅 Used 用量是示範 seed 值,頁面標註「Usage figures are demo values」)。下表 Downward Allocations 是往下切出去的份:宏碁雲算經銷拿了 2×NVL72、環宇智算代理拿了 1×GB200……每列都有狀態與列尾操作(Revoke)。

7.2 下切(Allocate)— 只能分自己有的、只能分給下級

1. 對持有池按列尾 ⋯ → Allocate:drawer 顯示 Source Pool 與 Pool remaining(三軸各自的剩餘,例:1 nodes / 600 TB / 75 Gbps)。
2. Target Scope 只列「嚴格下級」:不能分給自己、不能分給別人子樹 —— 選單裡根本不會出現非法對象。
3. 填三軸數量 → Allocate。任一軸超過剩餘 → 服務層擋下,頁面 alert「exceeds the pool's remaining quota」,且清單不會多出任何一列(enforcement 是真的,不是前端提示)。
4. 收回配額:對 Downward Allocations 列按 ⋯ → Revoke。

7.3 與其他畫面的連動

• DC 隔離:DC 只看得到自己子樹的池 —— 宏碁雲算經銷的 Entitlements 只有東京 NVL72(平台切給它的份),看不到北京 GB200 / 南京 B200 / 台北 RTX 池。
• 租戶詳情配額卡:scope detail 在 Scope Rollup 之後有 Entitlements 卡(持有池 + 下切明細 + Manage 按鈕跳本頁)—— 見 §6.1 截圖。
• Scope Rollup 的 Quota used 與本頁同源(EntitlementStore 即時推導)。
• 開通子租戶時的初始配額:New Tenant drawer 的初始配額段走同一套驗證(先驗證再建立,見 §5.3)。

8 委派代管完整流程(break-glass,SP-5 完整工作流)

情境:下線租戶需要你(上線)進去幫忙看/處理 —— 但明細預設黑箱。2026-07-03 起這裡不再是「直接建 grant」的簡化版,而是完整工作流:請求(request)→ 租戶核准(approve)→ 進場(enter)→ 權限子集 enforcement → 離場/撤銷。全程稽核。

8.1 請求 → 核准

1. 左側選單進 Delegated Access → Request Delegated Access 表單:選 Target Tenant(要被代管的租戶,例:子經銷 A)、Grantee(從平台管理員 roster 選,例:平台維運)、到期時間與備註。
2. 權限用 3 個 preset chips 一鍵帶入:Read-only / Tenant Admin / Quota Ops(例:Read-only = rollup_view.view/list + member.view/list),被選權限以 chips 列出可逐一移除;或按 Advanced 走 resource / action 兩段式自選。Submit Request → grant 進入 Pending。
3. 核准在 Pending My Approval 收件匣:只出現在租戶側(DC)、限自己子樹 —— OC 平台端不能「自己請求自己核准」,授權的決定權永遠在被代管的租戶手上。Approve → Active(grant 有 5 種狀態 chips:Pending / Active / Rejected / Expired / Revoked)。

8.2 進場 → 權限子集 → 離場

1. 對 Active 的 grant 按列尾 ⋯ → Enter Session。頂部立即出現黃色代管條:Acting as 〈租戶名〉+ Acting principal + 這張 grant 授了哪些 verb 的 chips + 剩餘時間 + Exit Delegation —— 只要在代管中,這條在每一頁都提醒你「你正站在別人的租戶裡、你只有這幾個權限」。
2. 代管中回到 租戶與組織 → 點進該租戶:原本上鎖的明細區已解鎖。每次解鎖讀取都會寫入 delegated_use 稽核。
3. 權限子集是真的擋(verb-subset enforcement):session 中你只有 grant 上那組動作 —— 拿 Read-only 卻想建租戶、下切配額、改定價,會被服務層直接拒絕(不是畫面藏起來而已)。
4. 按代管條右側 Exit Delegation 離開:黃條消失,再看明細 → 重新上鎖。到期同效;租戶側 Revoke 會把進行中的 session 一併踢出(撤銷與強制離場各寫一筆稽核)。

9 OC 平台端(INFINITIX 視角)+ OP 平台角色(SP-4)

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

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

9.1 RBAC 詞彙已含店中店資源(SP-4)

權限詞彙擴充到 82 個資源、14 個分類,新增 RESELLER & COMMERCE 組 —— sub_tenant(open_sub_tenant)、delegated_grant(request / approve / enter_session)、entitlement(allocate / revoke)、price_list(set_pricing)、settlement_statement(generate / export)等店中店動作都是一等公民,出現在角色詳情的有效權限矩陣裡(例:super_admin 顯示「324 actions across 82 resources」)。

9.2 平台 OP 角色:operator / auditor

驗證方式:Permission Simulator 現在有 preset 情境(租戶側 2 個 + 平台側 2 個)一鍵帶入 —— 例:operator × delegated_grant.enter_session → Allow;auditor × price_list.update → Deny + 理由與繼承鏈。角色詳情頁可看繼承鏈(例:super_admin → operator)。

10 建議 Demo 動線(20 分鐘)

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(恆可見,配額為真值)、Entitlements 配額卡 與下方上鎖的明細區(黑箱)。
6. 側欄 Entitlements:確認你只看得到自己子樹的池(東京 NVL72,沒有北京/南京/台北池)→ 對池按 ⋯ → Allocate 下切一份給 子經銷 A;再試一次把 Capacity 填成大於剩餘的數字 → 被擋「exceeds the pool's remaining quota」、清單不多列。
7. Delegated Access → Request 表單:Target Tenant 選 子經銷 A、Grantee 選 平台維運、按 Read-only chip → Submit Request → 在 Pending My Approval 按 Approve → 狀態變 Active —— 完整 request→approve 工作流。
8. 對 Active grant(或示範 grant)按 ⋯ → Enter Session → 黃色代管條出現(含已授權 verb chips 與剩餘時間)。
9. 回到 子經銷 A → 明細解鎖;順手試一個 grant 沒授權的動作(例:Read-only 下開子租戶)→ 被服務層拒絕 —— verb-subset enforcement。
10. Exit Delegation → 再看 → 重新上鎖。Audit Log 裡找到整串紀錄。
11. Permission Simulator:按 preset 情境 一鍵帶入(例:operator × enter_session → Allow;auditor × price_list.update → Deny),或任挑一組帳號×動作×資源。
12. 換 OC(ixcspadm)→ 租戶與組織:平台全樹對照;點進 宏碁雲算經銷 看 Commercial Profile(20% / 5% / 3x / monthly,platform-only 編輯)。
13. 回 DC → Commerce → Pricing:把 500 改成 1000 → 標「Over cap」不能存(上限 975);改回合法值儲存。
14. DC → Ledger 按「Record demo transaction」→ 看三腿分錄;換 OC 同樣記一筆 → Settlement 按 Generate → 淨額 6.615384 USD。
15. DC → 子經銷 A 詳情 → Issue Invite 得 INV- 碼 → Commerce → Join Demo 憑碼加入 → 成功歸屬 子經銷 A。

11 Mock 邊界與已知限制(誠實清單,2026-07-04 SP-3b 後更新)

11.1 已是「真行為」的部分(前端服務層真邏輯,非佔位)

• 配額(SP-1):池的持有 / 已分 / 剩餘與 rollup 的 Quota used 由 EntitlementStore 即時推導;下切驗證(嚴格下級、三軸剩餘、not-pool-owner)是服務層真 enforcement。僅「用量(Used)」為示範 seed 值,畫面標註「Usage figures are demo values」。
• 結算 / 營收(SP-3):rollup 的 Gross charges 與 Settlement 已接三腿帳本彙總;帳本沒資料時顯示 DEMO 佔位並在畫面標示。
• 退款 / 回補款(SP-3b):退款=三腿等比反沖(沿用原交易 FxSnapshot、累計超退服務層擋);Service Credit 兩態(issued→applied,credit 腿入帳,平台承擔);結算單 Refund/Credit 調整欄零調整時與舊公式一致 —— 皆為服務層真 enforcement。
• RBAC 詞彙(SP-4 + SP-4b):82 個資源、14 分類,含 RESELLER & COMMERCE 組(sub_tenant / delegated_grant / entitlement / price_list / settlement_statement);平台角色 operator / auditor 與 simulator preset 情境皆走真引擎判定。
• 委派(SP-5):完整 request → approve → enter 工作流(5 狀態、租戶側核准、OC 不能自我核准)+ session 中 verb-subset enforcement(不在 grant 上的動作被服務層拒絕)、Revoke 踢出進行中 session。

11.2 仍為 mock / 佔位 / 限制

• RBAC 資料 in-memory:重新整理(F5)會重置新建租戶/配額下切/grant/代管 session(需重按 Enter Session)。後端 RBAC API 就緒後換真資料、畫面不變(API-shaped);P4 前所有行為以 mock 語意為準。
• rollup 的事件數(Incidents)仍為佔位數字。
• 用量(quota Used)為示範 seed 值(如上;真用量要接後端計量)。
• 解鎖後的明細目前顯示成員/角色「數量」,完整名單表格為 follow-up。
• Service Credit 的停機時窗為人工填報(預覽無監控數據源,畫面有標);上線發下線的 pass-through credit,DC 發起表單為 follow-up(服務層已支援)。
• 角色/綁定的 per-scope 過濾為 follow-up(詳情頁有註記)。
• 此為 branch build(未併 main),請勿當正式環境操作依據。

12 疑難排解與常見問題

12.1 常見問題(業務 / 設計)

12.2 操作疑難