權限
對照成員角色、管理員帳號與 Kubernetes RBAC，確認每項操作的存取範圍和登入能維持多久。
看得到專案卻讀不到日誌時，先確認自己在這個專案的角色：檢視者只能看狀態和事件，開發者才能讀日誌、讀 Secret 和部署。Zeabur 用你自己的身分呼叫 kube-apiserver，能不能做由 Kubernetes RBAC 決定。
設定成員角色的步驟見成員。用本機 zeaburctl ui 時，權限就是 kubeconfig 的權限。下面的成員角色由 Helm chart 提供，管理員邀請成員時綁定。
| 操作 | 檢視者 | 開發者 |
|---|---|---|
| 看服務狀態、事件、一般設定檔與磁碟區資訊 | 可 | 可 |
| 看資料庫、備份與建置的狀態 | 可 | 可 |
| 讀取 Pod 日誌與日誌歷史紀錄 | 無 | 可 |
| 看用量歷史紀錄（要開啟 Zeabur Proxy） | 可 | 可 |
| 讀取與修改 Secret | 無 | 可 |
| 新增、修改、刪除工作負載與 Kubernetes Service | 無 | 可 |
| 改副本數、重新啟動服務 | 無 | 可 |
| 修改公開網域、HTTPRoute 與 NetworkPolicy | 無 | 可 |
| 新增或修改磁碟區 | 無 | 可 |
| 建立資料庫、物件儲存與支援的備份設定 | 無 | 可 |
| 從 Git 部署、重新建置 | 無 | 可 |
| 開啟容器終端機、加入除錯容器 | 無 | 可 |
| 修改專案顯示名稱、描述與圖示 | 無 | 可 |
| 建立／刪除 Namespace、把 Namespace 加入或移出 Zeabur | 無 | 無 |
| 修改角色與成員存取權、節點、叢集元件 | 無 | 無 |
| 從磁碟區的備份還原（K8up） | 無 | 可 |
| 設定叢集備份、從叢集備份還原 | 無 | 無 |
標示「可」的操作仍要通過 ResourceQuota、Pod Security、admission policy 和元件自己的檢查。資料庫和備份要先裝好對應的 operator 才能建立。角色已經先列好這些 operator 的資源，裝好後不用改角色。
開發者可以在自己的專案裡還原磁碟區，角色只多了該 Namespace 內 restores.k8up.io 的建立與刪除權限。使用前請注意兩件事：
- 還原到原處會覆蓋整個磁碟區，備份之後新增的檔案會被刪除。
- 能還原的人，就能讀取這個專案備份倉庫裡的所有備份。每個專案請用各自的備份路徑和密碼。
叢集備份由 Velero 執行，還原時 Velero 用自己的權限（預設是 cluster-admin）把物件寫回 Restore 指定的 Namespace，包括 RoleBinding 和 Secret。RBAC 只能決定誰能建立 Restore，不能限制它寫進哪些 Namespace，所以成員角色沒有任何 velero.io 權限，還原只開放給管理員。沒有權限建立 Restore 的人，還原 按鈕無法使用。
管理員用的是管理員帳號，登入後就有整個叢集的完整權限，不用再另外確認，見下方管理員帳號和一般帳號。介面依你實際擁有的 RBAC 規則顯示能做的操作，所以另外綁定的規則、管理員改過的 ClusterRole 都會反映出來。
Chart 建立什麼
Section titled “Chart 建立什麼”Chart 的 memberRoles.enabled 預設是 true，會建立：
zeabur-member：讀取節點、Namespace、StorageClass，以及知道名稱的 PersistentVolume。每位成員都看得到所有 Namespace 的名稱和 annotations，所以專案描述裡不要放機密。zeabur-project-viewer、zeabur-project-developer：專案角色，用zeabur.com/aggregate-to-<role>標籤聚合規則。zeabur-project-viewer-rules、zeabur-project-developer-rules、zeabur-project-builds-read、zeabur-project-builds-write：上面兩個角色實際的 verb 和 resource。檢視者看得到建置，開發者還能從 Git 部署和重新建置。zeabur-project-namespaceValidatingAdmissionPolicy 和它的 binding：限制開發者能改 Namespace 的哪些欄位，需要 Kubernetes 1.30 以上。
Chart 本身不綁定任何人。管理員在 Zeabur 邀請或變更成員時，Zeabur 用管理員的權限建立：
| 物件 | 範圍與內容 |
|---|---|
ClusterRoleBinding zeabur-member-<username> | 綁定 zeabur-member 給 zeabur:<username> |
各專案中的 RoleBinding zeabur-member-<username> | 綁定該專案的 developer 或 viewer 角色給同一位使用者 |
這些 binding 帶 zeabur.com/member: <username> 和 app.kubernetes.io/managed-by: zeabur 標籤。zeabur-installer uninstall 會一起刪掉它們。用 helm uninstall 移除時要自己刪，見移除後的權限。
關閉 memberRoles.enabled 時，chart 不建立這些角色和 Namespace 政策，邀請成員時只能選要不要給 管理員。
專案 Namespace 的保護
Section titled “專案 Namespace 的保護”開發者要有 patch namespaces 才能改專案名稱、描述和圖示，但 RBAC 不能把 patch 限制在個別欄位，所以 chart 用 zeabur-project-namespace 政策把開發者能改的範圍限制在三個 annotation：
zeabur.com/display-namezeabur.com/descriptionzeabur.com/icon其他 annotation、所有 label、finalizers、ownerReferences 和 spec，開發者都不能改。決定 Pod Security 等級和 NetworkPolicy 選取範圍的 label 也在其中。
對該 Namespace 有 zeabur-manage 權限，或對所有 Namespace 有 patch／update 權限的人，不受這項限制。所以把既有 Namespace 加入或移出 Zeabur，都要由管理員或有這些額外權限的人來做。
開發者能接觸哪些機密
Section titled “開發者能接觸哪些機密”開發者角色不能寫入 RBAC 物件和 ServiceAccount，也沒有 bind、escalate、impersonate、nodes/proxy 或 service／pod proxy 權限，所以不能自己擴大權限。實際能做到什麼，還要看專案裡既有的 ServiceAccount 有哪些權限。
檢視者讀不到 Secret 和日誌，但讀得到 ConfigMap 和工作負載的設定。直接寫在這些地方的密碼，檢視者也看得到。
管理員帳號和一般帳號
Section titled “管理員帳號和一般帳號”Zeabur Identity 的帳號分成兩種。在 成員 把某人設為 管理員，他的帳號就會變成管理員帳號；拿掉 管理員，就改回一般帳號。
| 一般帳號 | 管理員帳號 | |
|---|---|---|
| 登入方式 | Zeabur Identity 開放的每一種：通行密鑰，以及有設定的 GitHub、Google | 只能用通行密鑰 |
| 權限 | 成員頁給的專案角色，加上另外綁定的 RBAC 規則 | 整個叢集的完整權限：權杖帶 admins 群組，綁定 cluster-admin |
管理員帳號登入後就能做任何事，中間沒有再確認的步驟。所以管理員最好另外有一個一般帳號處理日常工作，只有要改叢集、管理成員時才用管理員帳號登入。Zeabur 沒有 sudo 模式，管理員帳號本身就是這道關卡；要更嚴格，可以開啟下方的 AAL3。
一般帳號權限不夠時，畫面會說需要更多權限，並列出缺少的規則。把它交給管理員，請他調整你的角色或幫你處理。
把成員設為 管理員 後，他之後只能用通行密鑰登入，原本用 GitHub 或 Google 登入的工作階段會在下次換權杖時結束。已經發出的權杖在到期前仍然有效，最多 5 或 10 分鐘。
第一位管理員來自安裝時的設定連結（zeabur-identityctl setup-link）。在命令列也能邀請管理員，或改變既有帳號的類型：
zeabur-identityctl invite --username alice --adminzeabur-identityctl account-type alice admin # 改回一般帳號：regularadmins 群組只能從帳號類型取得，Zeabur Identity 不接受把它寫進使用者的 groups。細節見 Zeabur Identity 的管理員帳號。
登入能維持多久
Section titled “登入能維持多久”一般帳號閒置 1 小時就要重新登入。管理員帳號也是 1 小時，但設定為多個團隊或開啟 AAL3 時縮短為 15 分鐘。不管有沒有在用，登入 12 小時後都要重新登入。
| 帳號 | 權杖有效時間 | 閒置多久後結束 | 最長 |
|---|---|---|---|
| 一般帳號 | 10 分鐘 | 1 小時 | 登入後 12 小時 |
| 管理員帳號，一個團隊 | 5 分鐘 | 1 小時 | 登入後 12 小時 |
| 管理員帳號，多個團隊或開啟 AAL3 | 5 分鐘 | 15 分鐘 | 登入後 12 小時 |
權杖到期時 Zeabur 會自己換新的，不用再按通行密鑰。12 小時從用通行密鑰、GitHub 或 Google 登入那一刻算起，換權杖不會延長。Zeabur 網頁的閒置上限是 1 小時，Zeabur Identity 給的時間比較短時就照它的。
開著頁面不操作不算在用。超過 60 秒沒有操作，頁面自動更新狀態的請求就不算活動，閒置時間照算。
終端機有在用就會一直開著，閒置 15 分鐘後關閉。
設定 頁的 登入設定 只影響管理員帳號，一般帳號不受影響。設定存在 Zeabur Identity 所在 Namespace 的 ConfigMap zeabur-identity-settings，Zeabur Identity 每次登入和換權杖時讀取，不用重新啟動。
| 設定 | ConfigMap 的鍵和值 | 預設 | 作用 |
|---|---|---|---|
| 團隊 | teams：single 或 multiple | single，一個團隊 | 多個團隊時，管理員帳號閒置 15 分鐘就結束。 |
| AAL3 | admin-aal3：false 或 true | false，關閉 | 管理員帳號只接受不會同步的通行密鑰，閒置 15 分鐘就結束。 |
安裝時不知道叢集是一個團隊在用還是多個團隊共用，所以一律從一個團隊開始。一個團隊的叢集，管理員通常就是唯一在用的人，閒置時間和一般帳號一樣。多個團隊共用叢集時，記得改成多個團隊。
這兩項沒有 Helm value，因為 Zeabur Identity 不在 Zeabur 的 chart 裡。在 設定 頁改，或用 kubectl 改同一個 ConfigMap：
kubectl -n zeabur-identity create configmap zeabur-identity-settings --from-literal=teams=multiplekubectl -n zeabur-identity patch configmap zeabur-identity-settings --type merge -p '{"data":{"teams":"single"}}'沒有這個 ConfigMap 或沒有某個鍵時用預設值。寫了 Zeabur Identity 看不懂的值，就當成比較嚴格的那一個（multiple 或 true）。
只接受不會同步的通行密鑰（AAL3）
Section titled “只接受不會同步的通行密鑰（AAL3）”開啟 AAL3 後，管理員帳號只能用不會同步到其他裝置的通行密鑰，例如安全金鑰，或只存在一台裝置上的通行密鑰。存在 iCloud 鑰匙圈、Google 密碼管理工具這類會同步的通行密鑰，登入時會被拒絕，畫面會直接說這把通行密鑰會同步、管理員帳號要用安全金鑰或只存在一台裝置上的通行密鑰。已經用會同步的通行密鑰登入的人，下次換權杖時就會被登出。
NIST SP 800-63B-4 規定會同步的通行密鑰最高只到 AAL2，不會同步的才可能達到 AAL3。通行密鑰會不會同步，是驗證器自己回報的（WebAuthn 的 backup eligibility 旗標，BE）。Zeabur Identity 不要求 attestation，所以沒有人驗證這個回報是真的。AAL3 能擋掉會同步的通行密鑰，但不能證明金鑰存在什麼硬體裡。
開啟前，先確認每位管理員都有不會同步的通行密鑰。你自己沒有的話，Zeabur 不會讓你開啟，避免把自己鎖在外面。其他沒有的管理員開啟後就登不進來，要用 zeabur-identityctl setup-link --username <管理員> --reset 產生新連結，讓他註冊安全金鑰。檢查每把通行密鑰的方式見 Zeabur Identity 的 AAL3 for admins。
用 kubectl 操作
Section titled “用 kubectl 操作”管理員帳號和一般帳號的 kubeconfig 都是一般的 kubelogin（oidc-login）context，靠 refresh token 換新權杖，直接下 kubectl 指令就好，不會每幾分鐘要你按一次通行密鑰。期限和上面的表一樣。
kubectl 沒有額外的確認步驟。管理員帳號在 kubectl 的保護，只有通行密鑰登入和上面的時間限制。
kubelogin 預設把 refresh token 存在 ~/.kube/cache/oidc-login。不想把它留在磁碟上，在 context 的 exec 參數加上：
--token-cache-storage=keyring：存進作業系統的鑰匙圈。--token-cache-storage=none：什麼都不存，每個 kubectl 指令都會開登入頁。
設定 kubeconfig 的步驟見 Zeabur Identity 的入門。
用 kubectl 確認權限
Section titled “用 kubectl 確認權限”以同一份 kubeconfig 檢查自己的權限：
kubectl auth can-i --list --namespace shopkubectl auth can-i get pods --namespace shopkubectl auth can-i get pods/log --namespace shopkubectl auth can-i create pods/exec --namespace shopkubectl auth can-i patch deployments.apps --namespace shopZeabur 用 SelfSubjectRulesReview 判斷介面上該顯示哪些操作。叢集回傳的規則不完整時，Zeabur 不確定你能不能做，會讓套用前的 dry run 決定。被政策或用量上限拒絕時，要修正政策指出的條件。管理員帳號也一樣要通過 admission policy。