解决多租户集群的安全隔离问题对于企业上云而言至关重要。本文讨论了 Kubernetes 多租户集群的概念和常见的应用模式、企业内共享集群的业务场景以及 Kubernetes 现有的安全管理功能。

什么是多租户集群

首先,我们讨论一下“租户”是什么。租户的概念不仅是集群用户,还包括构成计算、网络、存储和其他资源的工作负载集。在多租户集群中,对单个集群中不同租户进行隔离,这样恶意租户就无法攻击其他租户,共享集群资源也能合理地分配给租户。

根据隔离的安全级别,可以将集群分为软隔离(Soft Multi-tenancy)和硬隔离(Hard Multi-tenancy)软隔离适用于企业内的多租户集群,因为默认情况下不会有恶意租户。在这种情况下,软隔离主要是保护内部团队之间的业务并防护可能的安全攻击。硬隔离适用于那些提供对外服务的服务提供商。由于业务模式,不能保证不同租户中业务用户的安全背景,所以集群中的租户和 Kubernetes 系统可能会相互攻击,这时需要严格的隔离以确保安全性。下面会对不同的多租户方案进行更详细的描述。

多租户应用场景

下面介绍两种不同隔离要求的企业多租户方案:

企业内共享集群的多租户

这种场景下,所有集群用户都来自企业,这也是许多 Kubernetes 集群客户的使用场景。由于服务用户的身份是可控的,因此这种业务模式的安全风险也相对可控,毕竟老板可以直接开掉有问题的员工。根据企业内部人员的结构,企业可以通过命名空间,按照逻辑对不同部门或团队的资源进行隔离。另外,定义具有以下角色的业务人员:

  • 集群管理员
    • 具有集群管理功能,例如伸缩容、添加节点等
    • 为租户管理员创建并分配命名空间
    • 管理各种策略,例如 RAM、RBAC、NetworkPolicy 以及 quota
  • 租户管理员
    • 至少拥有集群 RAM 只读权限
    • 管理租户中相关人员的 RBAC 配置
  • 租户用户
    • 在租户命名空间允许范围内使用 Kubernetes 资源

除了用户角色的访问控制之外,我们还要确保命名空间之间的网络隔离,不同命名空间之间只允许白名单内的跨租户应用程序请求。

SaaS 和 KaaS 服务模型中的多租户

在 SaaS 多租户场景中,Kubernetes 集群中的租户是 SaaS 平台和 SaaS 控制平面上的服务应用程序实例。在这种场景下,平台的服务应用程序实例分为不同的命名空间。服务的最终用户无法与 Kubernetes 控制平面组件进行交互。这些最终用户可以通过自定义的 SaaS 控制平面访问和使用 SaaS 控制台,使用服务或部署业务,如下左图所示。例如,假设博客平台已部署并在多租户集群上运行。在这种情况下,租户是每个客户的博客实例和平台的控制平面。平台控制平面和每个托管博客都在不同的命名空间中运行。

KaaS 多租户方案通常与云服务提供商有关。在这种场景下,业务平台的服务通过 Kubernetes 控制平面直接暴露给不同租户的用户。最终用户可以使用服务提供商提供的 Kubernetes API 或其他扩展 API。为了满足隔离要求,不同的租户同样需要使用命名空间按照逻辑对访问进行隔离,同时确保不同租户的网络和资源配额的隔离。

与企业内的共享集群相反,这里的最终用户都来自非受信区域,所以可能会有在服务平台上运行恶意代码的恶意租户。对此,SaaS 和 KaaS 服务模型中的多租户集群需要更强的安全隔离。在这种场景下,Kubernetes 现有的原生功能还无法满足安全要求,因此需要在运行时进行内核级别的隔离来增强此业务场景中的租户安全性。