詳解Ocm Klusterlet秘鑰管理機制
概述
在open-cluster-management中，為了使控制面有更好的可擴展性，我們使用了hub-spoke的架構：即集中的控制面（hub）只負責處理控制面的資源和數據而無需訪問被管理的集群；每個被管理集群（spoke）運行一個稱為klusterlet的 agent 訪問控制面獲取需要執行的任務。在這個過程中，klusterlet需要擁有訪問hub集群的秘鑰才能和hub安全通信。確保秘鑰的安全性是非常重要的，因為如果這個秘鑰被泄露的話有可能導致對 hub 集群的惡意訪問或者竊取敏感信息，特別是當ocm的被管理集群分布在不同的公有云中的時候。為了保證秘鑰的安全性，我們需要滿足一些特定的需求：
- 盡量避免秘鑰在公有網絡中的傳輸
- 秘鑰的刷新和廢除
- 細粒度的權限控制
本文將詳細介紹ocm是如何實現秘鑰的管理來保證控制面板和被管理集群之間的安全訪問的。
架構和機制
在 ocm 中我們采用了以下幾個機制來確保控制面和被管理集群之間訪問的安全性：
- 基于CertificateSigniningRequest的 mutual tls
- 雙向握手協議和動態klusterletID
- 認證和授權的分離
基于CertificateSigniningRequest的 mutual tls
使用kubernetes的CertificateSigniningRequest（CSR[1]）API 可以方便的生成客戶認證證書。這個機制可以讓klusterlet在第一次啟動訪問hub集群時使用一個權限很小的秘鑰來創建 CSR。當 CSR 返回了生成的證書后，klusterlet就可以用后續生成的帶有更大訪問權限的證書來訪問hub集群。在使用 csr 的過程中，klusterlet的私鑰不會在網絡中傳輸而是一直保存在被管理集群中；只有 CSR 的公鑰和初始階段需要的小權限秘鑰（bootstrap secret）會在不同集群間傳輸。這就最大程度的保證秘鑰不會在傳輸過程中被泄露出去。
雙向握手協議和動態klusterletID
那么如果初始階段的 bootstrap secret 被泄露了會怎么樣呢？這就牽涉到 OCM 中的雙向握手協議。當被管理集群中的klusterlet使用 bootstrap secret 發起了第一次請求的時候，hub 集群不會立刻為這個請求創建客戶證書和對應的訪問權限。這個請求將處在Pending狀態，直到 hub 集群擁有特定管理權限的管理員同意了klusterlet的接入請求后，客戶證書和特定權限才會被創建出來。這個請求中包含了klusterlet啟動階段生成的動態 ID，管理員需要確保這個 ID 和被管理集群上klusterlet的 ID 一致才能同意klusterlet的接入。這也就確保了如果 bootstrap secret 被不慎泄露后，CSR 也不會被管理員輕易的接受。
klusterlet使用的客戶證書是有過期時間的，klusterlet需要在證書過期之前使用現有的客戶證書發起新的CSR請求來獲取新的客戶證書。hub集群會檢驗更新證書的CSR請求是否合法并自動簽署新的客戶證書。需要注意的是由于klusterlet使用了動態 ID 的機制，只有klusterlet本身發起的CSR請求才會被自動簽署。如果klusterlet在集群中被卸載然后重新部署后，它必須重新使用 bootstrap secret 流程來獲取客戶證書。
認證和授權的分離
在klusterlet的CSR請求被接受后，它獲得了被hub集群認證通過的客戶證書，但是它在這個時候還沒有對hub集群上特定資源訪問的權限。ocm中還有一個單獨的授權流程。每個被管理集群的klusterlet時候有權限訪問hub集群的特定資源是被對應ManagedClusterAPI 上的hubAcceptsClient域來控制的。只有當這個域被置位true時，hub集群的控制器才會為對應klusterlet賦予權限。而設置這個域需要用戶在hub集群中對managedcluster/accept具有update權限才可以。如下面的clusterrole的例子表示用戶只能對cluster1這個ManagedCluster上的klusterlet賦予權限。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: open-cluster-management:hub
rules:
- apiGroups: ["register.open-cluster-management.io"]
resources: ["managedclusters/accept"]
verbs: ["update"]
resourceNames: ["cluster1"]將認證和授權的流程分開的原因是通常情況下hub集群具有approve CSR權限的用戶和"允許 klusterlet 接入 hub"集群的用戶并不完全一致。以上機制就可以保證即使用戶擁有approve CSR的權限也不能給任意的klusterlet賦予接入hub集群的權限。
實現細節
所有認證授權和秘鑰管理的代碼實現都在registration[2]組件中。大概的流程 如下圖所示
當registration-agent在被管理集群中啟動后，會首先在自己的namespace里查找是否有hub-kubeconfig的秘鑰并驗證這個秘鑰是否合法。如果不存在或者不合法，registration-agent就進入了 bootstrap 流程，它會首先產生一個動態的agent ID, 然后使用一個更小權限的bootstrap-kubeconfig來創建 client 和 informer，接下來啟動一個ClientCertForHubController的 goroutine。這個 controller 會在 hub 集群創建 CSR，等待 CSR 中簽署的證書并最終把證書和私鑰做為名為hub-kubeconfig的秘鑰持久化在被管理集群中。agent 接著持續監控hub-kubeconfig這個秘鑰是否已經被持久化。當 agent 發現hub-kubeconfig則意味著 agent 已經獲取到了可以訪問hub集群的客戶證書，agent 就會停掉之前的 controller 并退出 bootstrap 流程。接下來 agent 會重新用hub-kubeconfig創建 client 和 informer，并啟動一個新的ClientCertForHubController的 goroutine 來定期刷新客戶證書。
在 hub 集群中的registration-controller會啟動CSRApprovingController用來負責檢查klusterlet發起的 CSR 請求是否可以自動簽發；以及managedClusterController用來檢查對應ManagedCluster上的hubAccepctsClient域是否被設置并在hub集群中創建相應的權限。
參考資料
[1]CSR: https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
[2]registration: https://github.com/open-cluster-management-io/registration
作者：邱見
