可擴展准入機制進入 Beta 階段

為 容 器 技 術 而 生

翻譯：夏天

校對：唐鵬程

今天，我們來好好聊一下 Kubernetes API server 中准入機制，它可以幫助用戶實現任意的准入控制決策，這一功能在 Kubernetes 1.9 中已經相當成熟。

API server 的准入機制是功能最強大的工具之一，它通過限制可以創建的對象，來保護 Kubernetes 集群，但它卻是一直是與 Kubernetes 源碼一起編譯的。在 Kubernetes 1.9 中，Admission Webhook 升級為 beta 版，允許用戶在 API server 之外使用准入機制。

准入機制是什麼？

准入是在經過授權之後，資源持久化之前的一個處理 API server 請求的步驟。准入過程能獲取到和認證過程一致的信息（用戶、URL 等），以及絕大多數 API 請求的完整報文。

准入階段由不同的插件組成，每個插件都能 「各司其職」，並明確知道自己要檢查的對象結構。例如：PodNodeSelector（影響調度決策），PodSecurityPolicy（防止升級的容器）和ResourceQuota（為每個 Namespace 限制資源配額）。

准入分為兩個階段：

• 修改 (Mutation) 階段：允許修改對象的主體內容以及拒絕 API 請求

• 驗證 (Validation) 階段：允許內省查詢以及拒絕 API 請求

一個準入插件可以在這兩個階段應用，但是所有的修改階段都發生在驗證階段之前。

1

修改 （Mutation）階段

Admission 的 Mutation 階段允許在資源內容生成前進行修改。因為同一個欄位在 Admission 鏈上可以被多次修改，因此 Admission 插件的執行順序很重要。准入修改插件（Mutating Admission Plugin）中的一個例子就是PodNodeSelector。

它使用 Namespace 的一個 annotation：

2

驗證 （Validating）階段

我們可以在 Admisson 的驗證階段來檢查特定 API 資源以保證其不變。驗證階段在所有的 mutators 完成之後運行，以確保資源在做完驗證之後不會被再次改變。

准入驗證插件（Validation Admission Plugin）的一個例子也是PodNodeSelector插件，它可以確保所有 pod 的spec.nodeSelector欄位都能符合 Namespace 上節點選擇器的約束。即使在 Mutating 鏈中運行PodNodeSelector之後，有其他修改插件試圖更改spec.nodeSelector欄位，驗證鏈中的PodNodeSelector插件也會因驗證失敗而阻止 API 資源的創建。

Admission Webhook 是什麼？

Admission Webhook 允許 Kubernetes 安裝人員或集群管理員，不需要進行重新編譯，就可以直接添加修改（Mutation）和驗證（Validation）這兩種插件到kube-apiserver和任何基於 k8s.io/apiserver 1.9 擴展的 apiserver (如 metrics, service-catalog, kube-projects 等) 准入鏈中。這兩種 Admission Webhook 插件分別會在修改和驗證鏈的最後執行，與編譯的准入插件具有相同的功能。

1

Webhook Admission 插件的優勢

Webhook Admission 插件允許對任何 API server 的任何資源進行修改和驗證，所以應用場景非常廣泛，比較常見的用例包括：

• 修改如 pod 這樣的資源：Istio 通過修改 pod 資源，把 side-car 容器注入到 pod 中。你也可以編寫一個能夠強制將鏡像 tag 解析成 SHA 的插件;

• 命名限制：在多租戶系統上，保留 Namespace 已經成為一種用例 ;

• 複雜的 CustomResource 驗證：因為整個對象是可見的，所以插件可以對欄位間依賴（A 需要 B）甚至外部資源（對比 LimitRanges）進行複雜的驗證;

• 安全響應：如果你把鏡像 tag 改成了 SHA，你可以通過寫一個插件來阻止對應某些 SHA 的鏡像運行。

2

註冊

這兩種類型的 Webhook Admission 插件都需要在 API 中註冊，所有 API servers（kube-apiserver 和所有擴展 API servers ）都共享一個通用配置。在註冊過程中，一個 Webhook Admission 插件描述了以下信息：

• 如何連接到 Webhook Admission Server；

• 如何驗證 Webhook Admission Server（是否是我們期望的 server）；

• 數據應該發送到 Server 的哪個 URL 路徑；

• 它將處理哪些資源和哪些 HTTP 動詞；

• API server 在連接失敗後應該做什麼（例如如果 Webhook Admission Server 停止服務了）。

• 第 6 行 name：Webhook 的名稱。mutating Webhooks 會根據名稱進行排序。

• 第 7 行 clientConfig：提供關於如何連接、信任以及發送數據給 Webhook Admission Server 的信息。

• 第 13 行 rules：用來描述 API server 應該在什麼時候調用 Admission 插件。在這個例子中，只有創建 Namespace 的時候才觸發。你可以指定任何資源，例如serviceinstances.servicecatalog.k8s.io 的 create 操作也是可行的。

• 第 22 行 failurePolicy：如果 Webhook Admission Server 無法連接時如何處理。有兩個選項分別是 「Ignore」（故障時開放） 和 「Fail」（故障時關閉）。「故障時開放」可能會導致無法預測的行為。

3

認證和信任

由於 Webhook Admission 插件具有強大的功能（他們可以查看 API 資源內容中任何發給他們的請求，並可以通過插件進行修改），所以在使用時需要考慮的重點是：

• 各個 API servers 如何驗證其與 Webhook Admission Server 的連接；

• Webhook Admission Server 如何準確地認證哪個 API server 正在與它連接；

• 該特定的 API server 是否有權進行請求。

連接可以分為以下三大類：

• 從 kube-apiserver 或 extension-apiservers 到運行在集群外部的 Admission Webhooks；

• 從 kube-apiserver 到運行在集群內部的 Admission Webhooks；

• 從 extension-apiservers 到運行在集群內部的 Admission Webhooks。

為了支持這三大類連接，Webhook Admission 插件可以支持從 kubeconfig 文件中讀取連接各個 server 的信息。由於認證/授權和訪問路徑是由用戶所連接的伺服器所決定的，因此為了與運行在集群外部的 Admission Webhooks 進行交互，除了手動配置這個文件之外，實際上沒有其他選擇。

對於在集群內運行的 Admission Webhook 來說，一個巧妙構建的 Webhook Admission Server 和拓撲結構，就是能夠利用 Admission 插件中內置的安全默認值，並具有可從任何 API server 運行的安全、可移植和零配置的拓撲結構。

簡單安全，可移植的拓撲結構

如果你建立的 Webhook Admission Server 也是一個 extension API server，就有可能把它作為一個普通的 API server 來聚合。這具有許多優點：

• 你的 Webhook 在默認 kube-apiserver 服務 「kubernetes.default.svc」 下變得可用 https：//kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews。另一個好處是，你可以使用kubectl進行測試。

• 你的 Webhook 會自動（無需任何配置）使用 kube-apiserver 提供的集群內認證和授權。你可以使用正常的 RBAC 規則限制對 Webhook 的訪問。

• 你的 extension API servers 和 kube-apiserver （無需任何配置）可以自動利用其集群內的憑證與 Webhook 進行通信。

• 因為中間會經過 kube-apiserver 這個安全的前端代理，所以 extension API servers 不會將其 service account token 泄漏給 Webhook。

https://drive.google.com/a/redhat.com/file/d/12nC9S2fWCbeX_P8nrmL6NgOSIha4HDNp

簡而言之：一個安全的拓撲結構可以使用 API server 聚合 (API server aggregation) 的所有安全機制，不需要額外的配置。其他的拓撲結構也是可行的，但是需要額外的手動配置以及創建安全設置工作。尤其是像 service catalog 這種 extension API servers，上面的拓撲結構就是零配置，並且可移植到任何 Kubernetes 集群中。

編寫 Webhook Admission Server

編寫一個具有完整的有完備身份驗證和授權的 Server 是非常困難的事情。為了讓這件事變得更容易，基於 Kubernetes 1.9 的不少項目都提供了相關的庫，可以讓使用者用 200 行甚至更少的代碼來實現一個 Webhook Admission Server。可以參考 「generic-admission-apiserver」 和 「kubernetes-namespace-reservation」 這兩個項目中提供的庫，以及如何構建一個安全和可移植的 Webhook Admission Server 的示例。

原文參考：http://blog.kubernetes.io/2018/01/extensible-admission-is-beta.html

留言區已開放，歡迎互動

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！