基於角色的存取控制

在 Kubernetes 中，授與使用者或特定應用程式的服務帳戶角色，是確保應用程式在您指定的作用範圍內運作的最佳實務做法。在 官方 Kubernetes 文件 中進一步了解服務帳戶權限。

從 Kubernetes 1.6 起，預設啟用基於角色的存取控制。RBAC 讓您能根據使用者及其在組織中的角色，指定哪些類型的動作被允許。

使用 RBAC，您可以

• 授與管理員特權作業（建立群集範圍資源，例如新增角色）
• 限制使用者建立資源（Pod、持久儲存空間、部署）的能力到特定命名空間，或限制在群集範圍內（資源配額、角色、自訂資源定義）
• 限制使用者檢視資源的能力到特定命名空間或在群集範圍內。

本指南適用於想要限制使用者與 Kubernetes API 互動範圍的管理員。

管理使用者帳戶

所有 Kubernetes 群集都有兩個類別的使用者：由 Kubernetes 管理的服務帳戶和一般使用者。

一般使用者假設由外部的獨立服務來管理。管理員會分發私鑰、使用類似的 Keystone 或 Google 帳戶使用者儲存空間，甚至使用包含使用者名稱和密碼清單的檔案。在此方面，Kubernetes 沒有代表一般使用者帳戶的物件。無法透過 API 呼叫將一般使用者新增到群集。

相比之下，服務帳戶是由 Kubernetes API 管理的使用者。它們與特定命名空間綁定，並且會由 API 伺服器自動建立，或透過 API 呼叫手動建立。服務帳戶會連結到儲存為機密的憑證組，並掛載到 Pod 中，允許群集內程序與 Kubernetes API 對話。

API 要求會綁定至一般使用者或服務帳戶，或視為匿名要求。這表示，群集內外每個處理程序，從工作站上輸入 kubectl 的人工使用者，到節點上的 kubelet，再到控制平面的成員，在向 API 伺服器提出要求時，都必須認證，或被視為匿名使用者。

角色、群集角色、角色繫結和群集角色繫結

在 Kubernetes 中，使用者帳戶和服務帳戶只能檢視和編輯已獲得存取權限的資源。此存取權限是透過角色和角色繫結予以授與。角色和角色繫結會繫結至特定命名空間，授予使用者檢視和/或編輯角色所提供存取權限的命名空間內資源的能力。

在群集範圍，這些稱為群集角色和群集角色繫結。授予使用者群集角色會授予他們檢視和/或編輯整個群集的資源。檢視和/或編輯群集範圍（命名空間、資源配額、節點）的資源也需要這樣做。

群集角色可透過角色繫結中的參照，繫結至特定命名空間。admin、edit 和 view 預設群集角色通常就是用這種方式。

以下是 Kubernetes 中預設提供的幾個群集角色。它們旨在是使用者面對角色。其中包括超級使用者角色（cluster-admin），以及具有較精細存取權限的角色（admin、edit、view）。

使用 RBAC 限制使用者帳戶的存取權

現在我們了解了基於角色的存取控制的基本原理，讓我們來討論管理員如何限制使用者的存取範圍。

範例：授予使用者特定命名空間的讀取/寫入存取權限

為限制使用者存取特定命名空間，我們可以使用 edit 或 admin 角色。如果您的圖表建立或與角色和角色繫結互動，您將需要使用 admin 集群角色。

此外，您也可以建立具有 cluster-admin 存取權的 RoleBinding。在命名空間範圍授予使用者 cluster-admin 存取權可以完全控制命名空間中的每個資源，包括命名空間本身。

在此範例中，我們將建立具有 edit 角色的使用者。首先，建立命名空間

$ kubectl create namespace foo

現在，在該命名空間中建立一個 RoleBinding，授予使用者 edit 角色。

$ kubectl create rolebinding sam-edit
    --clusterrole edit \​
    --user sam \​
    --namespace foo

範例：授予使用者在叢集範圍內讀寫權限

如果使用者希望安裝安裝叢集範圍資源（命名空間、角色、自訂資源定義等）的圖表，他們將需要叢集範圍寫入權限。

為此，請授予使用者 admin 或 cluster-admin 存取權。

授予使用者 cluster-admin 存取權會授予他們存取 Kubernetes 中所有可用的資源，包括使用 kubectl drain 和其他管理任務的節點存取權限。強烈建議考慮改為提供使用者 admin 存取權，或建立一個根據他們的需求量身打造的客製化叢集角色。

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \​
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam

範例：授予使用者對特定命名空間的唯讀權限

您可能注意到沒有可供查看機密的 ClusterRole。由於升級問題，view ClusterRole 並不會授予使用者對機密的讀取權限。Helm 預設將發佈資料儲存在機密中。

使用者必須能夠讀取這些機密才能執行 helm list。基於此，我們將建立一個特殊的 secret-reader ClusterRole。

建立檔案 cluster-role-secret-reader.yaml，並將下列內容寫入檔案中

apiVersion: rbac.authorization.k8s.io/v1​
kind: ClusterRole​
metadata:​
  name: secret-reader​
rules:​
- apiGroups: [""]​
  resources: ["secrets"]​
  verbs: ["get", "watch", "list"]

然後，使用下列指令建立 ClusterRole

$ kubectl create -f clusterrole-secret-reader.yaml​

完成後，我們可以授予使用者對大多數資源的讀取權限，然後再授予他們對機密的讀取權限

$ kubectl create namespace foo

$ kubectl create rolebinding sam-view
    --clusterrole view \​
    --user sam \​
    --namespace foo

$ kubectl create rolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam \​
    --namespace foo

範例：授予使用者在叢集範圍內唯讀權限

在某些情況下，授予使用者叢集範圍存取權可能會很有用。例如，如果使用者想要執行命令 helm list --all-namespaces，API 要求使用者擁有叢集範圍讀取權限。

為此，請按照上述說明授予使用者 view 和 secret-reader 存取權，但使用 ClusterRoleBinding。

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \​
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam

其他想法

上述範例使用了 Kubernetes 提供的預設 ClusterRoles。有關使用者獲准存取哪些資源的更精細控制，請參閱 Kubernetes 文件，瞭解如何建立自己的客製化角色和 ClusterRoles。