Kubernetes v1.6是如何支持RBAC的

這篇文章將為大家詳細講解有關Kubernetes v1.6是如何支持RBAC的，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

RBAC vs ABAC

　　當前Kubernetes已經支持多種認證模式。認證器是一種機制，可以決定用戶是否被允許通過Kubernetes API對集群做出一些修改。這會影響到kubectl、系統組件、還有運行在集群中和操縱集群狀態的某些應用，如Jenkins的Kubernetes插件，或者是運行在集群中的Helm，它使用Kubernetes API在集群中部署應用。在可用的授權機制中，ABAC和RBAC都是Kubernetes集群的本地機制，都可以對訪問策略進行配置。
　　ABAC，基于屬性的訪問控制（Attribute Based Access Control），是一種很強大的概念。然而在Kubernetes的實現中，ABAC難以管理和理解。要改變授權策略，要求有集群master節點的ssh和根文件系統的訪問權限。而且，只有在集群的API server重啟后，權限變更才會生效。
　　RBAC權限策略通過kubectl或者直接使用Kubernetes API來配置。可以通過RBAC來授權用戶，從而在不給予用戶集群master的ssh訪問權限情況下，可以進行資源管理。RBAC策略能夠輕松地映射資源和Kubernetes API中使用的操作。
　　基于Kubernetes社區的開發力度，未來RBAC應該會取代ABAC。

基本概念

　　要理解RBAC，這里有一些基本理念。最核心的，RBAC是一種授權用戶對Kubernetes API資源進行不同粒度訪問的方式。
　　
　　用戶和資源的連接是使用RBAC的下面兩個對象來定義的。

角色（Roles）

　　角色是一系列權限的集合。比如，角色可以被定義為包含pod的讀權限和列表（list）權限。ClusterRole（集群角色）和角色很像，但它可以被使用在集群中的任何位置。

角色綁定（Role Bindings）

　　角色綁定將角色映射到一個用戶或者一組用戶，把角色在命名空間中對資源的權限授權給這些用戶。ClusterRoleBinding（集群角色綁定）允許授權用戶ClusterRole的在整個集群中的授權訪問。
　　
　　此外，還需要考慮集群角色和集群角色綁定。集群角色和集群角色綁定功能就像角色和角色綁定一樣，只是有著更寬的使用范圍。集群用戶、集群用戶綁定和用戶、用戶綁定之間的準確區別，詳見Kubernetes doc。

Kubernetes中的RBAC

　　RBAC現在已經被深度集成在Kubernetes中，并使用它授權給系統組件使用。系統角色以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就能管理運行Kubernetes集群所需的權限。
　　在從ABAC到RBAC的權限遷移期間，一些在ABAC授權的deployment中默認使能的權限，在RBAC中被識別為是沒有必要的，權限會在RBAC中被降級。可能會影響到服務帳戶的權限的負載。在ABAC配置下，使用pod映射token來授權API server的pod請求有著很高的權限。一個具體的例子，當使能ABAC時，下面的curl命令會返回一個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

　　在從ABAC遷移為RBAC的過程中，Kubernetes集群中運行的任何應用，只要和Kubernetes API交互，都可能被權限遷移所影響。
　　為了使ABAC到RBAC的遷移盡量平滑，你可以在創建Kubernetes v1.6集群時，同時使能ABAC和RBAC授權。當同時使能ABAC和RBAC時，如果任一授權策略授以訪問權限，則都被會授予資源權限。然而，然而在這種配置下，被賦予了太寬容的權限，在完全的RBAC環境下可能無法工作。 　　現在，RBAC完全足夠，ABAC的支持未來應該考慮被棄用。在可預見的未來，它應該還會保存在Kubernetes中，不過開發主要集中在RBAC上了。

關于“Kubernetes v1.6是如何支持RBAC的”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。