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 / 綁定 / 模擬器管的東西。
• ⚠ 預覽限制: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,設計已定)

資金流:客戶付二房東(在地幣別)→ 平台 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 終端)、配額引用、第一位管理員。平台守則在服務端強制:depth cap(2 層)、單一經銷商的子租戶數上限、審核旗標(開啟時新租戶為 pending)——超限會被擋並顯示原因。旁邊的 New Organization 則是建內部部門/專案。

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

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

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」—— 憑碼歸屬到發碼租戶。不填碼則歸平台直客;碼無效或過期會被退回、不會誤歸。

7 委派代管完整流程(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 離開:黃條消失,再看明細 → 重新上鎖。

8 OC 平台端(INFINITIX 視角)

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

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

9 建議 Demo 動線(15 分鐘)

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)→ 租戶與組織:平台全樹對照;點進 宏碁雲算經銷 看 Commercial Profile(20% / 5% / 3x / monthly,platform-only 編輯)。
11. 回 DC → Commerce → Pricing:把 500 改成 1000 → 標「Over cap」不能存(上限 975);改回合法值儲存。
12. DC → Ledger 按「Record demo transaction」→ 看三腿分錄;換 OC 同樣記一筆 → Settlement 按 Generate → 淨額 6.615384 USD。
13. DC → 子經銷 A 詳情 → Issue Invite 得 INV- 碼 → Commerce → Join Demo 憑碼加入 → 成功歸屬 子經銷 A。

10 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),請勿當正式環境操作依據。

11 疑難排解與常見問題

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

11.2 操作疑難