目錄
文章目錄
- 目錄
- 基于命名空間的多用戶模型
- 基于層級命名空間的多租戶隔離
- 示例
基于命名空間的多用戶模型
在單個 Kubernetes Cluster 上安全托管多用戶一直是個難題，其中最大的麻煩就是不同的組織會以不同的方式使用 Kubernetes，很難找到一種通用的多用戶模型來適配所有組織，但是，Kubernetes 只提供了創建不同多用戶模型的基礎構件，例如：Namesapce、RBAC、NetworkPolicies，
其中最重要的就是 Namespace，它構成了 Kubernetes 控制平面的安全和共享策略的骨干，Namespace 有兩個關鍵屬性，使其成為策略執行的理想選擇：
-
首先，Namespace 可以用于表示所有權，通常的，Kubernetes 大多數的物件資源都會被劃分到某個 Namespace 中，所以，如果我們使用 Namespace 來代表資源的所有權的話，那么一個 Namespace 中的所有資源物件都被描述為屬于同一個用戶，
-
其次，Namespace 的創建和使用需要進行認證、鑒權、授權，只有超級管理員才能創建 Namesapce，其他用戶需要明確的權限才能使用這些 Namespace，包括：創建、查看和修改 Namespace 下屬的資源物件，所以，可以通過設定恰當的安全策略，來防止非特權用戶操作特定的資源物件，
然而在實際使用中，Namespace 還是不夠靈活，甚至無法滿足一些常見的 UseCase，例如：假設一個團隊擁有好幾套微服務環境，每一套微服務環境都有著各自的秘鑰和資源配額，理想情況下應該將不同的微服務環境劃分到不同的 Namespace 中，以便相互隔離，但這樣會帶來兩個問題：
-
不同的 Namespace 沒有共同所有權的概念，即：同一個團隊無法使用同一套賬戶鑒權來同時控制多個不同的 Namespace，Kubernetes 不僅沒有任何關于這些 Namespace 的共同所有者的記錄，而且針對某個 Namespace 的策略也無法跨空間生效，
-
其次，如果團隊能夠自主運作，那么團隊協作效率會更高，但 Namespace 的創建需要高級權限的超級管理員賬戶，所以開發團隊的普通成員都沒有權限新建一個 Namespace，這就意味著，對于上規模的組織而言是無法接受這種頻繁的 New Namespace 申請的，
基于層級命名空間的多租戶隔離
可見，僅僅基于 Namespace 只能實作 “多用戶（User）”，而非 “多租戶（Tenant）”，
層級命名空間（hierarchical namespaces）就是 Kubernetes 多租戶作業組（Working Group for Multi-Tenancy，wg-multitenancy）為了解決這些問題而提出的新概念，
- 在最簡單的形式下，HN 就是一個常規的 Namespace，它標識了一個單一的、可選的父命名空間；
- 更復雜的形式下，父命名空間還可以繼承出子命名空間（sub namespaces），
這樣就建立了跨命名空間的所有權概念，而不是局限于命名空間內，
層級命名空間的所有權可以在命名空間的基礎上實作額外的兩個關鍵功能：
- 繼承策略 : 如果一個命名空間是另一個命名空間的子空間，那么權限策略（e.g. RBAC RoleBindings）將會從父空間直接繼承到子空間，
- 繼承創建權限 : 通常情況下，需要管理員權限才能創建命名空間，但層級命名空間提供了一個新方案：只需要使用父命名空間中的部分權限即可操作子命名空間，
有了這兩個功能后，超級管理員就可以為團隊創建一個 Root Namespace（根命名空間），以及所必要的權限策略，然后將創建子命名空間的權限賦予該團隊的成員，這樣團隊內的成員就可以在不違反集群策略的情況下創建自己的子命名空間，
示例
層級命名空間由 Kubernetes 的層級命名空間控制器（Hierarchical Namespace Controller，HNC）實作，包含兩個組件：
- Controller：運行在 Master 中，用來管理子命名空間，傳遞策略物件，確保層次結構的合理性，并管理擴展點，
- kubectl-hns（kubectl Plugin） ：用戶可以使用該 Plugin 和 Controller 進行互動，
下面舉一個簡單的例子，假設某團隊成員沒有創建命名空間的權限，但可以查看命名空間 team-a，也可以為其創建子命名空間，使用 kubectl 插件執行以下命令即可完成 Sub Namespace 的創建（注：字命名空間也是常規的命名空間，所以名稱不能重復，）：
$ kubectl hns create svc1-team-a -n team-a
查看命名空間的層級結構：
$ kubectl hns tree team-a
team-a
└── svc1-team-a
父命名空間中的任何策略，都會被繼承到子命名空間中，例如：假設 team-a 中有一個名為 sres 的 RBAC RoleBinding，那么它也會出現在子命名空間中：
$ kubectl describe rolebinding sres -n svc1-team-a
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: ...
HNC 還為層級命名空間添加了相關的 Label，其中包含了層級結構的相關資訊，你可以用來設定其他的策略，例如：可以創建以下 NetworkPolicy，該策略會傳遞給 team-a 的所有子命名空間，也會允許所有這些子命名空間之間的 ingress 流量，這些 “tree” 標簽只能由 HNC 創建，用來確保最新的層級結構，
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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/227178.html
標籤：其他
上一篇：Java知識