使用webhook為Kubernetes實(shí)現(xiàn)基于標(biāo)簽的權(quán)限控制

作者：祝祥 翻譯 2021-03-16 07:56:32

云計(jì)算 Kubernetes支持名稱(chēng)空間級(jí)別的權(quán)限控制。但是，有時(shí)這不能滿足我們的要求。例如，在Akraino ICN項(xiàng)目中，我們有一些高級(jí)權(quán)限要求：多個(gè)用戶可以在同一名稱(chēng)空間中創(chuàng)建，更新或刪除一種資源，但不能更新或刪除其他人創(chuàng)建的對(duì)象。

創(chuàng)新互聯(lián)-專(zhuān)業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性?xún)r(jià)比任城網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式任城網(wǎng)站制作公司更省心,省錢(qián),快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋任城地區(qū)。費(fèi)用合理售后完善，10年實(shí)體公司更值得信賴(lài)。

Kubernetes支持名稱(chēng)空間級(jí)別的權(quán)限控制。但是，有時(shí)這不能滿足我們的要求。例如，在Akraino ICN項(xiàng)目中，我們有一些高級(jí)權(quán)限要求：多個(gè)用戶可以在同一名稱(chēng)空間中創(chuàng)建，更新或刪除一種資源，但不能更新或刪除其他人創(chuàng)建的對(duì)象。

為了滿足這一要求，我們使用Webhook在Kubernetes中設(shè)計(jì)并實(shí)現(xiàn)了基于標(biāo)簽的權(quán)限控制機(jī)制。通常，webhooks用于驗(yàn)證資源或設(shè)置資源的默認(rèn)值。在本文中，我們使用webhook來(lái)控制權(quán)限。

許可系統(tǒng)的設(shè)計(jì)

在Kubernetes中，用戶或服務(wù)帳戶可以綁定到一個(gè)或多個(gè)角色。每個(gè)角色定義其權(quán)限規(guī)則。例如，以下定義要求sdewan-test角色可以在默認(rèn)名稱(chēng)空間中創(chuàng)建或更新類(lèi)型為Mwan3Rule的自定義資源實(shí)例(CR)，并且可以獲取Mwan3Policy CR。

  
 
 
 
   
  
  
  
apiVersion: rbac.authorization.k8s.io/v1 
   
  
  
  
kind: Role 
   
  
  
  
metadata: 
   
  
  
  
  Annotations: 
   
  
  
  
  name: sdewan-test 
   
  
  
  
  namespace: default 
   
  
  
  
rules: 
   
  
  
  
- apiGroups: 
   
  
  
  
  - "" 
   
  
  
  
  resources: 
   
  
  
  
  - mwan3rules 
   
  
  
  
  verbs: 
   
  
  
  
  - create 
   
  
  
  
  - update 
   
  
  
  
- apiGroups: 
   
  
  
  
  - "" 
   
  
  
  
  resources: 
   
  
  
  
  - mwan3policies 
   
  
  
  
  verbs: 
   
  
  
  
  - get 
  
 
 

我們使用json格式的注釋sdewan-bucket-type-permission擴(kuò)展了角色。

在注釋中，我們可以定義基于標(biāo)簽的權(quán)限。例如，下面顯示的角色擴(kuò)展了sdewan-test角色權(quán)限：sdewan-test只能創(chuàng)建/更新帶有標(biāo)簽sdewan-bucket-type=app-intent或sdewan-bucket-type=k8s-service的Mwan3Rule(json鍵指定自定義資源類(lèi)型)CR。而且它只能獲得帶有標(biāo)簽sdewan-bucket-type=app-intent的Mwan3Policy CR。

實(shí)際上，我們也支持通配符匹配。例如，我們可以使用mwan3*來(lái)同時(shí)匹配mwan3policies和mwan3rules。

  
 
 
 
   
  
  
  
apiVersion: rbac.authorization.k8s.io/v1 
   
  
  
  
kind: Role 
   
  
  
  
metadata: 
   
  
  
  
annotations: 
   
  
  
  
  sdewan-bucket-type-permission: |- 
   
  
  
  
    { "mwan3rules": ["app-intent", "k8s-service"], 
   
  
  
  
    "mwan3policies": ["app-intent"] } 
   
  
  
  
name: sdewan-test 
   
  
  
  
namespace: default 
   
  
  
  
rules: 
   
  
  
  
- apiGroups: 
   
  
  
  
- "" 
   
  
  
  
resources: 
   
  
  
  
- mwan3rules 
   
  
  
  
verbs: 
   
  
  
  
- create 
   
  
  
  
- update 
   
  
  
  
- apiGroups: 
   
  
  
  
- "" 
   
  
  
  
resources: 
   
  
  
  
- mwan3policies 
   
  
  
  
verbs: 
   
  
  
  
- get 
  
 
 

Kubernetes Webhook負(fù)責(zé)解析角色注釋。讓我用簡(jiǎn)單的詞來(lái)描述什么是準(zhǔn)入webhook。我們可以將webhook視為Web服務(wù)，通常它在Kubernetes集群中作為pod運(yùn)行。

當(dāng)Kubernetes api收到請(qǐng)求時(shí)，kube-api可以在將對(duì)象保存到etcd中之前調(diào)用webhook API。如果webhook返回allowed=true，則kube-api繼續(xù)將對(duì)象持久保存到etcd中。否則，kube-api拒絕該請(qǐng)求。

Webhook請(qǐng)求主體具有一個(gè)名為userInfo的字段，該字段指示誰(shuí)在發(fā)出Kubernetes api請(qǐng)求。從用戶信息中，webhook可以獲取角色信息，然后獲取角色注釋。通過(guò)將注釋中描述的標(biāo)簽級(jí)別權(quán)限與CR標(biāo)簽進(jìn)行比較，webhook可以決定是否允許該請(qǐng)求。

實(shí)施權(quán)限控制系統(tǒng)

我們已經(jīng)通過(guò)Akraino ICN項(xiàng)目中的kubebuilder框架實(shí)現(xiàn)了基于標(biāo)簽的權(quán)限系統(tǒng)。這里的假設(shè)是已經(jīng)實(shí)現(xiàn)了一些自定義資源定義(CRD)(例如Mwan3Policy和Mwan3Rule)和相應(yīng)的控制器。

Kubebuilder可以生成基本的CRD，控制器代碼和Webhook代碼。要?jiǎng)?chuàng)建一個(gè)新的webhook，我們運(yùn)行以下kubebuilder命令：

  
 
 
 
   
  
  
  
kubebuilder create webhook --group batch --version v1 --kind CronJob --programmatic-validation 
  
 
 

此命令利用controller-runtime builder來(lái)創(chuàng)建驗(yàn)證Webhook。該命令還會(huì)創(chuàng)建webhook server，該server接受來(lái)自kube-api服務(wù)器的https請(qǐng)求。它甚至生成解析http請(qǐng)求正文并將其轉(zhuǎn)換為CRD結(jié)構(gòu)實(shí)例的代碼。

開(kāi)發(fā)人員只需要編寫(xiě)代碼來(lái)驗(yàn)證CRD實(shí)例內(nèi)容。這對(duì)于大多數(shù)Webhook情況都是有用的。但這不能滿足我們的要求，因?yàn)槲覀冃枰挥趆ttps請(qǐng)求正文中的UserInfo而不是CRD實(shí)例。

我們重用了kubebuilder生成的webhook server，但自己實(shí)現(xiàn)了處理程序。上圖顯示了處理程序的處理流程。處理程序接受“ admission.Request”作為輸入，其中包含UserInfo。在處理程序中，我們獲得用戶角色信息和CR標(biāo)簽。

• 獲取用戶角色信息。

userinfo在請(qǐng)求正文中。為了從userinfo獲取角色信息，處理程序必須向kube-api請(qǐng)求用戶的角色信息。處理程序使用serviceaccount令牌作為身份驗(yàn)證將請(qǐng)求發(fā)送到kube-api。首先，處理程序發(fā)送一個(gè)請(qǐng)求以獲取用戶的角色綁定信息。然后，它發(fā)送第二個(gè)請(qǐng)求以從角色綁定信息中獲取角色信息。默認(rèn)情況下，角色綁定資源在“ .subjects”字段上沒(méi)有索引器，這意味著我們無(wú)法在kube-api請(qǐng)求中過(guò)濾角色綁定，除非我們?yōu)榻巧壎ㄌ砑右韵滤饕鳎?/p>

  
 
 
 
   
  
  
  
err = mgr.GetFieldIndexer().IndexField(context.Background(), &rbacv1.RoleBinding{}, ".subjects", func(rawObj runtime.Object) []string { 
   
  
  
  
var fieldValues []string 
   
  
  
  
rolebinding := rawObj.(*rbacv1.RoleBinding) 
   
  
  
  
for _, subject := range rolebinding.Subjects { 
   
  
  
  
        if subject.Kind == "ServiceAccount" { 
   
  
  
  
                fieldValues = append(fieldValues, fmt.Sprintf("system:serviceaccount:%s:%s", subject.Namespace, subject.Name)) 
   
  
  
  
        } else { 
   
  
  
  
                fieldValues = append(fieldValues, subject.Name) 
   
  
  
  
        } 
   
  
  
  
} 
   
  
  
  
return fieldValues 
  
 
 

• 獲取CR信息

來(lái)自用戶的請(qǐng)求可能是創(chuàng)建，更新或刪除資源。對(duì)于創(chuàng)建或更新請(qǐng)求，處理程序從請(qǐng)求正文中提取CR信息。對(duì)于刪除請(qǐng)求，處理程序只能獲取CR名稱(chēng)，而不能獲取整個(gè)實(shí)例。因此需要調(diào)用kube-api來(lái)獲取CR信息

• 考慮角色和ClusterRole

除了角色外，還可以在ClusterRole中定義用戶權(quán)限。區(qū)別在于，角色始終在單個(gè)名稱(chēng)空間中定義權(quán)限，而ClusterRole可以在整個(gè)群集中定義權(quán)限。因此，我們還需要檢查ClusterRole中的注釋。解析角色信息時(shí)，我們只關(guān)心與CR具有相同名稱(chēng)空間的角色。

測(cè)試與實(shí)驗(yàn)

現(xiàn)在，我要介紹如何測(cè)試和試驗(yàn)基于標(biāo)簽的權(quán)限。在ICN中，此功能是通過(guò)kubebuilder與某些CRD/控制器一起開(kāi)發(fā)的。Webhook支持https，但不支持http。因此，我們需要Webhook server的認(rèn)證。

我們使用cert-manager插件來(lái)填充Webhook server的證書(shū)。同時(shí)，我們還將證書(shū)注入到webhook配置中，以便kube-api在發(fā)送webhook請(qǐng)求時(shí)可以使用證書(shū)。對(duì)于開(kāi)發(fā)或本地測(cè)試用例，其中Webhook從本地而不是Pod運(yùn)行，我們需要手動(dòng)配置證書(shū)。

一旦建立了網(wǎng)絡(luò)連接，我們就可以為測(cè)試創(chuàng)建角色和角色綁定。讓我們創(chuàng)建以下角色并將其綁定到用戶。

  
 
 
 
   
  
  
  
apiVersion: rbac.authorization.k8s.io/v1 
   
  
  
  
kind: Role 
   
  
  
  
metadata: 
   
  
  
  
namespace: default 
   
  
  
  
name: create-intent 
   
  
  
  
annotations: 
   
  
  
  
  sdewan-bucket-type-permission: |- 
   
  
  
  
    { "mwan3policies": ["app-intent"] } 
   
  
  
  
rules: 
   
  
  
  
- apiGroups: ["batch.sdewan.akraino.org"] 
   
  
  
  
resources: ["mwan3policies"] 
   
  
  
  
verbs: ["get", "watch", "list", "delete", "create"] 
  
 
 

允許用戶創(chuàng)建標(biāo)簽為“sdewan-bucket-type：app-intent”的mwan3policies，但不能創(chuàng)建其他標(biāo)簽。這里一個(gè)具體的例子是，用戶可以創(chuàng)建下面左邊的CR，而不是下面右邊的CR。

如果我們嘗試創(chuàng)建下面右邊的CR，則會(huì)收到錯(cuò)誤消息“Error from server (Your roles don't have the permission): error when creating "config/samples/batch_v1alpha1_mwan3policy.yaml"。

結(jié)論

Webhook是kubernetes的一個(gè)很好的功能，它賦予kubernetes更大的靈活性。開(kāi)發(fā)人員可以使用它來(lái)實(shí)現(xiàn)許多有用的功能。

Controller-runtime項(xiàng)目提供了builder工具，通過(guò)它我們可以輕松創(chuàng)建兩種類(lèi)型的Webhook：驗(yàn)證Webhook和Mutating Webhook。驗(yàn)證Webhook用于驗(yàn)證kube-api的資源，而Muting Webhook可以更新資源字段的值，例如設(shè)置默認(rèn)值。

有時(shí)，這兩種類(lèi)型的Webhook都不符合我們的要求。例如，在本文中，我們需要獲取不在資源正文中的userinfo。在這種情況下，我們需要自行開(kāi)發(fā)大多數(shù)處理程序代碼，而不是使用builder工具。

參考鏈接：

Kubebuilder book: https://book.kubebuilder.io/introduction.html

Controller-runtime doc: https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/doc.go

Akraino SDEWAN agent design: https://wiki.akraino.org/display/AK/Sdewan+config+Agent

Label based permission control patch: https://gerrit.akraino.org/r/c/icn/sdwan/+/3509

*本文部分內(nèi)容翻譯自https://01.org/kubernetes/blogs/chengli3/2020/implement-label-based-permission-control-kubernetes-using-webhook，如有侵權(quán)請(qǐng)聯(lián)系刪除

本文名稱(chēng)：使用Webhook為Kubernetes實(shí)現(xiàn)基于標(biāo)簽的權(quán)限控制
當(dāng)前地址：http://m.5511xx.com/article/coedgip.html