Kubernetes — 基于层级命名空间的多租户隔离

目录

基于命名空间的多用户模型

在单个 Kubernetes Cluster 上安全托管多用户一直是个难题。其中最大的麻烦就是不同的组织会以不同的方式使用 Kubernetes,很难找到一种通用的多用户模型来适配所有组织。但是,Kubernetes 只提供了创建不同多用户模型的基础构件,例如:Namesapce、RBAC、NetworkPolicies。

其中最重要的就是 Namespace,它构成了 Kubernetes 控制平面的安全和共享策略的骨干。Namespace 有两个关键属性,使其成为策略执行的理想选择:

  1. 首先,Namespace 可以用于表示所有权。通常的,Kubernetes 大多数的对象资源都会被划分到某个 Namespace 中。所以,如果我们使用 Namespace 来代表资源的所有权的话,那么一个 Namespace 中的所有资源对象都被描述为属于同一个用户。

  2. 其次,Namespace 的创建和使用需要进行认证、鉴权、授权。只有超级管理员才能创建 Namesapce,其他用户需要明确的权限才能使用这些 Namespace,包括:创建、查看和修改 Namespace 下属的资源对象。所以,可以通过设置恰当的安全策略,来防止非特权用户操作特定的资源对象。

然而在实际使用中,Namespace 还是不够灵活,甚至无法满足一些常见的 UseCase。例如:假设一个团队拥有好几套微服务环境,每一套微服务环境都有着各自的秘钥和资源配额,理想情况下应该将不同的微服务环境划分到不同的 Namespace 中,以便相互隔离。但这样会带来两个问题:

  1. 不同的 Namespace 没有共同所有权的概念,即:同一个团队无法使用同一套账户鉴权来同时控制多个不同的 Namespace。Kubernetes 不仅没有任何关于这些 Namespace 的共同所有者的记录,而且针对某个 Namespace 的策略也无法跨空间生效。

  2. 其次,如果团队能够自主运作,那么团队协作效率会更高。但 Namespace 的创建需要高级权限的超级管理员账户,所以开发团队的普通成员都没有权限新建一个 Namespace。这就意味着,对于上规模的组织而言是无法接受这种频繁的 New Namespace 申请的。

基于层级命名空间的多租户隔离

可见,仅仅基于 Namespace 只能实现 “多用户(User)”,而非 “多租户(Tenant)”。

层级命名空间(hierarchical namespaces)就是 Kubernetes 多租户工作组(Working Group for Multi-Tenancy,wg-multitenancy)为了解决这些问题而提出的新概念。

  • 在最简单的形式下,HN 就是一个常规的 Namespace,它标识了一个单一的、可选的父命名空间;
  • 更复杂的形式下,父命名空间还可以继承出子命名空间(sub namespaces)。

这样就建立了跨命名空间的所有权概念,而不是局限于命名空间内。

层级命名空间的所有权可以在命名空间的基础上实现额外的两个关键功能:

  1. 继承策略 : 如果一个命名空间是另一个命名空间的子空间,那么权限策略(e.g. RBAC RoleBindings)将会从父空间直接继承到子空间。
  2. 继承创建权限 : 通常情况下,需要管理员权限才能创建命名空间。但层级命名空间提供了一个新方案:只需要使用父命名空间中的部分权限即可操作子命名空间。

有了这两个功能后,超级管理员就可以为团队创建一个 Root Namespace(根命名空间),以及所必要的权限策略,然后将创建子命名空间的权限赋予该团队的成员。这样团队内的成员就可以在不违反集群策略的情况下创建自己的子命名空间。

示例

层级命名空间由 Kubernetes 的层级命名空间控制器(Hierarchical Namespace Controller,HNC)实现,包含两个组件:

  1. Controller:运行在 Master 中,用来管理子命名空间,传递策略对象,确保层次结构的合理性,并管理扩展点。
  2. 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
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 博客之星2020 设计师:CY__0809 返回首页
实付 49.00元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值