使用 RBAC，於 Kubernetes v1.8 中正式發佈

編輯註記： 這篇文章是關於 Kubernetes 1.8 新功能的系列深入文章的一部分。

Kubernetes 1.8 代表角色型存取控制 (RBAC) 授權器的一個重要里程碑，其在此版本中已升級為正式發布 (GA)。RBAC 是一種控制 Kubernetes API 存取權限的機制，自 1.6 版本推出 beta 版以來，許多 Kubernetes 叢集和佈建策略預設已啟用它。

展望未來，我們預期 RBAC 將成為保護 Kubernetes 叢集的基本建構區塊。這篇文章探討如何使用 RBAC 來管理使用者和應用程式對 Kubernetes API 的存取權限。

授予使用者存取權限

RBAC 是使用標準 Kubernetes 資源進行配置的。使用者可以透過繫結 (ClusterRoleBindings 和 RoleBindings) 繫結至一組角色 (ClusterRoles 和 Roles)。使用者一開始沒有任何權限，必須由管理員明確授予存取權限。

所有 Kubernetes 叢集都會安裝一組預設的 ClusterRoles，代表使用者可以放入的常見類別。「edit」角色讓使用者執行基本動作，例如部署 pod；「view」讓使用者觀察非敏感資源；「admin」允許使用者管理命名空間；而「cluster-admin」授予管理叢集的存取權限。

$ kubectl get clusterroles

NAME            AGE

admin           40m

cluster-admin   40m

edit            40m

# ...


view            40m

ClusterRoleBindings 授予使用者、群組或服務帳戶在整個叢集中的 ClusterRole 權限。使用 kubectl，我們可以讓範例使用者「jane」透過將她繫結至「edit」ClusterRole，在所有命名空間中執行基本動作

$ kubectl create clusterrolebinding jane --clusterrole=edit --user=jane

$ kubectl get namespaces --as=jane

NAME          STATUS    AGE

default       Active    43m

kube-public   Active    43m

kube-system   Active    43m

$ kubectl auth can-i create deployments --namespace=dev --as=jane

yes

RoleBindings 在命名空間內授予 ClusterRole 的權限，讓管理員能夠管理在整個叢集中重複使用之 ClusterRoles 的中央清單。例如，當新資源新增至 Kubernetes 時，預設的 ClusterRoles 會更新，以自動授予 RoleBinding 主體在其命名空間內的正確權限。

接下來，我們將讓「infra」群組修改「dev」命名空間中的資源

$ kubectl create rolebinding infra --clusterrole=edit --group=infra --namespace=dev

rolebinding "infra" created

由於我們使用了 RoleBinding，因此這些權限僅適用於 RoleBinding 的命名空間內。在我們的案例中，「infra」群組中的使用者可以檢視「dev」命名空間中的資源，但不能檢視「prod」中的資源

$ kubectl get deployments --as=dave --as-group=infra --namespace dev

No resources found.

$ kubectl get deployments --as=dave --as-group=infra --namespace prod

Error from server (Forbidden): deployments.extensions is forbidden: User "dave" cannot list deployments.extensions in the namespace "prod".

建立自訂角色

當預設的 ClusterRoles 不夠用時，可以建立定義一組自訂權限的新角色。由於 ClusterRoles 只是常規 API 資源，因此它們可以表示為 YAML 或 JSON manifest，並使用 kubectl 套用。

每個 ClusterRole 都包含一個權限清單，指定「規則」。規則純粹是累加的，並允許對一組資源執行特定的 HTTP 動詞。例如，以下 ClusterRole 擁有對「deployments」、「configmaps」或「secrets」執行任何動作以及檢視任何「pod」的權限

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

 name: deployer

rules:

- apiGroups: ["apps"]

 resources: ["deployments"]

 verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]



- apiGroups: [""] # "" indicates the core API group

 resources: ["configmaps", "secrets"]

 verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]



- apiGroups: [""] # "" indicates the core API group

 resources: ["pods"]

 verbs: ["get", "list", "watch"]

動詞對應於請求的 HTTP 動詞，而資源和 API 群組指的是正在引用的資源。請考慮以下 Ingress 資源

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

 name: test-ingress

spec:

 backend:

   serviceName: testsvc

   servicePort: 80

若要 POST 資源，使用者需要以下權限

rules:

- apiGroups: ["extensions"] # "apiVersion" without version

 resources: ["ingresses"]  # Plural of "kind"

 verbs: ["create"]         # "POST" maps to "create"

應用程式的角色

當部署需要存取 Kubernetes API 的容器時，最佳實務是隨應用程式 manifest 一起發布 RBAC Role。除了確保您的應用程式在啟用 RBAC 的叢集上運作之外，這也有助於使用者稽核您的應用程式將在叢集上執行的動作，並考量其安全性影響。

命名空間 Role 通常更適合應用程式，因為應用程式傳統上在單一命名空間內執行，而命名空間的資源應與應用程式的生命週期相關聯。但是，Role 無法授予對非命名空間資源 (例如節點) 或跨命名空間的存取權限，因此某些應用程式可能仍然需要 ClusterRoles。

以下 Role 允許 Prometheus 實例監控和探索「dev」命名空間中的服務、端點和 pod

kind: Role

metadata:

 name: prometheus-role

 namespace: dev

rules:

- apiGroups: [""] # "" refers to the core API group

 Resources: ["services", "endpoints", "pods"]

 verbs: ["get", "list", "watch"]

在 Kubernetes 叢集中執行的容器接收服務帳戶憑證以與 Kubernetes API 通訊，並且服務帳戶可以作為 RoleBinding 的目標。Pod 通常以「預設」服務帳戶執行，但最佳實務是讓每個應用程式都以唯一的服務帳戶執行，這樣 RoleBindings 才不會意外地將權限授予其他應用程式。

若要使用自訂服務帳戶執行 pod，請在相同的命名空間中建立 ServiceAccount 資源，並指定 manifest 的 serviceAccountName 欄位。

apiVersion: apps/v1beta2 # Abbreviated, not a full manifest

kind: Deployment

metadata:

 name: prometheus-deployment

 namespace: dev

spec:

 replicas: 1

 template:

   spec:

     containers:

     - name: prometheus

       image: prom/prometheus:v1.8.0

       command: ["prometheus", "-config.file=/etc/prom/config.yml"]

   # Run this pod using the "prometheus-sa" service account.

   serviceAccountName: prometheus-sa

---

apiVersion: v1

kind: ServiceAccount

metadata:

 name: prometheus-sa

 namespace: dev

參與其中

RBAC 的開發是透過授權特殊興趣小組（維護 Kubernetes 的眾多 SIG 之一）組織的社群工作。參與 Kubernetes 社群的一個好方法是加入符合您興趣的 SIG、提供意見反應，並協助制定藍圖。

關於作者

Eric Chiang 是軟體工程師，也是 CoreOS（企業級 Kubernetes 平台 Tectonic 的建立者）的 Kubernetes 開發技術主管。Eric 共同領導 Kubernetes SIG Auth，並代表 CoreOS 維護多個開放原始碼專案和程式庫。

• ←上一篇
下一篇→