前一篇讓開發者從 Backstage 查看 todo-api 的部署現況。查詢後端只需要讀取工作負載，Operator 要更新資源，Todo API 則只處理 HTTP 請求。如果都共用管理員憑證，任一元件出問題，都可能改到不該由它管理的資源。今天用 Namespace 與角色型存取控制（Role-Based Access Control，RBAC），說明這些權限怎麼分開。
Namespace 為多數 Kubernetes 資源提供名稱與管理範圍。不同 Namespace 可以各有同名的 todo-api Deployment，所以操作時要一起確認 Namespace、資源種類與名稱。但這不會自動限制 API 存取，也不會阻止 Pod 跨 Namespace 連線。
Todo 的 Dev 環境沿用 todo Namespace，誰能操作裡面的資源仍要由 API 授權決定。Node、Namespace 本身與自訂資源定義（Custom Resource Definition，CRD）則是叢集範圍的資源，不屬於任何 Namespace。
API Server 收到請求後，先驗證身分，再檢查授權。Operator 的 Pod 透過 serviceAccountName 使用 todo 裡的 microservice-operator，完整身分是 system:serviceaccount:todo:microservice-operator。ServiceAccount 提供身分，不會自動授予管理權。
Backstage 的 Pod 在 backstage Namespace，Kubernetes plugin 卻使用 todo 裡的 backstage-k8s-reader token。程式的位置不決定 API 權限，ServiceAccount 所在的 Namespace 也不會自動限制它能存取的範圍。
目前 plugin 使用共用的查詢身分，不會把 Backstage 登入者轉成 Kubernetes 使用者。Catalog 的 owner: todo 與 label selector 都不是授權規則；誰能開啟服務頁面，要由 Backstage 的登入與 permission policy 處理。
Todo API 不需要呼叫 Kubernetes API，因此 Operator 為它產生的 Pod 設定了 automountServiceAccountToken: false，不自動掛載 API token。這不影響 BFF 的 HTTP 呼叫，也與 Operator 自己的 API 憑證無關。
Role 定義規則，RoleBinding 把規則交給身分Role 定義 Namespace 內的 API 規則，包含 API group、資源與動作；RoleBinding 將規則授予使用者、群組或 ServiceAccount。只有 Role，沒有對應的 binding，就不會因此取得權限。
例如 reader 的 RoleBinding 放在 todo，將 Role 授予 backstage-k8s-reader，允許它對指定資源執行 get、list、watch：讀取單一物件、取得清單與監看變更。
ClusterRole 可定義共用規則或叢集範圍的權限，實際範圍取決於 binding：
| 授權方式 | 生效範圍 |
|---|---|
RoleBinding 引用同 Namespace 的 Role |
binding 所在的 Namespace |
RoleBinding 引用 ClusterRole |
binding 所在 Namespace 的資源，不會因此取得叢集範圍資源的權限 |
ClusterRoleBinding 引用 ClusterRole |
規則涵蓋的資源；Namespace 範圍的規則會作用於所有 Namespace |
ClusterRole 不一定是管理員權限，也可以只定義唯讀規則。RBAC 的允許權限會累加，沒有 deny 可以抵銷其他 binding 的授權，因此不能只看其中一份受限的 RoleBinding。
Operator 與 Backstage 呼叫同一個 API Server，但使用不同身分與規則：
最小權限是只授予完成工作需要的能力。沿著目前的交付流程，各元件的責任如下：
| 元件或身分 | 工作需要的能力 | 要留意的界線 |
|---|---|---|
| Todo API | 處理 HTTP 請求 | 不需要 Kubernetes API 權限 |
microservice-operator |
處理自訂資源（Custom Resource，CR）、回寫 status、管理工作負載並觀察健康 |
授權範圍是 todo，不只 todo-api |
| Argo CD | 讀取 Git 設定並同步目標資源 | 需要 Argo CD 設定與 Kubernetes 授權共同限制 |
backstage-k8s-reader |
唯讀查詢指定種類的資源 | selector 不會縮小 API 權限 |
| Backstage 模板後端 | 產生設定並提出 Git Pull Request（PR） | Git 權限不等於 Kubernetes 權限 |
Operator 的 Deployment、Service 寫入權涵蓋整個 todo Namespace。程式雖然用 ownerReferences 檢查所有權、避免覆寫外部同名資源，但這是程式保護，不是 RBAC 的逐服務隔離。
Argo CD 的 AppProject 限制 Git 來源、部署目的地與資源種類，RBAC 則限制同步身分的 API 操作。目前 Todo project 固定了 repository 與 todo 目的地，但允許所有 Namespace 範圍的資源種類，另允許 Namespace 資源，仍不是完整的最小權限設計。
依現有 Operator 與 reader 的 Role／RoleBinding，若沒有其他授權，預期結果如下，並非本次叢集實測：
| 身分與 API 動作 | 預期結果 | 依據 |
|---|---|---|
Operator 更新 todo 的 Deployment |
允許 | 有 deployments 的 update |
Operator 更新 default 的 Deployment |
不允許 | 現有 binding 只授予 todo 範圍的規則 |
Operator 讀取 todo 的 Secret |
不允許 | Role 沒有 secrets 的讀取規則 |
Backstage reader 列出 todo 的 Pod |
允許 | 有 pods 的 list |
Backstage reader 更新 todo 的 Deployment |
不允許 | 只有唯讀動作 |
Backstage reader 讀取 todo 的 Microservice |
不允許 | 尚未授予這種 CR 的讀取權 |
遇到 Forbidden 時，要核對請求身分、資源、動作與適用的 binding。自己的管理員憑證查得到，不代表 plugin 也能查到，不應直接補上管理員權限。
RBAC 不檢查 BFF 呼叫 Todo API 的 HTTP 請求，也不限制 CPU 或記憶體。Pod 間的連線範圍要另外設定 NetworkPolicy，並確認叢集網路實作支援；Namespace 的資源總額可用 ResourceQuota，container 的資源需求與限制則由 requests／limits、LimitRange 處理。
這些機制不會隨 Namespace 自動啟用。共用 Namespace 或 Node 時，還要考慮資源競爭與容器執行權限，不能因個別元件已有有限的 API 授權，就認定團隊隔離已完成。
身分有權建立 Deployment，也不代表設定符合平台要求。下一篇會用 Gatekeeper 說明資源政策如何檢查這些內容。
iThome鐵人賽
看影片追技術