由于k8s是一個(gè)容器化平臺管理系統(tǒng)呻纹，那必定是會提供給各個(gè)部門去使用已骇，那每個(gè)使用者就應(yīng)該由管理者分配相應(yīng)的使用權(quán)限见妒。這就不得不提到Kubernetes中的角色訪問控制機(jī)制（RBAC）支持。Kubernetes 中的 RBAC 支持
在Kubernetes1.6版本中新增角色訪問控制機(jī)制（Role-Based Access宴偿，RBAC）讓集群管理員可以針對特定使用者或服務(wù)賬號的角色昭齐，進(jìn)行更精確的資源訪問控制尿招。在RBAC中，權(quán)限與角色相關(guān)聯(lián)阱驾，用戶通過成為適當(dāng)角色的成員而得到這些角色的權(quán)限就谜。這就極大地簡化了權(quán)限的管理。在一個(gè)組織中里覆，角色是為了完成各種工作而創(chuàng)造丧荐，用戶則依據(jù)它的責(zé)任和資格來被指派相應(yīng)的角色，用戶可以很容易地從一個(gè)角色被指派到另一個(gè)角色喧枷。
RBAC vs ABAC
目前 Kubernetes 中有一系列的鑒權(quán)機(jī)制虹统。
https://kubernetes.io/docs/admin/authorization/
鑒權(quán)的作用是，決定一個(gè)用戶是否有權(quán)使用 Kubernetes API 做某些事情隧甚。它除了會影響 kubectl 等組件之外车荔，還會對一些運(yùn)行在集群內(nèi)部并對集群進(jìn)行操作的軟件產(chǎn)生作用，例如使用了?Kubernetes?插件的?Jenkins戚扳，或者是利用 Kubernetes API 進(jìn)行軟件部署的 Helm忧便。ABAC 和 RBAC 都能夠?qū)υL問策略進(jìn)行配置。
ABAC（Attribute Based Access Control）本來是不錯的概念帽借，但是在 Kubernetes 中的實(shí)現(xiàn)比較難于管理和理解（怪我咯）珠增，而且需要對 Master 所在節(jié)點(diǎn)的 SSH 和文件系統(tǒng)權(quán)限，而且要使得對授權(quán)的變更成功生效砍艾，還需要重新啟動 API Server蒂教。
而 RBAC 的授權(quán)策略可以利用 kubectl 或者 Kubernetes API 直接進(jìn)行配置。RBAC 可以授權(quán)給用戶脆荷，讓用戶有權(quán)進(jìn)行授權(quán)管理悴品，這樣就可以無需接觸節(jié)點(diǎn)，直接進(jìn)行授權(quán)管理。RBAC 在 Kubernetes 中被映射為 API 資源和操作苔严。
因?yàn)?Kubernetes 社區(qū)的投入和偏好，相對于 ABAC 而言孤澎，RBAC 是更好的選擇届氢。
由于在RBAC也不是很好理解，在這里我只能把我說理解的給表達(dá)出來覆旭，并且給出一些例子退子。
k8s里面有兩種用戶,一種是User,一種就是service account,User給人用的,service account給進(jìn)程用的,讓進(jìn)程有相關(guān)的權(quán)限。而我們?nèi)嗽谑褂弥薪佑|的最多就是User型将，因?yàn)槲覀冃枰吹娇刂泼姘寮畔椋蛘咄ㄟ^apiserver去訪問不同的api。
之前我在k8s集群搭建教程中說到了讓apiserver開啟basicauth七兜，通過basic-auth-file文件存放用戶名密碼丸凭，那通過這種方式，我們就可以給k8s創(chuàng)建對應(yīng)的用戶了腕铸，這就完成了訪問k8s API的認(rèn)證惜犀。
用戶創(chuàng)建了，但是在k8s中是沒有任何權(quán)限的狠裹，這就是我要重點(diǎn)說道的授權(quán)虽界。
首先來認(rèn)識幾個(gè)概念
Role
ClusterRole
RoleBinding
ClusterRoleBinding
RBAC API定義了四個(gè)資源對象用于描述RBAC中用戶和資源之間的連接權(quán)限。
Role和ClusterRole
Role是一系列權(quán)限的集合涛菠。Role是定義在某個(gè)Namespace下的資源莉御，在這個(gè)具體的Namespace下使用。ClusterRole與Role相似俗冻，只是ClusterRole是整個(gè)集群范圍內(nèi)使用的礁叔。
RoleBinding和ClusterRoleBinding
RoleBinding把Role綁定到賬戶主體Subject，讓Subject繼承Role所在namespace下的權(quán)限言疗。ClusterRoleBinding把ClusterRole綁定到Subject晴圾，讓Subject集成ClusterRole在整個(gè)集群中的權(quán)限。
賬戶主體Subject在這里還是叫“用戶”吧噪奄，包含組group死姚，用戶user和ServiceAccount。
通過以上的描述估計(jì)大家還是沒看懂是啥意思吧勤篮，恩我就是這樣的都毒。。碰缔。那我們實(shí)踐來了解一下：
首先來看看我創(chuàng)建一個(gè)Role.yaml文件,我在安裝k8s集群的時(shí)候創(chuàng)建了一個(gè)user账劲，名字叫test（可以去到初階k8s集群搭建里去查看我是如何創(chuàng)建的這個(gè)用戶），我想讓這個(gè)test只有在default的命名空間里，擁有對pod瀑焦、deployment腌且、services可讀的權(quán)限，那么首先我們得有以下的規(guī)則榛瓮，
“在default的命名空間里铺董，擁有對pod、deployment禀晓、services可讀”的權(quán)限
應(yīng)該這樣寫：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
? namespace: default
? name: reader
rules:
- apiGroups: [""] # "" indicates the core API group
? resources: ["pods","pods/log"]
? verbs: ["get", "watch","list","patch"]
- apiGroups: ["extensions", "apps"]
? resources: ["deployments"]
? verbs: ["get", "list", "watch", "patch"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["services"]
? verbs: ["get", "watch","list","patch"]
這樣對比起來就很明顯了吧精续，我們創(chuàng)建了一個(gè)名叫reader的規(guī)則，它擁有對pod粹懒、deployment重付、services可讀的權(quán)限，它的作用域是名叫default的命名空間凫乖。
規(guī)則是創(chuàng)建好了确垫，但是沒有人用呀？我們要給test這個(gè)用戶去使用,也就是說拣凹，我們要把這個(gè)叫做reader的rule賦給test森爽，這時(shí)我們就需要RoleBinding來幫助我們綁定Role：
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
? name: reader-test
? namespace: default
subjects:
- kind: User
? name: test
? apiGroup: rbac.authorization.k8s.io
roleRef:
? kind: Role
? name: reader
? apiGroup: rbac.authorization.k8s.io
這下就好了，從上面的配置文件看嚣镜，我們將名叫reader的Role通過名叫reader-test的RoleBinding去賦值到用戶test上了爬迟，通過kubectl apply -f RoleBinding.yaml,大家即可驗(yàn)證通過test登錄到控制臺上，只能查看到default命名空間下的pod菊匿、deployment付呕、services，并且無法修改無法操作跌捆，我們也就完成了以上需求徽职。規(guī)則是人定的，想怎么改就根據(jù)實(shí)際業(yè)務(wù)需求吧佩厚！
然鵝，事情真的就這樣結(jié)束了嗎抄瓦？我們發(fā)現(xiàn)通過以上創(chuàng)建好規(guī)則是沒什么問題了潮瓶，但是在控制臺上，也無法選擇別的命名空間了钙姊，如下圖所示
這就不好辦了毯辅，也就是說，剛剛使用的RoleBinding和Role都只能在一個(gè)命名空間下發(fā)揮它的作用煞额，在多個(gè)命名空間或者是說在集群的這一整個(gè)范圍之上呢思恐，有一個(gè)集群管理員需要獲得namespace 列表和node列表我們應(yīng)該怎么做沾谜？
這就引出了ClusterRoleBinding和ClusterRole這兩個(gè)資源對象了，我覺得可以理解為RoleBinding和Role的升級版胀莹，也就是說基跑，它的控制范圍是在集群上的，而不是在某一個(gè)命名空間嗜逻。
在之前的文章中涩僻，我們還創(chuàng)建了一個(gè)用戶admin，我們想讓這個(gè)admin作為系統(tǒng)觀察者栈顷，并擁有所有命名空間的pod、deployment嵌巷、services可讀權(quán)限萄凤，我們可以這樣做，按照老步驟：
擁有所有命名空間的pod搪哪、deployment靡努、services可讀權(quán)限
vim?ClusterRole.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
? #namespace: default
? name: admin-nsp
rules:
- apiGroups: [""] # "" indicates the core API group
? resources: ["pods","pods/log"]
? verbs: ["get", "watch","list","patch","update", "create","delete"]
- apiGroups: ["extensions", "apps"]
? resources: ["deployments"]
? verbs: ["get", "list", "watch", "patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["services"]
? verbs: ["get", "watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["namespaces"]
? verbs: ["get", "watch","list"]
- apiGroups: [""]
? resources: ["nodes"]
? verbs: ["get", "list", "watch"]
我們創(chuàng)造了一個(gè)名叫admin-nsp集群級別的規(guī)則，很容易看出這個(gè)集群規(guī)則比之前的Role權(quán)利更大晓折，注意啦惑朦，這類規(guī)則是不需要寫命名空間的，它面向的是整個(gè)集群漓概，一旦你設(shè)置完成漾月，這個(gè)規(guī)則就擁有對整個(gè)集群下的相關(guān)權(quán)利。
然后我們將它付給我們的用戶admin：
vim?ClusterRoleBinding
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
? name: read-nsp-global
subjects:
- kind: User
? name: admin
? apiGroup: rbac.authorization.k8s.io
#- kind: User
# ?name: test
# ?apiGroup: rbac.authorization.k8s.io
roleRef:
? kind: ClusterRole
? name: admin-nsp
? apiGroup: rbac.authorization.k8s.io
通過kubectl apply -f 部署之后就完成了這個(gè)admin用戶的整個(gè)授權(quán)胃珍。從這個(gè)yaml文件看到梁肿，這個(gè)ClusterRoleBinding可以讓我們綁定多個(gè)用戶，也就是說觅彰，設(shè)置好的ClusterRole或者是Role都可以被多個(gè)用戶綁定授權(quán)吩蔑。
通過以上的小例子大家應(yīng)該能對這四個(gè)資源對象有一定的了解了吧，通過一系列的組合方式即可變成一系列靈活的授權(quán)模板填抬，這大大的滿足了用戶多租戶多權(quán)限的個(gè)性化需求烛芬。
附：
規(guī)則中的一些資源對象
rules:
- apiGroups: [""] # "" indicates the core API group
? resources: ["pods","pods/log"]
? verbs: ["get", "watch","list","patch","update", "create","delete"]
- apiGroups: ["extensions", "apps"]
? resources: ["deployments"]
? verbs: ["get", "list", "watch", "patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["services"]
? verbs: ["get", "watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["configmaps"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["persistentvolumeclaims"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["secrets"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["ingresses.extensions"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["daemonsets.apps"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["events"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["replicasets.apps"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["jobs.batch"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["cronjobs/batch","cronjobs"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["replicationcontrollers"]
? verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
? resources: ["statefulsets.apps"]
? verbs: ["get","watch","list","patch","delete","update","create"]
本人個(gè)人理解。飒责。赘娄。有不對的地方還望及時(shí)指出。读拆。擅憔。
參考文獻(xiàn)：
