為什麼需要 Kubernetes 准入控制器

Kubernetes 准入控制器是叢集管理必要功能。這些控制器主要在後臺工作，並且許多可以作為編譯外掛使用，它可以極大地提高部署的安全性。

准入控制器在 API 請求傳遞到 APIServer 之前攔截它們，並且可以禁止或修改它們。這適用於大多數型別的 Kubernetes 請求。准入控制器在經過適當的身份驗證和授權後處理請求。

預設情況下啟用了幾個准入控制器，因為大多數正常的 Kubernetes 操作都依賴於它們。這些控制器中的大多數都包含一些 Kubernetes 原始碼樹，並被編譯為外掛。但是，也可以編寫和部署第三方准入控制器。一些說明性示例將在稍後解決這個問題。

准入控制器工作原理

Kubernetes 控制平面由幾個元件組成。其中一個元件是 kube-apiserver，簡單的 API server。它公開了一個 REST 端點，使用者、叢集元件以及客戶端應用程式可以通過該端點與叢集進行通訊。總的來說，它會進行以下操作：

• 從客戶端應用程式(如 kubectl)接收標準 HTTP 請求。
• 驗證傳入請求並應用授權策略。
• 在成功的身份驗證中，它能根據端點物件(Pod、Deployments、Namespace 等)和 http 動作(Create、Put、Get、Delete 等)執行操作。
• 對 etcd 資料儲存進行更改以儲存資料。
• 操作完成，它就向客戶端傳送響應。

現在讓我們考慮這樣一種情況：在請求經過身份驗證後，但在對 etcd 資料儲存進行任何更改之前，我們需要攔截該請求。例如：

• 攔截客戶端傳送的請求。
• 解析請求並執行操作。
• 根據請求的結果，決定對 etcd 進行更改還是拒絕對 etcd 進行更改。

Kubernetes 准入控制器就是用於這種情況的外掛。在程式碼層面，准入控制器邏輯與 API server 邏輯解耦，這樣使用者就可以開發自定義攔截器(custom interceptor)，無論何時物件被建立、更新或從 etcd 中刪除，都可以呼叫該攔截器。

有了准入控制器，從任意來源到 API server 的請求流將如下所示：

根據准入控制器執行的操作型別，它可以分為三種類型：

• Mutating(變更)
• Validating(驗證)
• Both(兩者都有)

Mutating：這種控制器可以解析請求，並在請求向下傳送之前對請求進行更改(變更請求)。

例如：AlwaysPullImages

Validating：這種控制器可以解析請求並根據特定資料進行驗證。

例如：NamespaceExists

Both：這種控制器可以執行變更和驗證兩種操作。

例如：CertificateSigning

默認準入控制器

Kubernetes 具有多個內建准入控制器。一個簡單的例子，DefaultIngressClass將預設入口類應用到還沒有指定類的入口物件。同樣，DefaultStorageClass將預設儲存類應用到PersistentVolumeClaims還沒有的儲存類。必須啟用此控制器以允許基於儲存類的動態儲存配置。

准入控制器在維護安全性方面非常有幫助。例如，它們可以減輕對多租戶叢集的拒絕服務 (DoS) 攻擊。考慮LimitRanger外掛，顧名思義，它強制限制範圍。限制範圍以每個名稱空間為基礎定義資源消耗的強制範圍。這可以防止租戶耗盡彼此的資源。

另一個問題是所謂的事件氾濫，叢集被事件淹沒，無法充分處理其他合法請求。對於EventRateLimit此類情況，控制器是一種強大的緩解工具。它的設計使其能夠限制每個名稱空間或每個使用者的事件發生率。

此外，還有兩個重要的控制器允許開發人員將他們的准入外掛作為 webhook 執行，以便在執行時進行配置。MutatingAdmissionWebhook使 webhook 能夠修改提交的資源，通常用於強制執行自定義預設值。同時，ValidatingAdmissionWebhook控制器啟用已註冊的 webhook 來決定處於最終狀態的 API 驗證資源是繼續通過還是被完全丟棄。

第三方准入控制器

Kubernetes 有兩個領先的開源策略引擎：Open Policy Agent (OPA) Gatekeeper 和 Kyverno。

這兩個引擎都是對雲原生計算基金會 (CNCF) 的捐贈，該基金會致力於雲原生技術的標準化和推廣。它在其上級組織 Linux 基金會下運作。值得注意的是，Kubernetes 是一個 CNCF 專案。

Kyverno 的主要優勢在於它不需要學習額外的語言。它的所有策略都定義為 Kubernetes 資源。相反，Gatekeeper 利用 OPA 的宣告性語言 Rego。Gatekeeper 是更大的 OPA 系統的一部分，而 Kyverno 是 Kubernetes 的獨立專案。總而言之，Gatekeeper 是更 成熟的專案，但 Kyverno 的學習曲線更小。

使用控制器的目的

在物理機上執行多項服務的最初方法是讓虛擬機器共享同一主機，並使用管理程式分隔它們的作業系統。一個複雜的雲配置系統(例如，由 AWS 定義的那些)使系統保持獨立，並確保租戶不會意外或故意傷害彼此。

Kubernetes 最初被設計為單個組織或使用者可以使用的協作系統。此外，它比其他雲系統之間的依賴更強。然而，隨著 Kubernetes 在可用部署的多樣性和處理更大叢集規模的能力方面的增長，制定確保單個使用者不會干擾系統操作的策略變得越來越重要。

為了使這個過程自動化，組織需要一個策略系統。Kubernetes 具有一些內建支援，但它不具備功能齊全的專用策略引擎的能力。

自定義准入控制器

您可以使用 Webhook 使用任何可以處理 HTTP 請求並返回 Javascript 物件表示法 (JSON) 的語言來編寫自定義准入控制器邏輯。例如，Go、Python 或 Ruby 都是有效的選項。

下面的示例演示瞭如何為自定義准入控制器設定 webhook。它類似於上面介紹的 LimitRanger，它拒絕對超過資源名稱空間限制的 Pod 的請求。

首先，使用配置物件註冊 webhook：

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
  name: mywebhook
webhooks:
  - name: mywebhook
    clientConfig:
      service:
        name: mywebhook
        namespace: project1
        path: "/hook"
    rules:
      - operations: ["CREATE"]
        apiVersions: ["v1"]
        apiGroups: [""]
        resources: ["pods"]

這說明 ValidatingWebhookController webhook。它還指定要訪問的服務以及在執行伺服器的容器上探測的路徑。它還確定在決定是否呼叫 webhook 時要應用哪些規則。此示例側重於建立新 pod。

實際上，在叢集上建立此資源將在最後發生 - 在為 webhook 伺服器建立部署之後。部署包含與上述檔案中的定義匹配的服務：

apiVersion: v1
kind: Service
metadata:
  name: mywebhook
  namespace: project1
spec:
  - ports:
      name: mywebhook
      port: 80
      targetPort: 8000

下面是 webhook 的示例部署，與常規應用程式沒有什麼不同。我們不會探索使用傳輸層安全 (TLS) 來保護通訊，但強烈建議這樣做。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mywebhook
  namespace: project1
spec:
  selector:
    matchLabels:
      app: mywebhook
  template:
    metadata:
      labels:
        app: mywebhook
    spec:
      containers:
        - image: webhook1:latest
          name: mywebhook

新的 Pod 請求提交給 Kubernetes 並通過 Kubernetes 傳遞後ValidatingWebhook，相關資訊會作為POST請求傳送到配置的 URL 路徑，幷包含一個 JSON 物件供 webhook 處理。

驗證是否正常工作

部署完 webhook 伺服器並完成配置之後，我們還需要對它進行測試和驗證，

用 kubectl create -f examples/.yaml 建立 Pod。如果是前兩種情況，我們可以通過檢查日誌來驗證 Pod 執行時的使用者 ID，例如：

$ kubectl create -f examples/pod-test.yaml
$ kubectl logs pod-test

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "6ce7a33c-ea67-40e5-9cc8-f710d31985dc",
    "allowed": true
  }
}

當然我們也可以自定義更復雜的准入控制器，明確某些 Pod 必須以非 root 身份執行，如果不對，那麼就可以拒絕物件建立請求。

自定義准入控制器可以像這個示例一樣簡單，也可以複雜得多。