Kubernetes v1.6是如何支持RBAC的

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

RBAC vs ABAC

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

基本概念

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

角色（Roles）

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

角色綁定（Role Bindings）

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

Kubernetes中的RBAC

　　RBAC現(xiàn)在已經(jīng)被深度集成在Kubernetes中，并使用它授權(quán)給系統(tǒng)組件使用。系統(tǒng)角色以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的系統(tǒng)角色，僅使用RBAC就能管理運行Kubernetes集群所需的權(quán)限。
　　在從ABAC到RBAC的權(quán)限遷移期間，一些在ABAC授權(quán)的deployment中默認使能的權(quán)限，在RBAC中被識別為是沒有必要的，權(quán)限會在RBAC中被降級。可能會影響到服務(wù)帳戶的權(quán)限的負載。在ABAC配置下，使用pod映射token來授權(quán)API server的pod請求有著很高的權(quán)限。一個具體的例子，當使能ABAC時，下面的curl命令會返回一個JSON格式的正確結(jié)果，而只使能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集群中運行的任何應(yīng)用，只要和Kubernetes API交互，都可能被權(quán)限遷移所影響。
　　為了使ABAC到RBAC的遷移盡量平滑，你可以在創(chuàng)建Kubernetes v1.6集群時，同時使能ABAC和RBAC授權(quán)。當同時使能ABAC和RBAC時，如果任一授權(quán)策略授以訪問權(quán)限，則都被會授予資源權(quán)限。然而，然而在這種配置下，被賦予了太寬容的權(quán)限，在完全的RBAC環(huán)境下可能無法工作。 　　現(xiàn)在，RBAC完全足夠，ABAC的支持未來應(yīng)該考慮被棄用。在可預(yù)見的未來，它應(yīng)該還會保存在Kubernetes中，不過開發(fā)主要集中在RBAC上了。

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