Argus

Appearance

SQL Editor ​

對應主管要求 ① 全公司 SQL 變更審計 + ② 零信任 + ③ DBA SOP 內建。

SQL Editor 是 Argus 給「不走 Plan 流程的互動 SQL」唯一受審計的入口。每一次查詢、每一次匯出、每一個管理命令，都會留下 audit 軌跡與規則合規檢查紀錄。

是什麼 ​

SQL Editor 是平台內建的線上 SQL 介面，提供三條互動執行路徑：

路徑RPC用途典型場景
Queryargus.v1.SQLService/Query跑 SELECT，回傳 rows開發者查資料、Auditor 對帳、DBA 調查問題
AdminExecuteargus.v1.SQLService/AdminExecuteDBA 模式直接執行 DDL / DML（streaming）緊急救火、特殊運維
Exportargus.v1.SQLService/Export跑 SELECT → 直接出 CSV / JSON / SQL / XLSX報表匯出、稽核取證

三條路徑共用同一套權限、masking、advisor、audit 機制。差別只在 streaming 模式（AdminExecute）與輸出形式（Export）。

為什麼存在 ​

痛點SQL Editor 怎麼解
開發者要查資料就要 ssh / psql 直連 → 沒 audit、沒 masking把所有互動 SQL 收口到平台
DBA 緊急場景要繞 Plan 流程 → 失去軌跡AdminExecute 模式保留審計但不卡 Plan
個別 client 工具不會跑公司 lint 規則Plan / Release / Issue 已跑的 advisor 規則庫，現在互動 path 也跑（A2 PR-1）
報表匯出散落多個工具Export RPC 統一輸出

三道保護機制 ​

每一次互動執行同時通過：

各機制 fail-open / fail-close 行為：

機制違規時為何這樣
IAM / ACLblock沒權限就不能跑
Masking遮蔽欄位（不 block）讓「能看部分資料」的角色仍可工作
Advisor記錄但不 block（observable-only）A2 PR-1 起跑兩週 soak，PR-2 才考慮 block
Audit log永遠寫即使後續所有檢查 fail 也要留軌跡

Advisor on Query — 互動 path 違規偵測（A2 PR-1） ​

歷史上 Argus 的 280+ 條 advisor 規則只跑在 Plan / Release / Issue 批次審批流程。自 A2 PR-1 起，互動 path（Query / AdminExecute / Export）也跑同一套規則，但走 observable-only 模式：

表面顯示位置受益對象
Result panel banner跑 query 後立刻彈出，折疊式，展開看每條規則跑 query 的人本人
HistoryPane badge每筆歷史記錄旁邊一個數字 chip跑 query 的人 + workspace admin
audit_log rowmethod='/argus.v1.SQLService/AdvisorViolation'Auditor、workspace admin
query_history.payload.rule_violations[]可 CEL filter rule_violation_count > 0同上
Prometheus counterargus_sql_advisor_violation_total{rule_type,severity,query_path}Ops、SRE

詳見 Advisor 違規查詢 SOP（auditor 角度）與 Plan Check（批次流程角度的同一套規則庫）。

ACL — 三層 binding 串接 ​

SQL Editor 的查詢權限由三層 IAM 串接決定：

三層為 AND 關係：任一層不通過，請求被拒。

場景需要的 IAM
只跑 SELECTprojectQuerier 或 projectOwner（含 SQL Editor）
跑 AdminExecuteprojectOwner + database admin data source 有 mapping
ExportprojectQuerier + 該 environment 的 disable_export policy 沒擋

Workspace IAM 的詳情：指派角色與權限。

Masking — 欄位級遮蔽 ​

Sensitive Data policy 在 driver 拿到 row 之後、回傳給 client 之前套用：

  • 規則 hierarchy：workspace → project → database → table → column
  • 行為：value 被替換為 mask 樣式（***、xxx@***、保留前 N 後 M 等）
  • 預設：保守（policy 越上層越嚴，可由下層放寬）

細節：Sensitive Data 操作。

Query Restriction Policy ​

Workspace / project 可設定查詢限額：

設定行為
maximum_result_size查詢回傳超過 size cap → truncate + UI 顯示「超出限制」banner
maximum_result_rows同上但以 row 數計
max_query_timeout_seconds超時 → 中斷 + slog 記錄
disable_export阻擋 Export RPC
disable_copy_data阻擋前端結果 copy（UI 端）

細節：Settings 參考。

跟 Plan 流程的關係 ​

SQL Editor 不是 Plan 的替代品 — 兩者目的不同：

SQL EditorPlan
場景探索、查資料、緊急救火正式變更
流程即時執行Plan → Issue → Approval → Rollout → Task → TaskRun
審批沒有（IAM 即決）必經審批
Advisor跑但不 block跑且依嚴重度 block
回滾自負平台支援 Revision rollback
Audit每次都記每階段都記

規則：能走 Plan 就走 Plan。SQL Editor 是「Plan 流程不適用」的場景的補強，不是繞道。

在 UI 上 ​

  • 左下 sidebar → SQL Editor
  • 左欄 schema tree：點 database → 展開 schema → table → 欄位
  • 中間 editor：Monaco（含 SQL 補全 + lint）
  • 右欄：歷史記錄（含 violation badge）、worksheet 收藏、masking 規則提示

跟 Schema Drift Detection 的關係 ​

AdminExecute 跑 DDL 後，Schema Drift Detection runner 會在 10 分鐘內偵測到 DB 真實 schema 跟 Plan-blessed baseline 不一致，自動寫一筆 drift event。

狀況結果
DBA 跑了 DDL 並在 24h 內補 retroactive PlanPlan 通過 → TaskRun 自動祝福新 baseline → drift event 不再出現
DBA 跑了 DDL 沒補單drift event 一直留著被 auditor 看到 → 月底 compliance report 列 finding
Auditor 對 drift event 按「Trigger Re-check」確認狀態寫一筆 TriggerDriftCheck audit_log（actor=auditor）

這是 Argus 把「事前合規」（advisor on Plan）跟「事後可審計」（drift detection）兩條防線收口的關鍵點。

限制 / 已知設計 ​

  • AdminExecute 在 mobile 版限制 streaming（network drop 容易斷）— 用 desktop 或 Plan 路徑
  • Query 超 timeout 會中斷但已執行的 side effect 不會 rollback（這是 driver 行為）
  • Plan check / advisor 規則庫的調整影響的是新查詢，已執行的不會重判

相關 ​

Argus — 公司內部資料庫變更審計平台