Kubernetes 的新武器：層級(jí)命名空間

在單個(gè) Kubernetes 集群上安全托管大量用戶一直是一個(gè)老大難問(wèn)題，其中最大的麻煩就是不同的組織以不同的方式使用 Kubernetes，很難找到一種租戶模式可以適配所有組織。相反，Kubernetes 只提供了創(chuàng)建不同租戶模式的基礎(chǔ)構(gòu)件，例如 RBAC 和 NetworkPolicies，這些基礎(chǔ)構(gòu)件實(shí)現(xiàn)得越好，安全構(gòu)建多租戶集群就越容易。

1. 命名空間

其中最重要的基礎(chǔ)構(gòu)件是命名空間（namespace），它構(gòu)成了幾乎所有 Kubernetes 控制平面安全和共享策略的骨干。命名空間有兩個(gè)關(guān)鍵屬性，使其成為策略執(zhí)行的理想選擇：

• 首先，命名空間可以用來(lái)代表所有權(quán)。大多數(shù) Kubernetes 對(duì)象資源必須在某一個(gè)命名空間中，所以如果使用命名空間來(lái)代表所有權(quán)，那么命名空間中的所有對(duì)象都隸屬于同一個(gè)所有者。
• 其次，命名空間的創(chuàng)建和使用需要授權(quán)。只有超級(jí)管理員才能創(chuàng)建命名空間，其他用戶需要明確的權(quán)限才能使用這些命名空間（包括創(chuàng)建、查看和修改命名空間中的資源對(duì)象）?？梢栽O(shè)置恰當(dāng)?shù)陌踩呗裕乐狗翘貦?quán)用戶創(chuàng)建某些資源對(duì)象。

2. 命名空間的限制

然而在實(shí)際使用中，命名空間還是不夠靈活，無(wú)法滿足一些常見(jiàn)的用例。假設(shè)一個(gè)團(tuán)隊(duì)擁有好幾套微服務(wù)環(huán)境，每一套微服務(wù)環(huán)境都有自己的秘鑰和資源配額，理想情況下應(yīng)該將不同的微服務(wù)環(huán)境放到不同的命名空間中，以便相互隔離。但這樣會(huì)帶來(lái)兩個(gè)問(wèn)題：

• 首先，不同的命名空間沒(méi)有共同的所有權(quán)概念，即使它們屬于同一個(gè)團(tuán)隊(duì)。如果某個(gè)團(tuán)隊(duì)控制了多個(gè)命名空間，Kubernetes 不僅沒(méi)有任何關(guān)于這些命名空間的共同所有者的記錄，而且針對(duì)命名空間范圍內(nèi)的策略也無(wú)法跨多個(gè)命名空間生效。
• 其次，如果團(tuán)隊(duì)能夠自主運(yùn)作，團(tuán)隊(duì)協(xié)作效率會(huì)更高。但創(chuàng)建命名空間是需要高級(jí)權(quán)限的，所以開(kāi)發(fā)團(tuán)隊(duì)的任何成員都不可能有權(quán)限創(chuàng)建命名空間。這就意味著，每當(dāng)某個(gè)團(tuán)隊(duì)想要?jiǎng)?chuàng)建新的命名空間時(shí)，就必須向集群管理員提出申請(qǐng)，這種方式對(duì)小規(guī)模組織還可以接受，但隨著組織的發(fā)展壯大，勢(shì)必需要尋求更佳的方案。

3. 層級(jí)命名空間介紹

層級(jí)命名空間（hierarchical namespaces）^[1]是 Kubernetes 多租戶工作組（Working Group for Multi-Tenancy，wg-multitenancy）^[2] 為了解決這些問(wèn)題而提出的新概念。在最簡(jiǎn)單的形式下，層級(jí)命名空間就是一個(gè)常規(guī)的命名空間，它標(biāo)識(shí)了一個(gè)單一的、可選的父命名空間；更復(fù)雜的形式下，父命名空間還可以繼承出子空間。這樣就建立了跨命名空間的所有權(quán)概念，而不是局限于命名空間內(nèi)。

這種層級(jí)命名空間的所有權(quán)可以在命名空間的基礎(chǔ)上實(shí)現(xiàn)額外的兩種功能：

• 策略繼承 : 如果一個(gè)命名空間是另一個(gè)命名空間的子空間，那么權(quán)限策略（例如 RBAC RoleBindings）將會(huì)從父空間直接復(fù)制到子空間^[3]。
• 繼承創(chuàng)建權(quán)限 : 通常情況下，需要管理員權(quán)限才能創(chuàng)建命名空間。但層級(jí)命名空間提供了一個(gè)新方案：子命名空間（subnamespaces）^[4]，只需要使用父命名空間中的部分權(quán)限即可操作子命名空間。

有了這兩個(gè)功能后，集群管理員就可以為團(tuán)隊(duì)創(chuàng)建一個(gè)『根』命名空間，以及所有必要的權(quán)限策略，然后將創(chuàng)建子命名空間的權(quán)限賦予該團(tuán)隊(duì)的成員。這樣團(tuán)隊(duì)內(nèi)的成員就可以在不違反集群策略的情況下創(chuàng)建自己的子命名空間。

4. 示例

層級(jí)命名空間由 Kubernetes 的層級(jí)命名空間控制器（Hierarchical Namespace Controller，HNC）^[5]。HNC 包含兩個(gè)組件：

• 控制器 : 控制器運(yùn)行在集群中，用來(lái)管理子命名空間，傳遞策略對(duì)象，確保層次結(jié)構(gòu)的合理性，并管理擴(kuò)展點(diǎn)。
• kubectl 插件 : 插件名叫 kubectl-hns，用戶可以使用該插件和控制器進(jìn)行交互。

控制器和插件的安裝請(qǐng)參考 release 頁(yè)面^[6]。

下面舉一個(gè)簡(jiǎn)單的例子，假設(shè)某團(tuán)隊(duì)成員沒(méi)有創(chuàng)建命名空間的權(quán)限，但可以查看命名空間 team-a，也可以為其創(chuàng)建子命名空間。使用 kubectl 插件執(zhí)行以下命令：

$ kubectl hns create svc1-team-a -n team-a

這個(gè)命令創(chuàng)建了一個(gè)字命名空間 svc1-team-a。字命名空間也是常規(guī)的命名空間，所以名稱(chēng)不能重復(fù)。

查看命名空間的層級(jí)結(jié)構(gòu)：

$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a

如果父命名空間中有任何策略，都會(huì)被繼承到子命名空間中。例如，假設(shè)  team-a 中有一個(gè)名為 sres 的 RBAC RoleBinding，那么它也會(huì)出現(xiàn)在子命名空間中：

$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name:         sres
Labels:       hnc.x-k8s.io/inheritedFrom=team-a  # inserted by HNC
Annotations:  
      
       
Role:
       
  Kind:  ClusterRole
       
  Name:  admin
       
Subjects: ...
       

      

HNC 還為層級(jí)命名空間添加了相關(guān)標(biāo)簽，其中包含了層級(jí)結(jié)構(gòu)的相關(guān)信息，你可以用來(lái)設(shè)置其他的策略。例如，可以創(chuàng)建以下 NetworkPolicy：

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-team-a
  namespace: team-a
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchExpressions:
          - key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
            operator: Exists

該策略會(huì)傳遞給 team-a 的所有子命名空間，也會(huì)允許所有這些字命名空間之間的 ingress 流量。這些 "tree" 標(biāo)簽只能由 HNC 創(chuàng)建，用來(lái)確保最新的層級(jí)結(jié)構(gòu)。

關(guān)于 HNC 的更多信息請(qǐng)參考用戶指南^[7]。

參考資料

你可能還喜歡

點(diǎn)擊下方圖片即可閱讀

云原生是一種信仰 ?

掃碼關(guān)注公眾號(hào)

后臺(tái)回復(fù)?k8s?獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！