2同行回答
在实施多租户架构时首先需要确定对应的应用场景，包括判断租户内用户和应用负载的可信程度以及对应的安全隔离程度。在此基础上以下几点是安全隔离的基本需求：
开启Kubernetes集群的默认安全配置
- 开启RBAC鉴权，禁止匿名用户访问
- 开启secrets encryption能力，增强敏感信息保护
- 基于CIS kubernetes benchmarks进行相应的安全配置
- 开启NodeRestriction， AlwaysPullImages, PodSecurityPolicy等相关admission controllers
- 通过PSP限制pod部署的特权模式，同时控制其运行时刻SecurityContext配置NetworkPolicy
- Docker 运行时刻开启Seccomp/AppArmor/SELinux配置
- 尽量实现监控、日志等服务的多租隔离
租户的概念不止局限于集群的用户，它可以包含为一组计算，网络，存储等资源组成的工作负载集合。而在多租户集群中，需要在一个集群范围内（未来可能会是多集群）对不同的租户提供尽可能的安全隔离，以最大程度的避免恶意租户对其他租户的攻击，同时需要保证租户之间公平地分配共享集群资源。
在隔离的安全程度上，我们可以将其分为软隔离 (Soft Multi-tenancy) 和硬隔离（Hard Multi-tenancy）两种。其中软隔离更多的是面向企业内部的多租需求，该形态下默认不存在恶意租户，隔离的目的是为了内部团队间的业务保护和对可能的安全攻击进行防护；而硬隔离面向的更多是对外提供服务的服务供应商，由于该业务形态下无法保证不同租户中业务使用者的安全背景，我们默认认为租户之间以及租户与 k8s 系统之间是存在互相攻击的可能，因此这里也需要更严格的隔离作为安全保障。
多租户应用场景
下面介绍一下典型的两种企业多租户应用场景和不同的隔离需求：
1）企业内部共享集群的多租户
该场景下集群的所有用户均来自企业内部，这也是当前很多 k8s 集群客户的使用模式，因为服务使用者身份的可控性，相对来说这种业务形态的安全风险是相对可控的，毕竟老板可以直接裁掉不怀好意的员工：）根据企业内部人员结构的复杂程度，我们可以通过命名空间对不同部门或团队进行资源的逻辑隔离，同时定义以下几种角色的业务人员：
- 集群管理员：
具有集群的管理能力（扩缩容、添加节点等操作）
负责为租户管理员创建和分配命名空间
负责各类策略（RAM/RBAC/networkpolicy/quota…）的 CRUD
- 租户管理员
至少具有集群的 RAM 只读权限
管理租户内相关人员的 RBAC 配置
- 租户内用户
在租户对应命名空间内使用权限范围内的 k8s 资源
在建立了基于用户角色的访问控制基础上，我们还需要保证命名空间之间的网络隔离，在不同的命名空间之间只能够允许白名单范围内的跨租户应用请求。
另外，对于业务安全等级要求较高的应用场景，我们需要限制应用容器的内核能力，可以配合 seccomp/AppArmor/SELinux 等策略工具达到限制容器运行时刻 capabilities 的目的。
2）SaaS & KaaS 服务模型下的多租户
在 SaaS 多租场景下，kubernetes 集群中的租户对应为 SaaS 平台中各服务应用实例和 SaaS 自身控制平面，该场景下可以将平台各服务应用实例划分到彼此不同的命名空间中。而服务的最终用户是无法与 Kubernetes 的控制平面组件进行交互，这些最终用户能够看到和使用的是 SaaS 自身控制台，他们通过上层定制化的 SaaS 控制平面使用服务或部署业务（如下左图所示）。例如，某博客平台部署在多租户集群上运行。在该场景下，租户是每个客户的博客实例和平台自己的控制平面。平台的控制平面和每个托管博客都将在不同的命名空间中运行。客户将通过平台的界面来创建和删除博客、更新博客软件版本，但无法了解集群的运作方式。
KaaS 多租场景常见于云服务提供商，该场景下业务平台的服务直接通过 Kubernetes 控制平面暴露给不同租户下的用户，最终用户可以使用 k8s 原生 API 或者服务提供商基于 CRDs/controllers 扩展出的接口。出于隔离的最基本需求，这里不同租户也需要通过命名空间进行访问上的逻辑隔离，同时保证不同租户间网络和资源配额上的隔离。
与企业内部共享集群不同，这里的最终用户均来自非受信域，他们当中不可避免的存在恶意租户在服务平台上执行恶意代码，因此对于 SaaS/KaaS 服务模型下的多租户集群，我们需要更高标准的安全隔离，而 kubernetes 现有原生能力还不足以满足安全上的需求，为此我们需要如安全容器这样在容器运行时刻内核级别的隔离来强化该业务形态下的租户安全。
收起