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 文檔。
本文轉自中文社群-
Kubernetes中的角色通路控制機制（RBAC）支援