2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

Kubernetes v1.6的一個(gè)亮點(diǎn)就是RBAC認(rèn)證特性成為了beta版本。RBAC，基于角色的訪問控制（Role-Based Access Control），是用于管理Kubernetes資源訪問權(quán)限的認(rèn)證機(jī)制。RBAC支持靈活的認(rèn)證策略配置，使得集群在不重啟的情況下就可以升級權(quán)限。
　　本文重點(diǎn)聚焦在一些有趣的新特性和實(shí)踐上。

RBAC vs ABAC

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

基本概念

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

角色（Roles）

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

角色綁定（Role Bindings）

　　角色綁定將角色映射到一個(gè)用戶或者一組用戶，把角色在命名空間中對資源的權(quán)限授權(quán)給這些用戶。ClusterRoleBinding（集群角色綁定）允許授權(quán)用戶ClusterRole的在整個(gè)集群中的授權(quán)訪問。
　　
　　此外，還需要考慮集群角色和集群角色綁定。集群角色和集群角色綁定功能就像角色和角色綁定一樣，只是有著更寬的使用范圍。集群用戶、集群用戶綁定和用戶、用戶綁定之間的準(zhǔ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 ...

　　擴(kuò)充了RBAC的系統(tǒng)角色，僅使用RBAC就能管理運(yùn)行Kubernetes集群所需的權(quán)限。
　　在從ABAC到RBAC的權(quán)限遷移期間，一些在ABAC授權(quán)的deployment中默認(rèn)使能的權(quán)限，在RBAC中被識別為是沒有必要的，權(quán)限會在RBAC中被降級。可能會影響到服務(wù)帳戶的權(quán)限的負(fù)載。在ABAC配置下，使用pod映射token來授權(quán)API server的pod請求有著很高的權(quán)限。一個(gè)具體的例子，當(dāng)使能ABAC時(shí)，下面的curl命令會返回一個(gè)JSON格式的正確結(jié)果，而只使能RBAC時(shí)則會返一個(gè)錯(cuò)誤。

$ 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ùn)行的任何應(yīng)用，只要和Kubernetes API交互，都可能被權(quán)限遷移所影響。
　　為了使ABAC到RBAC的遷移盡量平滑，你可以在創(chuàng)建Kubernetes v1.6集群時(shí)，同時(shí)使能ABAC和RBAC授權(quán)。當(dāng)同時(shí)使能ABAC和RBAC時(shí)，如果任一授權(quán)策略授以訪問權(quán)限，則都被會授予資源權(quán)限。然而，然而在這種配置下，被賦予了太寬容的權(quán)限，在完全的RBAC環(huán)境下可能無法工作。 　　現(xiàn)在，RBAC完全足夠，ABAC的支持未來應(yīng)該考慮被棄用。在可預(yù)見的未來，它應(yīng)該還會保存在Kubernetes中，不過開發(fā)主要集中在RBAC上了。
　　在Google Cloud Next會議上，有兩篇涉及到Kubernetes v1.6中BRAC相關(guān)改變的演講，可通過這里和這里來查看相關(guān)部分。如果要查看更多關(guān)于Kubernetes v1.6使用RBAC的詳細(xì)信息，閱讀完整的RBAC文檔。

轉(zhuǎn)載于:https://my.oschina.net/styshoo/blog/883146

總結(jié)

以上是生活随笔為你收集整理的Kubernetes v1.6开始支持RBAC的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。