原標題：

RBAC Support in Kubernetes

Kubernetes 中的 RBAC 支援

PS：在Kubernetes1.6版本中新增角色訪問控制機制（Role-Based Access，RBAC）讓叢集管理員可以針對特定使用者或服務賬號的角色，進行更精確的資源訪問控制。在RBAC中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中，角色是為了完成各種工作而創造，使用者則依據它的責任和資格來被指派相應的角色，使用者可以很容易地從一個角色被指派到另一個角色。

RBAC vs ABAC

目前 Kubernetes 中有一系列的鑑權機制。

https://kubernetes.io/docs/admin/authorization/

鑑權的作用是，決定一個使用者是否有權使用 Kubernetes API 做某些事情。它除了會影響 kubectl 等元件之外，還會對一些執行在叢集內部並對叢集進行操作的軟體產生作用，例如使用了 Kubernetes 外掛的 Jenkins，或者是利用 Kubernetes API 進行軟體部署的 Helm。ABAC 和 RBAC 都能夠對訪問策略進行配置。

ABAC（Attribute Based Access Control）本來是不錯的概念，但是在 Kubernetes 中的實現比較難於管理和理解（怪我咯），而且需要對 Master 所在節點的 SSH 和檔案系統許可權，而且要使得對授權的變更成功生效，還需要重新啟動 API Server。

而 RBAC 的授權策略可以利用 kubectl 或者 Kubernetes API 直接進行配置。RBAC 可以授權給使用者，讓使用者有權進行授權管理，這樣就可以無需接觸節點，直接進行授權管理。RBAC 在 Kubernetes 中被對映為 API 資源和操作。

因為 Kubernetes 社群的投入和偏好，相對於 ABAC 而言，RBAC 是更好的選擇。

基礎概念

需要理解 RBAC 一些基礎的概念和思路，RBAC 是讓使用者能夠訪問 Kubernetes API 資源的授權方式。

在 RBAC 中定義了兩個物件，用於描述在使用者和資源之間的連線許可權。

角色

角色是一系列的許可權的集合，例如一個角色可以包含讀取 Pod 的許可權和列出 Pod 的許可權， ClusterRole 跟 Role 類似，但是可以在叢集中到處使用（ Role 是 namespace 一級的）。

角色繫結

RoleBinding 把角色對映到使用者，從而讓這些使用者繼承角色在 namespace 中的許可權。ClusterRoleBinding 讓使用者繼承 ClusterRole 在整個叢集中的許可權。

關於 RoleBinding 和 ClusterRoleBinding： https://kubernetes.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding

Kubernetes 中的 RBAC

RBAC 現在被 Kubernetes 深度整合，並使用他給系統元件進行授權。系統角色 (System Roles) 一般具有字首system:，很容易識別：

➜  kubectl get clusterroles --namespace=kube-system
NAME                    KIND
admin                   ClusterRole.v1beta1.rbac.authorization.k8s.io
cluster-admin           ClusterRole.v1beta1.rbac.authorization.k8s.io
edit                    ClusterRole.v1beta1.rbac.authorization.k8s.io
kubelet-api-admin       ClusterRole.v1beta1.rbac.authorization.k8s.io
system:auth-delegator   ClusterRole.v1beta1.rbac.authorization.k8s.io
system:basic-user       ClusterRole.v1beta1.rbac.authorization.k8s.io
system:controller:attachdetach-controller ClusterRole.v1beta1.rbac.authorization.k8s.io
system:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.k8s.io
...

RBAC 系統角色已經完成足夠的覆蓋，讓叢集可以完全在 RBAC 的管理下執行。

在 ABAC 到 RBAC 進行遷移的過程中，有些在 ABAC 叢集中預設開放的許可權，在 RBAC 中會被視為不必要的授權，會對其進行降級。這種情況會影響到使用 Service Account 的負載。ABAC 配置中，從 Pod 中發出的請求會使用 Pod Token，API Server 會為其授予較高許可權。例如下面的命令在 APAC 叢集中會返回 JSON 結果，而在 RBAC 的情況下則會返回錯誤。

➜  kubectl run nginx --image=nginx:latest
➜  kubectl exec -it $(kubectl get pods -o jsonpath='{.items[0].metadata.name}') bash
➜  apt-get update && apt-get install -y curl
➜  curl -ik \
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  https://kubernetes/api/v1/namespaces/default/pods

降級過程的說明： https://kubernetes.io/docs/admin/authorization/rbac/#upgrading-from-15

所有在 Kubernetes 叢集中執行的應用，一旦和 API Server 進行通訊，都會有可能受到遷移的影響。

要平滑的從 ABAC 升級到 RBAC，在建立 1.6 叢集的時候，可以同時啟用 ABAC 和 RBAC。當他們同時啟用的時候，對一個資源的許可權請求，在任何一方獲得放行都會獲得批准。然而在這種配置下的許可權太過粗放，很可能無法在單純的 RBAC 環境下工作。

RBAC 和 ABAC 同時執行： https://kubernetes.io/docs/admin/authorization/rbac/#parallel-authorizers

在 Google Cloud Next 上的兩次講話提到了 Kubernetes 1.6 中的 RBAC。要獲得更詳細的資訊，請閱讀 RBAC 文件。

https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s https://kubernetes.io/docs/admin/authorization/rbac/