Zeabur開源自架PaaS：pre-alpha狀態、Kubernetes權限與維運界線

先看結論：自有Kubernetes上的PaaS介面，仍是pre-alpha

zeabur-oss/zeabur 把叢集裡的Namespace、工作負載、連線及儲存等物件整理成專案與服務，提供診斷、操作預覽和管理介面。它是可自架的Kubernetes管理與部署平台，不應直接視為商業Zeabur雲端服務的完整開源複製品，也不代表主機、儲存、備份或維運變免費。[1]

查核的README明確標示pre-alpha 0.1.1、僅在少量叢集試用，警告不要指向無法承受故障的叢集。本文看的是固定提交與公開發布資訊；沒有安裝、編譯、連接kubeconfig或替Allen更換部署平台。[1]

版本狀態：main的修復不能當成已發布功能

本次取得的GitHub發布清單列出v0.1.1，且prerelease為true；發布時間為2026-10-28 17:05:21 UTC，即台北2026-10-29 01:05:21。發布說明稱它是內部測試用途、預期仍有問題的測試版本。GitHub的latest release端點回404，不能因此說完全沒有可下載版本：發布清單確實包含這個預發布版與其二進位、chart及校驗資產。[2]

固定main的CHANGELOG在Unreleased區塊記錄兩個值得留意的修復：v0.1.1沒有發布Zeabur Proxy映像，安裝VictoriaMetrics或VictoriaLogs時可能使proxy無法拉取；以及變更存取主機後OAuth redirect URI未同步的登入問題。本文沒有把這些main修復說成v0.1.1下載包已包含，也沒有實際重現故障。[3]

版本文件亦有未對齊：README／Cargo版本為0.1.1，根SECURITY.md仍描述只支持最新0.0.x。這是維護文件的一致性問題；不能據此推定0.1.1享有某個安全修補承諾。SECURITY.md也明示沒有保證回應或修補時限，1.0之前可能沒有相容遷移路徑。[1][3][4]

三種使用路徑，不是同一種風險

• 既有叢集上的本機介面：zeaburctl ui在本機隨機loopback埠提供網頁，使用啟動時選定的kubeconfig。關閉介面不等於撤銷已套用到叢集的變更；本機執行也不是唯讀模式。[1][5]
• 團隊使用：在既有Kubernetes叢集安裝Helm chart，搭配Zeabur Identity、HTTPS、API server對issuer的信任及成員RBAC。安裝文件要求Kubernetes 1.30以上，預設成員管理依賴Namespace的ValidatingAdmissionPolicy；不是把一個網頁容器啟動就完成權限整合。[6]
• 單台Linux伺服器：root安裝器可建立K3s／RKE2與所選元件。個人用途另有KubeSolo路徑，不包含相同的團隊權限與網路隔離；必須按照該路徑的限制理解，不能從低記憶體門檻推成同等安全與功能。[4][7]

個人路徑文件指出KubeSolo不執行NetworkPolicy，持有其kubeconfig者可控制整個叢集，不適合多人共用；Git或資料夾建置還需要另外選擇Builder與registry。文件的記憶體門檻只是上游安裝條件，不是本次量測的穩定負載能力。[7]

安全界線：使用者權限不代表多租戶隔離

架構設計強調以使用者身分向Kubernetes API發出讀寫，權限由RBAC及admission規則決定；不要因此把介面理解成獨立於Kubernetes的沙箱。安全文件明說整個叢集是信任邊界，沒有teams概念，互不信任的使用者應用不同叢集；同一叢集的不同專案也不防止互相設定相同域名。[5][8]

• Developer不是只有部署權：可讀取專案Secrets、修改工作負載、開容器終端，並可透過工作負載使用專案中ServiceAccount的權限。不要把管理員憑證或超出該團隊權限的ServiceAccount放進專案。
• Viewer也不是所有內容都不可見：可讀配置與工作負載設定；若直接把密碼寫進這些可讀欄位，標成Viewer不會把它藏起來。
• Admin及Node terminal：管理員登入即有整個叢集權限；Node terminal可取得主機root。不能把一般介面的Review／Apply推成終端裡每條指令都經過同樣的人類審核。
• 網路隔離有條件：文件中的專案策略是入站規則，並不預設限制所有外送；還依賴平台namespace標記與支援NetworkPolicy的CNI。不能只看UI寫著專案就宣稱彼此完全隔離。[8]

變更預覽有實質控制，但不是跨物件交易或四眼簽核