使用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，如有侵權請聯系刪除
