摘要：本文介紹了模型中四個(gè)最主要的對(duì)象，即，大致了解了的工作原理和使用方法，如果要更加深入地了解和掌握，可以查看官方文檔。只是這個(gè)不能復(fù)用到其他，一般只有在做精細(xì)化權(quán)限管理的時(shí)候，我們才會(huì)創(chuàng)建對(duì)象，比如一個(gè)只能查看名稱(chēng)為的。

了解RBAC

簡(jiǎn)介

RBAC是一種基于角色來(lái)管理對(duì)計(jì)算機(jī)或網(wǎng)絡(luò)資源訪(fǎng)問(wèn)策略的方法。

我們知道，對(duì)K8S內(nèi)所有API對(duì)象的操作都是通過(guò)訪(fǎng)問(wèn)kube-apiserver來(lái)完成的，因此kube-apiserver需要校驗(yàn)訪(fǎng)問(wèn)者是否具備操作這些API對(duì)象的權(quán)限。而K8S中負(fù)責(zé)授權(quán)和權(quán)限校驗(yàn)(Authorization&Authentication)的這套機(jī)制，則是RBAC：基于角色的訪(fǎng)問(wèn)控制（Role-based Access Control ）

在Kubernetes的RBAC模型里面，有三個(gè)基本的概念：

• Role：角色，其實(shí)是一組權(quán)限規(guī)則的集合，定義了一組對(duì)Kubernetes API 對(duì)象的操作權(quán)限。
• Subject：主體，即被授予角色的"人"或"物"，即可以是Kubernetes里面的Service Account，也可以是外部User，為了簡(jiǎn)單起見(jiàn)，本文主要以Service Account來(lái)做演示。
• RoleBinding：定義了Role與Subject的綁定關(guān)系。

而至于ClusterRole、ClusterRoleBinding，在概念上與Role、RoleBinding非常相似，只是作用域不同而已。

Role & ClusterRole

1、Role---namespace維度的權(quán)限集合

首先我們來(lái)介紹下Role，Role本身也是Kubernetes中的一個(gè) API 對(duì)象，其定義如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get" "watch" "list"]

首先，我們注意到這個(gè)名為"pod-reader"的Role，通過(guò)namespace: default指定了他能產(chǎn)生作用的Namespace。

Namespace是Kubernetes中的一個(gè)邏輯管理單位，Kubernetes中大部分業(yè)務(wù)類(lèi)API對(duì)象（如Pod、Service）都是Namespace級(jí)別的，在操作時(shí)需要顯式指明Namespace，如：kubectl edit role/pod-reader -n namespace2.

然后是rules字段，一個(gè)Role對(duì)象所擁有的權(quán)限，其實(shí)就是通過(guò)rules字段來(lái)定義了。

• apiGroups：apiGroup代表API對(duì)象所屬的組，可以通過(guò)kubectl api-resources來(lái)查看API對(duì)象屬于哪個(gè)組，上文示例""代表Core API group。
• resources： 用于聲明該角色可訪(fǎng)問(wèn)的API對(duì)象。
• verbs：用于聲明該角色可對(duì)API對(duì)象進(jìn)行的操作，在Kubernetes中，verbs的全集為"get" "list" "watch" "create" "update" "patch" "delete"，如果我們要賦予某個(gè)role對(duì)某個(gè)API對(duì)象的所有權(quán)限，指定verbs的全部集合即可。
• resourceName：resourceName表示具體的K8S資源，需要注意的是，當(dāng)聲明了resourceName時(shí)，則verbs中不能再賦予list操作，該字段較少使用，一般用于較細(xì)粒度的權(quán)限管理。

了解了Role每個(gè)字段的含義后，上文Role示例的意義其實(shí)就很清楚了：一組可對(duì)default命名空間下所有的Pod，進(jìn)行GET、WATCH、LIST操作的權(quán)限集合，名稱(chēng)為pod-reader。

2、ClusterRole---Cluster維度的權(quán)限集合

ClusterRole的API定義與Role基本相同，你可以給一個(gè)ClusterRole賦予與Role一樣的權(quán)限。但由于其cluster-wide的特性，ClusterRole可以被賦予一些不同的權(quán)限：

• 集群級(jí)別的API對(duì)象訪(fǎng)問(wèn)權(quán)限，如nodes、namespace、pv；
• 非資源類(lèi)型endpoints的訪(fǎng)問(wèn)權(quán)限，如"/healthz";
• 所有Namespace下資源的訪(fǎng)問(wèn)權(quán)限，如kubectl get pods --all-namespaces；

下文是一個(gè)ClusterRole的示例，與Role最大的區(qū)別就在于不需要聲明namespace。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get" "watch" "list"]

值得注意的是，Kubernetes內(nèi)置了很多為系統(tǒng)保留的ClusterRole，你可以通過(guò)kubectl get clusterrole查看到他們。一般來(lái)說(shuō)，這些ClusterRole，是綁定給系統(tǒng)組件對(duì)應(yīng)的service account使用的。比如，其中一個(gè)名為system:controller:cronjob-controller的ClusterRole，定義的權(quán)限規(guī)則是Cronjob這個(gè)控制器運(yùn)行所必要的權(quán)限。你可以通過(guò)如下示例查看查看其權(quán)限規(guī)則。

bash-4.4# kubectl describe clusterrole system:controller:cronjob-controller
Name:         system:controller:cronjob-controller
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources                  Non-Resource URLs  Resource Names  Verbs
  ---------                  -----------------  --------------  -----
  jobs.batch                 []                 []              [create delete get list patch update watch]
  events                     []                 []              [create patch update]
  pods                       []                 []              [delete list]
  cronjobs.batch             []                 []              [get list update watch]
  cronjobs.batch/finalizers  []                 []              [update]
  cronjobs.batch/status      []                 []              [update]

除此以外，還有幾個(gè)預(yù)先的定義的CluterRole值得留意下，后面給其他集群用戶(hù)配置權(quán)限的時(shí)候，我們可能會(huì)用到：

• view
• edit
• admin
• cluster-admin

其所擁有的權(quán)限，通過(guò)其名稱(chēng)我們也能猜到大概，具體的權(quán)限規(guī)則可以通過(guò)kubectl describe clusterrole clusterrole-name來(lái)查看。

了解了Role和ClusterRole后，我們知道如何在Kubernetes集群內(nèi)聲明一組權(quán)限集合，那怎么把權(quán)限賦予某個(gè)具體的"人"或"物"呢？答案就是RoleBinding和ClusterRoleBinding啦。

RoleBinding&ClusterRoleBinding

1、Rolebinding---在Namespace范圍內(nèi)授予權(quán)限

Rolebinding可將角色中定義的權(quán)限授予用戶(hù)或用戶(hù)組，它包含subject（user、group或Service Account），以及所引用的角色。RoleBinding可以在同一命名空間中引用Role（意味著Role和Rolebinding必須位于同一Namespace）。

以下RoleBinding的示例，將“pod-reader”角色授予“default”命名空間中的“jane”。 這允許“jane”讀取“默認(rèn)”命名空間中的pod。

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: jane # must create a ServiceAccount jane in default namespace
  namespace: default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

值得注意的是，一個(gè)RoleBinding也可以引用ClusterRole，這樣ClusterRole中所定義的Namespace級(jí)別的權(quán)限將會(huì)被賦予Subject，當(dāng)然只在rolebinding所在的Namespace有效。這樣做的好處是，集群管理員可以預(yù)先創(chuàng)建一些通用的ClusterRole，然后在不同的Namespace中使用他們，比如在上個(gè)章節(jié)提到的view、admin.

如下文所示，雖然"view-only"這個(gè)RoleBinding引用了ClusterRole，但"ucloud"這個(gè)ServiceAccount只擁有查看"development"這個(gè)命名空間下所有資源的權(quán)限，而不能查看所有命名空間下的資源。

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
metadata:
  name: view-only
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: ServiceAccount
  name: ucloud # Create a ServiceAccount in your cluster before test
  namespace: production # The namespace of subject can be different with Rolebinding
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

2、ClusterRoleBinding---在Cluster范圍內(nèi)授予權(quán)限

下面我們來(lái)了解下ClusterRoleBinding，前面我們提到過(guò)，Role和RoleBinding都是Namespace級(jí)別的資源，也就是說(shuō)他們所聲明的權(quán)限規(guī)則都只在Namespace范圍內(nèi)有效。
那如果我們

1. 想讓某個(gè)Subject（用戶(hù)）擁有所有Namespace的查看權(quán)限；
2. 或者想讓某個(gè)Pod擁有查看Node的權(quán)限；

應(yīng)該怎么辦呢？這就需要用到ClusterRole和ClusterRoleBinding這對(duì)組合了，和ClusterRole一樣，ClusterRoleBinding與RoleBinding的最大不同其實(shí)就是不需要聲明"namespace"這個(gè)字段了。

首先我們來(lái)看一個(gè)示例，我們想讓techleader擁有所有Namespace的查看權(quán)限，注意roleRef，對(duì)于ClusterRoleBinding，只能引用ClusterRole，而不能是Role。

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows a service account named "techleader" to view resource in any namespace.
kind: ClusterRoleBinding
metadata:
  name: techleader-read-global
subjects:
- kind: ServiceAccount
  name: techleader   
  namespace: default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

其次，我們還希望為techleader賦予查看nodes的權(quán)限，所以我們需要在創(chuàng)建一個(gè)ClusterRole和ClusterRoleBinding。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get" "watch" "list"]

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows a service account named "techleader" to view resource in any namespace.
kind: ClusterRoleBinding
metadata:
  name: techleader-read-node
subjects:
- kind: ServiceAccount
  name: techleader   
  namespace: default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

本文介紹了Kubernetes RBAC 模型中四個(gè)最主要的API對(duì)象，即Role、ClusterRole、RoleBinding、ClusterRoleBinding，大致了解了RBAC的工作原理和使用方法，如果要更加深入地了解和掌握RBAC，可以查看官方文檔。

權(quán)限管理實(shí)踐

背景

本文主要通過(guò)一個(gè)例子來(lái)介紹如何基于K8S的RBAC實(shí)現(xiàn)授權(quán)決策，允許集群管理員通過(guò)Kubernetes API動(dòng)態(tài)配置策略，讓非集群管理員具有某個(gè)namespace下的所有權(quán)限，并可通過(guò)Dashboard或者kubectl來(lái)管理該ns下的資源。

一、創(chuàng)建NS

kubectl create ns pre

上面的示例創(chuàng)建了一個(gè)名為"pre"的命名空間，用于部署預(yù)發(fā)布的服務(wù)。

二、創(chuàng)建Service Account

kubectl create sa mingpianwang -n pre

在pre的命名空間下創(chuàng)建一個(gè)名為"mingpianwang"的Service account，給到某個(gè)特定的用戶(hù)使用。這里要說(shuō)明下，K8S里面有兩類(lèi)用戶(hù)，一個(gè)是Service Account，另一個(gè)是普通用戶(hù)(user)。但K8S本身不并管理user，而是交由外部獨(dú)立服務(wù)管理，因此我們不能通過(guò)K8S API來(lái)創(chuàng)建user，考慮到我們只是通過(guò)kubectl和Dashboard來(lái)管理集群，Service account已經(jīng)足夠滿(mǎn)足要求，而且可以在Kubernetes中直接管理。因此這里不介紹如何使用user這個(gè)對(duì)象來(lái)管理集群。

三、賦予權(quán)限

由于我們已經(jīng)預(yù)先說(shuō)明，需要給mingpianwang這個(gè)用戶(hù)賦予pre 這個(gè)命名空間下的所有權(quán)限，即admin權(quán)限。

重點(diǎn)來(lái)了，RoleBinding對(duì)象是可以引用一個(gè)ClusterRole對(duì)象的，然后這個(gè)ClusterRole所擁有的權(quán)限只會(huì)在這個(gè)NS下面有效。這一點(diǎn)允許管理員在整個(gè)集群范圍內(nèi)首先定義一組通用的角色，然后再在不同的名字空間中復(fù)用這些角色。

我們先看下集群內(nèi)默認(rèn)的ClusterRole有哪些，執(zhí)行g(shù)et clusterrole命名可以看到，有admin、cluster-admin、edit等角色，那我們可以直接使用admin這個(gè)clusterrole角色，通過(guò)rolebinding的方式賦予”mingpianwang“這個(gè)用戶(hù)。

[root@10-9-149-7 ~]# kubectl get clusterrole
NAME AGE
admin 4h53m
cluster-admin 4h53m
edit 4h53m

示例的yaml如下，我們只要執(zhí)行下kubectl apply -f rolebinding.yaml 即可。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: pre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- kind: ServiceAccount
  name: mingpianwang
  namespace: pre

當(dāng)然，我們也可以創(chuàng)建一個(gè)Namespace級(jí)別的role，并將這個(gè)角色綁定到ServiceAccount。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: pre
  name: admin
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["*"]
  verbs: ["*"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: pre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin
subjects:
- kind: ServiceAccount
  name: mingpianwang
  namespace: pre

只是這個(gè)role不能復(fù)用到其他Namespace，一般只有在做精細(xì)化權(quán)限管理的時(shí)候，我們才會(huì)創(chuàng)建Role對(duì)象，比如一個(gè)只能查看pod 名稱(chēng)為test-pod的Role。其他場(chǎng)景下，我們推薦集群管理員使用ClusterRole。

四、訪(fǎng)問(wèn)Dashboard

這里我們使用token方式來(lái)登錄Dashboard，那我們就要獲取到”mingpianwang“的token，其實(shí)就是secret了。這個(gè)secret在我們創(chuàng)建的時(shí)候，K8S就幫我們自動(dòng)生成了。通過(guò)下面的方式來(lái)獲取，最后的token復(fù)制下來(lái)就可以了。

bash-4.4# kubectl describe sa/mingpianwang -n pre
Name:                mingpianwang
Namespace:           pre
Labels:              
Annotations:         
Image pull secrets:  
Mountable secrets:   mingpianwang-token-4l8xj
Tokens:              mingpianwang-token-4l8xj
Events:              
bash-4.4# kubectl describe secret/mingpianwang-token-4l8xj -n pre
Name:         mingpianwang-token-4l8xj
Namespace:    pre
Labels:       
Annotations:  kubernetes.io/service-account.name: mingpianwang
              kubernetes.io/service-account.uid: d7bb847d-7621-11e9-9679-5254007e7ba9

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1359 bytes
namespace:  5 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9/....

復(fù)制到登錄框，我們發(fā)現(xiàn)可以登錄到Dashboard首頁(yè)，不過(guò)需要注意的是，由于這個(gè)賬號(hào)只有pre這個(gè)命名空間的權(quán)限，而Dashboard默認(rèn)是default，所以進(jìn)去之后會(huì)報(bào)一堆錯(cuò)咯，沒(méi)關(guān)系，只要將左側(cè)的NS改為pre即可。

五、通過(guò)kubectl管理集群

由于我們還需要支持kubectl命令行管理NS，因此還需要為mingpianwang生成kubecofnig，一個(gè)用戶(hù)還好，多個(gè)用戶(hù)就很麻煩了，因此這里我們使用一個(gè)自動(dòng)生成kubeconfig的腳本，代碼如下：

#!/bin/bash -e
# Usage ./k8s-service-account-kubeconfig.sh ( namespace ) ( service account name )
TEMPDIR=$( mktemp -d )
trap "{ rm -rf $TEMPDIR ; exit 255; }" EXIT
SA_SECRET=$( kubectl get sa -n $1 $2 -o jsonpath={.secrets[0].name} )
# Pull the bearer token and cluster CA from the service account secret.
BEARER_TOKEN=$( kubectl get secrets -n $1 $SA_SECRET -o jsonpath={.data.token} | base64 -d )
kubectl get secrets -n $1 $SA_SECRET -o jsonpath={.data.ca.crt} | base64 -d > $TEMPDIR/ca.crt
CLUSTER_URL=$( kubectl config view -o jsonpath={.clusters[0].cluster.server} )
KUBECONFIG=kubeconfig

kubectl config --kubeconfig=$KUBECONFIG 
    set-cluster 
    $CLUSTER_URL 
    --server=$CLUSTER_URL 
    --certificate-authority=$TEMPDIR/ca.crt 
    --embed-certs=true

kubectl config --kubeconfig=$KUBECONFIG 
    set-credentials $2 --token=$BEARER_TOKEN

kubectl config --kubeconfig=$KUBECONFIG 
    set-context registry 
    --cluster=$CLUSTER_URL 
    --user=$2 
    --namespace=$1

kubectl config --kubeconfig=$KUBECONFIG 
    use-context registry

echo "kubeconfig written to file "$KUBECONFIG""

直接在master節(jié)點(diǎn)執(zhí)行sh kubeconfig.sh pre mingpianwang，即可自動(dòng)生成一個(gè)kubeconfig文件，將這個(gè)kubeconfig文件分發(fā)給使用者，讓其復(fù)制到~/.kube/config下即可，而且默認(rèn)NS就是pre，get nodes等操作都是不被允許的。

自動(dòng)生成kubeconfig的源代碼在這里，generator kubeconfig，我們只是加了一個(gè)默認(rèn)NS，這樣不需要在執(zhí)行kubectl命令的時(shí)候追加-n pre。

實(shí)時(shí)文檔歡迎訪(fǎng)問(wèn)https://docs.ucloud.cn/uk8s/bestpractice/authorization/rbac