使用Webhook為Kubernetes實現基于標簽的權限控制
Kubernetes支持名稱空間級別的權限控制。但是,有時這不能滿足我們的要求。例如,在Akraino ICN項目中,我們有一些高級權限要求:多個用戶可以在同一名稱空間中創建,更新或刪除一種資源,但不能更新或刪除其他人創建的對象。
為了滿足這一要求,我們使用Webhook在Kubernetes中設計并實現了基于標簽的權限控制機制。通常,webhooks用于驗證資源或設置資源的默認值。在本文中,我們使用webhook來控制權限。
許可系統的設計
在Kubernetes中,用戶或服務帳戶可以綁定到一個或多個角色。每個角色定義其權限規則。例如,以下定義要求sdewan-test角色可以在默認名稱空間中創建或更新類型為Mwan3Rule的自定義資源實例(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擴展了角色。
在注釋中,我們可以定義基于標簽的權限。例如,下面顯示的角色擴展了sdewan-test角色權限:sdewan-test只能創建/更新帶有標簽sdewan-bucket-type=app-intent或sdewan-bucket-type=k8s-service的Mwan3Rule(json鍵指定自定義資源類型)CR。而且它只能獲得帶有標簽sdewan-bucket-type=app-intent的Mwan3Policy CR。
實際上,我們也支持通配符匹配。例如,我們可以使用mwan3*來同時匹配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負責解析角色注釋。讓我用簡單的詞來描述什么是準入webhook。我們可以將webhook視為Web服務,通常它在Kubernetes集群中作為pod運行。
當Kubernetes api收到請求時,kube-api可以在將對象保存到etcd中之前調用webhook API。如果webhook返回allowed=true,則kube-api繼續將對象持久保存到etcd中。否則,kube-api拒絕該請求。
Webhook請求主體具有一個名為userInfo的字段,該字段指示誰在發出Kubernetes api請求。從用戶信息中,webhook可以獲取角色信息,然后獲取角色注釋。通過將注釋中描述的標簽級別權限與CR標簽進行比較,webhook可以決定是否允許該請求。
實施權限控制系統
我們已經通過Akraino ICN項目中的kubebuilder框架實現了基于標簽的權限系統。這里的假設是已經實現了一些自定義資源定義(CRD)(例如Mwan3Policy和Mwan3Rule)和相應的控制器。
Kubebuilder可以生成基本的CRD,控制器代碼和Webhook代碼。要創建一個新的webhook,我們運行以下kubebuilder命令:
- kubebuilder create webhook --group batch --version v1 --kind CronJob --programmatic-validation
此命令利用controller-runtime builder來創建驗證Webhook。該命令還會創建webhook server,該server接受來自kube-api服務器的https請求。它甚至生成解析http請求正文并將其轉換為CRD結構實例的代碼。
開發人員只需要編寫代碼來驗證CRD實例內容。這對于大多數Webhook情況都是有用的。但這不能滿足我們的要求,因為我們需要位于https請求正文中的UserInfo而不是CRD實例。
我們重用了kubebuilder生成的webhook server,但自己實現了處理程序。上圖顯示了處理程序的處理流程。處理程序接受“ admission.Request”作為輸入,其中包含UserInfo。在處理程序中,我們獲得用戶角色信息和CR標簽。
- 獲取用戶角色信息。
userinfo在請求正文中。為了從userinfo獲取角色信息,處理程序必須向kube-api請求用戶的角色信息。處理程序使用serviceaccount令牌作為身份驗證將請求發送到kube-api。首先,處理程序發送一個請求以獲取用戶的角色綁定信息。然后,它發送第二個請求以從角色綁定信息中獲取角色信息。默認情況下,角色綁定資源在“ .subjects”字段上沒有索引器,這意味著我們無法在kube-api請求中過濾角色綁定,除非我們為角色綁定添加以下索引器:
- 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信息
來自用戶的請求可能是創建,更新或刪除資源。對于創建或更新請求,處理程序從請求正文中提取CR信息。對于刪除請求,處理程序只能獲取CR名稱,而不能獲取整個實例。因此需要調用kube-api來獲取CR信息
- 考慮角色和ClusterRole
除了角色外,還可以在ClusterRole中定義用戶權限。區別在于,角色始終在單個名稱空間中定義權限,而ClusterRole可以在整個群集中定義權限。因此,我們還需要檢查ClusterRole中的注釋。解析角色信息時,我們只關心與CR具有相同名稱空間的角色。
測試與實驗
現在,我要介紹如何測試和試驗基于標簽的權限。在ICN中,此功能是通過kubebuilder與某些CRD/控制器一起開發的。Webhook支持https,但不支持http。因此,我們需要Webhook server的認證。
我們使用cert-manager插件來填充Webhook server的證書。同時,我們還將證書注入到webhook配置中,以便kube-api在發送webhook請求時可以使用證書。對于開發或本地測試用例,其中Webhook從本地而不是Pod運行,我們需要手動配置證書。
一旦建立了網絡連接,我們就可以為測試創建角色和角色綁定。讓我們創建以下角色并將其綁定到用戶。
- 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"]
允許用戶創建標簽為“sdewan-bucket-type:app-intent”的mwan3policies,但不能創建其他標簽。這里一個具體的例子是,用戶可以創建下面左邊的CR,而不是下面右邊的CR。
如果我們嘗試創建下面右邊的CR,則會收到錯誤消息“Error from server (Your roles don't have the permission): error when creating "config/samples/batch_v1alpha1_mwan3policy.yaml"。
結論
Webhook是kubernetes的一個很好的功能,它賦予kubernetes更大的靈活性。開發人員可以使用它來實現許多有用的功能。
Controller-runtime項目提供了builder工具,通過它我們可以輕松創建兩種類型的Webhook:驗證Webhook和Mutating Webhook。驗證Webhook用于驗證kube-api的資源,而Muting Webhook可以更新資源字段的值,例如設置默認值。
有時,這兩種類型的Webhook都不符合我們的要求。例如,在本文中,我們需要獲取不在資源正文中的userinfo。在這種情況下,我們需要自行開發大多數處理程序代碼,而不是使用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
*本文部分內容翻譯自https://01.org/kubernetes/blogs/chengli3/2020/implement-label-based-permission-control-kubernetes-using-webhook,如有侵權請聯系刪除