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