K8s 原生支持的準入策略管理

作者：陽明 2023-01-04 17:42:22

CEL 最開始被引入到 Kubernetes 中來是用于 CustomResourceDefinitions 的驗證規則，此次改進則大大擴展了 CEL 在 Kubernetes 中的使用，可以支持更廣泛的準入用例場景。

在 Kubernetes 1.26 發布的 changelog 中，發現了一個 alpha 版本的驗證準入策略的更新，其實就是可以用一種特定的語言來進行準入控制，以前我們介紹過可以通過 OPA、kyverno? 等方式來進行策略管理，但是這些方式并非官方默認的方式，而現在官方提供了一種自帶的方式，在驗證準入策略時可以使用一種通用的表達式語言（CEL）來提供聲明的、進程內的替代方法來驗證 validating admission webhook。

什么是 CEL

CEL 是一種非圖靈的完整表達式語言，被設計為快速、可移植和安全執行，CEL 可以單獨使用，也可以嵌入到一個更大的產品中。

CEL 被設計成一種可以安全執行用戶代碼的語言，雖然在用戶的 python 代碼上盲目地調用 eval() 是危險的，但你可以安全地執行用戶的 CEL 代碼。因為 CEL 防止了會使其性能降低的行為，它可以在納秒到微秒的時間內安全地進行評估；它是性能關鍵型應用的理想選擇。CEL 評估表達式，這類似于單行函數或 lambda 表達式。雖然 CEL 通常用于布爾決策，但它也可用于構建更復雜的對象，如 JSON 或 protobuf 消息。

CEL 的類 C 語法看起來與 C++、Go、Java 和 TypeScript 中的等價表達式幾乎是相同的。

resource.name.startWith("/groups/" + auth.claims.group) // 檢測resource.name是否以group開頭

關于 CEL 語言的完整語法可以參考官網 https://github.com/google/cel-spec。

準入策略

我們知道準入控制器的開發和操作是非常繁瑣的，除了要開發 Webhook 程序之外，還需要維護 Webhook 二進制文件來處理準入請求，admission webhook 的操作也都很復雜，每個 webhook 都必須部署、監控，并要有一個明確的升級和回滾計劃，如果你的 webhook 超時或不可用了，那么 Kubernetes 控制平面可能會變得不可用，影響面非常大。現在我們可以通過將 CEL 表達式嵌入到 Kubernetes 資源中，而不是調用遠程 webhook 程序來實現準入策略，這樣就大大降低了 admission webhook 的復雜性。

策略管理通常由三個資源組成：

ValidatingAdmissionPolicy 描述了策略的抽象邏輯。
ValidatingAdmissionPolicyBinding 將上述資源鏈接在一起并提供范圍界定。
參數資源向ValidatingAdmissionPolicy 提供信息以使其成為具體聲明。ConfigMap 或 CRD 等類型定義了參數資源的 schema，ValidatingAdmissionPolicy 對象指定他們期望參數資源的種類。

至少必須定義一個 ValidatingAdmissionPolicy 和一個相應的 ValidatingAdmissionPolicyBinding 才能使策略生效。如果不需要通過參數配置 ValidatingAdmissionPolicy，只不設置 ValidatingAdmissionPolicy 中的 spec.paramKind 即可。

一個很簡單例子，例如我們要設置 Deployment 可以擁有的副本數量限制，那么可以定義如下所示的驗證策略資源對象：

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"  # 策略對象
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 5"

該對象中的 expression 字段的值就是用于驗證準入請求的 CEL 表達式，我們這里配置的 object.spec.replicas <= 5，就表示要驗證對象的 spec.replicas 屬性值是否大于 5，而 matchConstraints 屬性則聲明了該 ValidatingAdmissionPolicy 對象可以驗證哪些類型的請求，我們這里是針對 Deployment 資源對象。

接下來我們可以將該策略綁定到合適的資源：

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding-test.example.com"
spec:
  policy: "demo-policy.example.com"
  matchResources:
    namespaceSelector:
    - key: environment,
      operator: In,
      values: ["test"]

此 ValidatingAdmissionPolicyBinding 資源會將上面聲明的 demo-policy.example.com 策略綁定到 environment 標簽設置為 test 的命名空間，一旦創建該綁定對象后，kube-apiserver 將開始執行這個準入策略。

我們可以簡單對比下，如果是通過開發 admission webhook 來實現上面的功能，那么我們就需要開發和維護一個程序來執行 <= 的檢查，雖然是一個非常簡單的功能，但是要做非常多的其他工作，而且在實際工作中，絕大多數也是執行一些相對簡單的檢查，這些我們都可以很容易使用 CEL 來進行表達。

此外驗證準入策略是高度可配置的，我們可以根據需要定義策略，可以根據集群管理員的需求對資源進行參數化，例如我們可以修改上面的準入策略以使其具有可配置性：

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  paramKind:
    apiVersion: rules.example.com/v1 # 需要一個 CRD
    kind: ReplicaLimit
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= params.maxReplicas"

在該準入策略對象中，paramKind 屬性定義了用于配置策略的資源，在 expression 屬性中我們使用了 params 變量來訪問參數資源。

然后我們可以定義多個綁定，每個綁定都可以有不同的配置。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding-production.example.com"
spec:
  policy: "demo-policy.example.com"
  paramsRef:
    name: "demo-params-production.example.com"
  matchResources:
    namespaceSelector:
    - key: environment,
      operator: In,
      values: ["production"]
---
apiVersion: rules.example.com/v1 
kind: ReplicaLimit
metadata:
  name: "demo-params-production.example.com"
maxReplicas: 1000

這里我們通過 paramsRef 屬性關聯了一個 CRD 對象，這樣在策略對象中我們就可以通過 params.maxReplicas 獲取到該對象的 maxReplicas 屬性值了，這里我們將 environment 標簽設置為 production 的命名空間的 Deployments 限制為最多 1000 個副本，當然我們還可以創建另外的綁定對象，為其他命名空間進行不同的限制。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "replicalimit-binding-test.example.com"
spec:
  policyName: "replicalimit-policy.example.com"
  paramRef:
    name: "replica-limit-test.example.com"
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: test
---
apiVersion: rules.example.com/v1
kind: ReplicaLimit
metadata:
  name: "replica-limit-test.example.com"
maxReplicas: 3

此策略參數資源將部署限制為測試環境中所有名稱空間中最多 3 個副本，準入政策可能有多個綁定。要將所有其他環境綁定到 maxReplicas 限制為 100，則可以創建另一個 ValidatingAdmissionPolicyBinding 對象：

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "replicalimit-binding-nontest"
spec:
  policyName: "replicalimit-policy.example.com"
  paramRef:
    name: "replica-limit-clusterwide.example.com"
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: environment,
        operator: NotIn,
        values: ["test"]
---
apiVersion: rules.example.com/v1
kind: ReplicaLimit
metadata:
  name: "replica-limit-clusterwide.example.com"
maxReplicas: 100

此外在策略對象中我們還可以通過 failurePolicy 來定義如何處理錯誤配置和 CEL 表達式從準入策略評估為錯誤，該屬性允許的值包括 Ignore、Fail。

Ignore 表示忽略調用 ValidatingAdmissionPolicy 的錯誤，允許 API 請求繼續。
Fail 表示調用 ValidatingAdmissionPolicy 出錯導致準入失敗，API 請求被拒絕。

需要注意的是 failurePolicy 是在 ValidatingAdmissionPolicy 對象中定義的，如下所示：

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
spec:
...
failurePolicy: Ignore # 默認值為 "Fail"
validations:
- expression: "object.spec.xyz == params.x"

通過前面的示例我們知道在策略對象中是通過 spec.validations[i].expression 來表示由 CEL 進行評估的表達式的，通過 CEL 表達式我們可以訪問準入請求/響應的內容，可以組織成 CEL 變量以及一些其他變量：

object - 來自傳入請求的對象，對于 DELETE 請求，該值為 null。
oldObject - 現有對象，對于 CREATE 請求，該值為 null。
request - 準入請求的屬性。
params - 正在評估的策略綁定引用的參數資源，如果未設置 ParamKind，則值為 null。

apiVersion、kind、metadata.name 和 metadata.generateName 這些屬性我們始終可以從對象的根進行訪問，沒有其他元數據屬性可訪問。

責任編輯：姜華來源： k8s技術圈

Kubernetes K8s