審批流程

對應主管要求 ② 零信任。

是什麼

Issue 從 open 進到 approved 之間的閘門。由：

• Approval Rule（規則：什麼樣的變更 → 走什麼審批模板）
• Approval Template（模板：多步驟、每步指派誰）
• Self-Approval Policy（自核策略：是否允許自己核自己提的）

三者組合決定。

三層模型

Rule 的條件

WORKSPACE_APPROVAL.rules[].condition 是 CEL 表達式。可用變數：

變數	型別	例
source	enum	CHANGE_DATABASE / CREATE_DATABASE / EXPORT_DATA / REQUEST_ROLE / REQUEST_ACCESS
level	enum	LOW / MODERATE / HIGH
project_id	string	play
environment_id	string	prod
database_change_type	enum	DDL / DML / SDL
affected_rows	int64	plan check 估算結果

範例條件：

// Prod DDL → 走兩步審批
source == "CHANGE_DATABASE" && environment_id == "prod" && database_change_type == "DDL"

// 大量 DML（>10000 rows）→ 走 DBA 審批
source == "CHANGE_DATABASE" && database_change_type == "DML" && affected_rows > 10000

// Export 敏感資料 → 走資安審批
source == "EXPORT_DATA" && level == "HIGH"

第一條 match 的 rule 勝出。建議把最嚴格的條件放最上面。

Step 的指派方式

每個 step 可用以下任一指派：

指派	例
user	具體某位（alice）
group	user group
role	workspaceDBA / projectOwner / 自訂 role
cel	CEL 求值得到一個或多個 actor

推薦用 role，避免具名 user 離職 / 休假時審批卡住。

Self-Approval

Setting	行為
disallow_self_approval_default = true（新 workspace 預設）	零信任：所有 project 禁止自核，即便 project 設定為允許
disallow_self_approval_default = false	project 級 AllowSelfApproval 才生效

Argus P0-1 設計決定：把預設往安全側推，project 想開放必須雙方同意（workspace 與 project 設定都得開）。

Settings → Custom Approval 頁面頂端會顯示一條 banner 告訴 workspace operator 目前有效的政策（R10）：

• 若 workspace 把 disallow_self_approval_default 開了 → info banner：「workspace 層級已關閉自核，project 即使開啟 allow_self_approval 也不生效」
• 若 workspace 關了 → warning banner：「workspace 不擋，由各 project 自行決定。請到 project 頁面確認」

兩種情境的 banner 長相：

這讓 operator 讀 approval rules 時，能立刻知道現在系統處於三層哪一層的 self-approval policy 底下，而不必對著兩個 setting 反覆比對。

真實 UI 截圖：/images/screenshot-self-approval-banner-info.png / /images/screenshot-self-approval-banner-warning.png（補圖中）。

AllUsers IAM binding 在 approval 路徑

AllUsers member 在 IAM binding 上的展開行為 不適用於 approval-role 解析（R2 PR-1）。即使 workspace 某 role 被綁了 members=[allUsers]，approval runner 也不會把所有 workspace user 當成該 role 的 reviewer。

• 動機：避免 admin 不慎把 workspaceDBA（或任何高權審批 role）開放給整個 workspace
• 行為：runner 跳過 AllUsers member（轉計 argus_iam_allusers_binding_skipped_total 計數）
• 偵測：legacy workspace 還有 AllUsers binding 可從上述 metric 看見；建議改寫 binding 為具名 role
• workspace IAM 一般權限檢查（讀 / 寫資料）仍會讓 AllUsers binding 生效；只有 approval-role resolver 是例外

Override

如果 plan check 有 error、預設阻擋 Issue 建立。Workspace admin 可在 Settings → SQL Review → Allow Override 開啟有條件 override：

• 提交者須輸入理由
• 此 Issue 走升級版審批（額外加 DBA Lead step）
• override 紀錄寫進 audit log
• 審批者 UI 強烈高亮（紅色 banner）

在 UI 上

Issue 詳情頁的 Approval 區塊長相 ↓ 真實截圖見 /images/approval-state-issue-detail.png（補圖中）。

寫進 audit log 的動作

• bb.issue.approve — 含 approval_step 欄位
• bb.issue.reject — 含理由
• bb.issue.comment
• bb.setting.update — 改 WORKSPACE_APPROVAL 時（severity = notice）

相關

• Plan、Issue、Rollout
• Plan Check
• 設定：設定項 — WORKSPACE_APPROVAL
• 任務：審批一個 issue
• 安全：認證模式、Audit Log