概述

在open-cluster-management中，為了使控制面有更好的可擴(kuò)展性，我們使用了hub-spoke的架構(gòu)：即集中的控制面（hub）只負(fù)責(zé)處理控制面的資源和數(shù)據(jù)而無(wú)需訪問(wèn)被管理的集群；每個(gè)被管理集群（spoke）運(yùn)行一個(gè)稱(chēng)為klusterlet的 agent 訪問(wèn)控制面獲取需要執(zhí)行的任務(wù)。在這個(gè)過(guò)程中，klusterlet需要擁有訪問(wèn)hub集群的秘鑰才能和hub安全通信。確保秘鑰的安全性是非常重要的，因?yàn)槿绻@個(gè)秘鑰被泄露的話有可能導(dǎo)致對(duì) hub 集群的惡意訪問(wèn)或者竊取敏感信息，特別是當(dāng)ocm的被管理集群分布在不同的公有云中的時(shí)候。為了保證秘鑰的安全性，我們需要滿足一些特定的需求：

1. 盡量避免秘鑰在公有網(wǎng)絡(luò)中的傳輸
2. 秘鑰的刷新和廢除
3. 細(xì)粒度的權(quán)限控制

本文將詳細(xì)介紹ocm是如何實(shí)現(xiàn)秘鑰的管理來(lái)保證控制面板和被管理集群之間的安全訪問(wèn)的。

架構(gòu)和機(jī)制

在 ocm 中我們采用了以下幾個(gè)機(jī)制來(lái)確保控制面和被管理集群之間訪問(wèn)的安全性：

1. 基于CertificateSigniningRequest的 mutual tls
2. 雙向握手協(xié)議和動(dòng)態(tài)klusterletID
3. 認(rèn)證和授權(quán)的分離

基于CertificateSigniningRequest的 mutual tls

使用kubernetes的CertificateSigniningRequest（CSR[1]）API 可以方便的生成客戶認(rèn)證證書(shū)。這個(gè)機(jī)制可以讓klusterlet在第一次啟動(dòng)訪問(wèn)hub集群時(shí)使用一個(gè)權(quán)限很小的秘鑰來(lái)創(chuàng)建 CSR。當(dāng) CSR 返回了生成的證書(shū)后，klusterlet就可以用后續(xù)生成的帶有更大訪問(wèn)權(quán)限的證書(shū)來(lái)訪問(wèn)hub集群。在使用 csr 的過(guò)程中，klusterlet的私鑰不會(huì)在網(wǎng)絡(luò)中傳輸而是一直保存在被管理集群中；只有 CSR 的公鑰和初始階段需要的小權(quán)限秘鑰（bootstrap secret）會(huì)在不同集群間傳輸。這就最大程度的保證秘鑰不會(huì)在傳輸過(guò)程中被泄露出去。

雙向握手協(xié)議和動(dòng)態(tài)klusterletID

那么如果初始階段的 bootstrap secret 被泄露了會(huì)怎么樣呢？這就牽涉到 OCM 中的雙向握手協(xié)議。當(dāng)被管理集群中的klusterlet使用 bootstrap secret 發(fā)起了第一次請(qǐng)求的時(shí)候，hub 集群不會(huì)立刻為這個(gè)請(qǐng)求創(chuàng)建客戶證書(shū)和對(duì)應(yīng)的訪問(wèn)權(quán)限。這個(gè)請(qǐng)求將處在Pending狀態(tài)，直到 hub 集群擁有特定管理權(quán)限的管理員同意了klusterlet的接入請(qǐng)求后，客戶證書(shū)和特定權(quán)限才會(huì)被創(chuàng)建出來(lái)。這個(gè)請(qǐng)求中包含了klusterlet啟動(dòng)階段生成的動(dòng)態(tài) ID，管理員需要確保這個(gè) ID 和被管理集群上klusterlet的 ID 一致才能同意klusterlet的接入。這也就確保了如果 bootstrap secret 被不慎泄露后，CSR 也不會(huì)被管理員輕易的接受。

klusterlet使用的客戶證書(shū)是有過(guò)期時(shí)間的，klusterlet需要在證書(shū)過(guò)期之前使用現(xiàn)有的客戶證書(shū)發(fā)起新的CSR請(qǐng)求來(lái)獲取新的客戶證書(shū)。hub集群會(huì)檢驗(yàn)更新證書(shū)的CSR請(qǐng)求是否合法并自動(dòng)簽署新的客戶證書(shū)。需要注意的是由于klusterlet使用了動(dòng)態(tài) ID 的機(jī)制，只有klusterlet本身發(fā)起的CSR請(qǐng)求才會(huì)被自動(dòng)簽署。如果klusterlet在集群中被卸載然后重新部署后，它必須重新使用 bootstrap secret 流程來(lái)獲取客戶證書(shū)。

認(rèn)證和授權(quán)的分離

在klusterlet的CSR請(qǐng)求被接受后，它獲得了被hub集群認(rèn)證通過(guò)的客戶證書(shū)，但是它在這個(gè)時(shí)候還沒(méi)有對(duì)hub集群上特定資源訪問(wèn)的權(quán)限。ocm中還有一個(gè)單獨(dú)的授權(quán)流程。每個(gè)被管理集群的klusterlet時(shí)候有權(quán)限訪問(wèn)hub集群的特定資源是被對(duì)應(yīng)ManagedClusterAPI 上的hubAcceptsClient域來(lái)控制的。只有當(dāng)這個(gè)域被置位true時(shí)，hub集群的控制器才會(huì)為對(duì)應(yīng)klusterlet賦予權(quán)限。而設(shè)置這個(gè)域需要用戶在hub集群中對(duì)managedcluster/accept具有update權(quán)限才可以。如下面的clusterrole的例子表示用戶只能對(duì)cluster1這個(gè)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)的流程分開(kāi)的原因是通常情況下hub集群具有approve CSR權(quán)限的用戶和"允許 klusterlet 接入 hub"集群的用戶并不完全一致。以上機(jī)制就可以保證即使用戶擁有approve CSR的權(quán)限也不能給任意的klusterlet賦予接入hub集群的權(quán)限。

實(shí)現(xiàn)細(xì)節(jié)

所有認(rèn)證授權(quán)和秘鑰管理的代碼實(shí)現(xiàn)都在registration[2]組件中。大概的流程 如下圖所示

當(dāng)registration-agent在被管理集群中啟動(dòng)后，會(huì)首先在自己的namespace里查找是否有hub-kubeconfig的秘鑰并驗(yàn)證這個(gè)秘鑰是否合法。如果不存在或者不合法，registration-agent就進(jìn)入了 bootstrap 流程，它會(huì)首先產(chǎn)生一個(gè)動(dòng)態(tài)的agent ID, 然后使用一個(gè)更小權(quán)限的bootstrap-kubeconfig來(lái)創(chuàng)建 client 和 informer，接下來(lái)啟動(dòng)一個(gè)ClientCertForHubController的 goroutine。這個(gè) controller 會(huì)在 hub 集群創(chuàng)建 CSR，等待 CSR 中簽署的證書(shū)并最終把證書(shū)和私鑰做為名為hub-kubeconfig的秘鑰持久化在被管理集群中。agent 接著持續(xù)監(jiān)控hub-kubeconfig這個(gè)秘鑰是否已經(jīng)被持久化。當(dāng) agent 發(fā)現(xiàn)hub-kubeconfig則意味著 agent 已經(jīng)獲取到了可以訪問(wèn)hub集群的客戶證書(shū)，agent 就會(huì)停掉之前的 controller 并退出 bootstrap 流程。接下來(lái) agent 會(huì)重新用hub-kubeconfig創(chuàng)建 client 和 informer，并啟動(dòng)一個(gè)新的ClientCertForHubController的 goroutine 來(lái)定期刷新客戶證書(shū)。

在 hub 集群中的registration-controller會(huì)啟動(dòng)CSRApprovingController用來(lái)負(fù)責(zé)檢查klusterlet發(fā)起的 CSR 請(qǐng)求是否可以自動(dòng)簽發(fā)；以及managedClusterController用來(lái)檢查對(duì)應(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

作者：邱見(jiàn)