如何解决多租户集群的安全隔离问题是企业上云的一个关键问题,本文主要介绍kubernetes多租户集群的基本概念和常见应用形态,以及在企业内部共享集群的业务场景下,基于kubernetes原生和ACK集群现有安全管理能力快速实现多租户集群的相关方案。
什么是多租户集群?
---------
这里首先介绍一下"租户",租户的概念不止局限于集群的用户,它可以包含为一组计算,网络,存储等资源组成的工作负载集合。而在多租户集群中,需要在一个集群范围内(未来可能会是多集群)对不同的租户提供尽可能的安全隔离,以最大程度的避免恶意租户对其他租户的攻击,同时需要保证租户之间公平地分配共享集群资源。
在隔离的安全程度上,我们可以将其分为软隔离(Soft Multi-tenancy)和硬隔离(Hard Multi-tenancy)两种。其中软隔离更多的是面向企业内部的多租需求,该形态下默认不存在恶意租户,隔离的目的是为了内部团队间的业务保护和对可能的安全攻击进行防护;而硬隔离面向的更多是对外提供服务的服务供应商,由于该业务形态下无法保证不同租户中业务使用者的安全背景,我们默认认为租户之间以及租户与k8s系统之间是存在互相攻击的可能,因此这里也需要更严格的隔离作为安全保障。关于多租户的不同应用场景,在下节会有更细致的介绍。
![多租1.png](https://ata2-img.cn-hangzhou.oss-pub.aliyun-inc.com/c1c4c4861c9cb16fb99aa4dbe24b00cd.png)
多租户应用场景
-------
下面介绍一下典型的两种企业多租户应用场景和不同的隔离需求:
### 1)企业内部共享集群的多租户
该场景下集群的所有用户均来自企业内部,这也是当前很多k8s集群客户的使用模式,因为服务使用者身份的可控性,相对来说这种业务形态的安全风险是相对可控的,毕竟老板可以直接裁掉不怀好意的员工:)根据企业内部人员结构的复杂程度,我们可以通过命名空间对不同部门或团队进行资源的逻辑隔离,同时定义以下几种角色的业务人员:
* 集群管理员:
* 具有集群的管理能力(扩缩容、添加节点等操作)
* 负责为租户管理员创建和分配命名空间
* 负责各类策略(RAM/RBAC/networkpolicy/quota...)的CRUD
* 租户管理员
* 至少具有集群的RAM只读权限
* 管理租户内相关人员的RBAC配置
* 租户内用户
* 在租户对应命名空间内使用权限范围内的k8s资源
在建立了基于用户角色的访问控制基础上,我们还需要保证命名空间之间的网络隔离,在不同的命名空间之间只能够允许白名单范围内的跨租户应用请求。
另外,对于业务安全等级要求较高的应用场景,我们需要限制应用容器的内核能力,可以配合seccomp/AppArmor/SELinux等策略工具达到限制容器运行时刻capabilities的目的。
![多租6.png](https://ata2-img.cn-hangzhou.oss-pub.aliyun-inc.com/5574d4df1ed6809af404acbcc254b32f.png)
当然Kubernetes现有的命名空间单层逻辑隔离还不足以满足一部分大型企业应用复杂业务模型对隔离需求,我们可以关注[Virtual Cluster](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RseBCBhb5u_g6iwpVABP--XHhKi6I9-i_UTB8QJrT9k%2Fedit),它通过抽象出更高级别的租户资源模型来实现更精细化的多租管理,以此弥补原生命名空间能力上的不足。
#### 2)SaaS & KaaS 服务模型下的多租户
在SaaS多租场景下,kubernetes集群中的租户对应为SaaS平台中各服务应用实例和SaaS自身控制平面,该场景下可以将平台各服务应用实例划分到彼此不同的命名空间中。而服务的最终用户是无法与Kubernetes的控制平面组件进行交互,这些最终用户能够看到和使用的是SaaS自身控制台,他们通过上层定制化的SaaS控制平面使用服务或部署业务(如下左图所示)。例如,某博客平台部署在多租户集群上运行。在该场景下,租户是每个客户的博客实例和平台自己的控制平面。平台的控制平面和每个托管博客都将在不同的命名空间中运行。客户将通过平台的界面来创建和删除博客、更新博客软件版本,但无法了解集群的运作方式。
KaaS多租场景常见于云服务提供商,该场景下业务平台的服务直接通过Kubernetes控制平面暴露给不同租户下的用户,最终用户可以使用k8s原生API或者服务提供商基于CRDs/controllers扩展出的接口。出于隔离的最基本需求,这里不同租户也需要通过命名空间进行访问上的逻辑隔离,同时保证不同租户间网络和资源配额上的隔离。
与企业内部共享集群不同,这里的最终用户均来自非受信域,他们当中不可避免的存在恶意租户在服务平台上执行恶意代码,因此对于SaaS/KaaS服务模型下的多租户集群,我们需要更高标准的安全隔离,而kubernetes现有原生能力还不足以满足安全上的需求,为此我们需要如安全容器这样在容器运行时刻内核级别的隔离来强化该业务形态下的租户安全。
![多租5.jpg](https://ata2-img.cn-hangzhou.oss-pub.aliyun-inc.com/21cc36b487e4d47f68951696f5c75214.jpg)
实施多租户架构
-------
在规划和实施多租户集群时,我们首先可以利用的是Kubernetes自身的资源隔离层,包括集群本身,命名空间,节点,pod和容器均是不同层次的资源隔离模型。当不同租户的应用负载能够共享相同的资源模型时,就会存在彼此之间的安全隐患。为此,我们需要在实施多租时控制每个租户能够访问到的资源域,同时在资源调度层面尽可能的保证处理敏感信息的容器运行在相对独立的资源节点内;如果出于资源开销的角度,当有来自不同租户的负载共享同一个资源域时,可以通过运行时刻的安全和资源调度控制策略减少跨租户攻击的风险。
虽然Kubernetes现有安全和调度能力还不足以完全安全地实施多租隔离,但是在如企业内部共享集群这样的应用场景下,通过命名空间完成租户间资源域的隔离,同时通过RBAC、PodSecurityPolicy、NetworkPolicy等策略模型控制租户对资源访问范围和能力的限制,以及现有资源调度能力的结合,已经可以提供相当的安全隔离能力。而对于SaaS、KaaS这样的服务平台形态,我们可以通过容器服务八月即将推出的安全容器来实现容器内核级别的隔离,能够最大程度的避免恶意租户通过逃逸手段的跨租户攻击。
本节重点关注基于Kubernetes原生安全能力的多租户实践。
### 访问控制
#### AuthN & AuthZ & Admission
ACK集群的授权分为RAM授权和RBAC授权两个步骤,其中RAM授权作用于集群管理接口的访问控制,包括对集群的CRUD权限(如集群可见性、扩缩容、添加节点等操作),而RBAC授权用于集群内部kubernetes资源模型的访问控制,可以做到指定资源在命名空间粒度的细化授权。
ACK授权管理为租户内用户提供了不同级别的预置角色模板,同时支持绑定多个用户自定义的集群角色,此外支持对批量用户的授权。如需详细了解ACK上集群相关访问控制授权,请参阅[相关帮助文档](https://help.aliyun.com/document_detail/119596.html?spm=a2c4g.11186623.6.585.385a2fc9sfG2vm)。
#### NetworkPolicy
NetworkPolicy可以控制不同租户业务pod之间的网络流量,另外可以通过白名单的方式打开跨租户之间的业务访问限制。
您可以在使用了Terway网络插件的容器服务集群上配置NetworkPolicy,[这里](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2Fahmetb%2Fkubernetes-network-policy-recipes)可以获得一些策略配置的示例。
#### PodSecurityPolicy
PSP是k8s原生的集群维度的资源模型,它可以在创建pod请求的admission阶段校验其行为是否满足对应PSP策略的要求,比如检查pod是否使用了host的(网络,文件系统,指定端口,PID namespace)等,同时可以限制租户内的用户开启特权(privileged)容器,限制挂盘类型,强制只读挂载等能力;不仅如此,PSP还可以基于绑定的策略给pod添加对应的SecurityContext,包括容器运行时刻的uid,gid和添加或删除的内核capabilities等多种设置。
关于如何开启PSP admission和相关策略及权限绑定的使用,可以参阅[这里](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fzh%2Fdocs%2Fconcepts%2Fpolicy%2Fpod-security-policy%2F%23%25E4%25BB%2580%25E4%25B9%2588%25E6%2598%25AF-pod-%25E5%25AE%2589%25E5%2585%25A8%25E7%25AD%2596%25E7%2595%25A5)
#### OPA
OPA(Open Policy Agent)是一种功能强大的策略引擎,支持解耦式的policy decisions服务并且社区已经有了相对成熟的与kubernetes的[集成方案](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwww.openpolicyagent.org%2Fdocs%2Flatest%2Fkubernetes-admission-control)。当现有RBAC在命名空间粒度的隔离不能够满足企业应用复杂的安全需求时,可以通过OPA提供object模型级别的细粒度访问策略控制。
同时OPA支持七层的NetworkPolicy策略定义及基于labels/annotation的跨命名空间访问控制,可以作为k8s原生NetworkPolicy的有效增强。
### 资源调度相关
#### Resource Quotas & Limit Range
在多租户场景下,不同团队或部门共享集群资源,难免会有资源竞争的情况发生,为此我们需要对每个租户的资源使用配额做出限制。其中ResourceQuota用于限制租户对应命名空间下所有pod占用的总资源request和limit,LimitRange用来设置租户对应命名空间中部署pod的默认资源request和limit值。另外我们还可以对租户的存储资源配额和对象数量配额进行限制。
关于资源配额的详细指导可以参见[这里](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fzh%2Fdocs%2Fconcepts%2Fpolicy%2Fresource-quotas%2F)
#### Pod Priority/Preemption
从1.14版本开始pod的优先级和抢占已经从beta成为稳定特性,其中pod priority标识了pod在pending状态的调度队列中等待的优先级;而当节点资源不足等原因造成高优先的pod无法被调度时,scheduler会尝试驱逐低优先级的pod来保证高优先级pod可以被调度部署。
在多租户场景下,可以通过优先级和抢占设置确保租户内重要业务应用的可用性;同时pod priority可以和ResouceQuota配合使用,完成租户在指定优先级下有多少配额的限制。
#### Dedicated Nodes
**注意****:恶意租户可以规避由节点污点和容忍机制强制执行的策略。以下说明仅用于企业内部受信任租户集群,或租户无法直接访问 Kubernetes 控制平面的集群。**
通过对集群中的某些节点添加污点,可以将这些节点用于指定几个租户专门使用。在多租户场景下,例如集群中的GPU节点可以通过污点的方式保留给业务应用中需要使用到GPU的服务团队使用。集群管理员可以通过如effect: "NoSchedule"这样的标签给节点添加污点,同时只有配置了相应容忍设置的pod可以被调度到该节点上。
当然恶意租户可以同样通过给自身pod添加同样的容忍配置来访问该节点,因此仅使用节点污点和容忍机制还无法在非受信的多租集群上保证目标节点的独占性。
关于如何使用节点污点机制来控制调度,请参阅[这里](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Fconcepts%2Fconfiguration%2Ftaint-and-toleration%2F)。
### 敏感信息保护
#### secrets encryption at REST
在多租户集群中不同租户用户共享同一套etcd存储,在最终用户可以访问Kubernetes控制平面的场景下,我们需要保护secrets中的数据,避免在访问控制策略配置不当情况下的敏感信息泄露。为此可以参考k8s原生的secret加密能力,请参阅[这里](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Ftasks%2Fadminister-cluster%2Fencrypt-data%2F)。
ACK也提供了基于阿里云KMS服务的secrets加密开源解决方案,可以参阅[这里](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2FAliyunContainerService%2Fack-kms-plugin)。
总结
--
在实施多租户架构时首先需要确定对应的应用场景,包括判断租户内用户和应用负载的可信程度以及对应的安全隔离程度。在此基础上以下几点是安全隔离的基本需求:
* 开启Kubernetes集群的默认安全配置
* 开启RBAC鉴权,禁止匿名用户访问
* 开启secrets encryption能力,增强敏感信息保护
* 基于CIS kubernetes benchmarks进行相应的安全配置
* 开启NodeRestriction, AlwaysPullImages, PodSecurityPolicy等相关admission controllers
* 通过PSP限制pod部署的特权模式,同时控制其运行时刻SecurityContext
* 配置NetworkPolicy
* Docker 运行时刻开启Seccomp/AppArmor/SELinux配置
* 尽量实现监控、日志等服务的多租隔离
而对于如SaaS、KaaS等服务模型下,或者我们无法保证租户内用户的可信程度时,我们需要采取一些更强有力的隔离手段,比如:
* 使用如OPA等动态策略引擎进行网络或Object级别的细粒度访问控制
* 使用安全容器实现容器运行时刻内核级别的安全隔离
* 完备的监控,日志,存储等服务的多租隔离方案
[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/739645%3Futm_content%3Dg_1000094672)
本文为阿里云内容,未经允许不得转载。
分享到:
相关推荐
pandas whl安装包,对应各个python版本和系统(具体看资源名字),找准自己对应的下载即可! 下载后解压出来是已.whl为后缀的安装包,进入终端,直接pip install pandas-xxx.whl即可,非常方便。 再也不用担心pip联网下载网络超时,各种安装不成功的问题。
基于java的大学生兼职信息系统答辩PPT.pptx
基于java的乐校园二手书交易管理系统答辩PPT.pptx
tornado-6.4-cp38-abi3-musllinux_1_1_i686.whl
Android Studio Ladybug 2024.2.1(android-studio-2024.2.1.10-mac.dmg)适用于macOS Intel系统,文件使用360压缩软件分割成两个压缩包,必须一起下载使用: part1: https://download.csdn.net/download/weixin_43800734/89954174 part2: https://download.csdn.net/download/weixin_43800734/89954175
有学生和教师两种角色 登录和注册模块 考场信息模块 考试信息模块 点我收藏 功能 监考安排模块 考场类型模块 系统公告模块 个人中心模块: 1、修改个人信息,可以上传图片 2、我的收藏列表 账号管理模块 服务模块 eclipse或者idea 均可以运行 jdk1.8 apache-maven-3.6 mysql5.7及以上 tomcat 8.0及以上版本
tornado-6.1b2-cp38-cp38-macosx_10_9_x86_64.whl
Android Studio Ladybug 2024.2.1(android-studio-2024.2.1.10-mac.dmg)适用于macOS Intel系统,文件使用360压缩软件分割成两个压缩包,必须一起下载使用: part1: https://download.csdn.net/download/weixin_43800734/89954174 part2: https://download.csdn.net/download/weixin_43800734/89954175
matlab
基于java的毕业生就业信息管理系统答辩PPT.pptx
随着高等教育的普及和毕业设计的日益重要,为了方便教师、学生和管理员进行毕业设计的选题和管理,我们开发了这款基于Web的毕业设计选题系统。 该系统主要包括教师管理、院系管理、学生管理等多个模块。在教师管理模块中,管理员可以新增、删除教师信息,并查看教师的详细资料,方便进行教师资源的分配和管理。院系管理模块则允许管理员对各个院系的信息进行管理和维护,确保信息的准确性和完整性。 学生管理模块是系统的核心之一,它提供了学生选题、任务书管理、开题报告管理、开题成绩管理等功能。学生可以在此模块中进行毕业设计的选题,并上传任务书和开题报告,管理员和教师则可以对学生的报告进行审阅和评分。 此外,系统还具备课题分类管理和课题信息管理功能,方便对毕业设计课题进行分类和归档,提高管理效率。在线留言功能则为学生、教师和管理员提供了一个交流互动的平台,可以就毕业设计相关问题进行讨论和解答。 整个系统设计简洁明了,操作便捷,大大提高了毕业设计的选题和管理效率,为高等教育的发展做出了积极贡献。
这个数据集来自世界卫生组织(WHO),包含了2000年至2015年期间193个国家的预期寿命和相关健康因素的数据。它提供了一个全面的视角,用于分析影响全球人口预期寿命的多种因素。数据集涵盖了从婴儿死亡率、GDP、BMI到免疫接种覆盖率等多个维度,为研究者提供了丰富的信息来探索和预测预期寿命。 该数据集的特点在于其跨国家的比较性,使得研究者能够识别出不同国家之间预期寿命的差异,并分析这些差异背后的原因。数据集包含22个特征列和2938行数据,涉及的变量被分为几个大类:免疫相关因素、死亡因素、经济因素和社会因素。这些数据不仅有助于了解全球健康趋势,还可以辅助制定公共卫生政策和社会福利计划。 数据集的处理包括对缺失值的处理、数据类型转换以及去重等步骤,以确保数据的准确性和可靠性。研究者可以使用这个数据集来探索如教育、健康习惯、生活方式等因素如何影响人们的寿命,以及不同国家的经济发展水平如何与预期寿命相关联。此外,数据集还可以用于预测模型的构建,通过回归分析等统计方法来预测预期寿命。 总的来说,这个数据集是研究全球健康和预期寿命变化的宝贵资源,它不仅提供了历史数据,还为未来的研究和政策制
基于微信小程序的高校毕业论文管理系统小程序答辩PPT.pptx
基于java的超市 Pos 收银管理系统答辩PPT.pptx
基于java的网上报名系统答辩PPT.pptx
基于java的网上书城答辩PPT.pptx
婚恋网站 SSM毕业设计 附带论文 启动教程:https://www.bilibili.com/video/BV1GK1iYyE2B
基于java的戒烟网站答辩PPT.pptx
基于微信小程序的“健康早知道”微信小程序答辩PPT.pptx
Capital Bikeshare 数据集是一个包含从2020年5月到2024年8月的自行车共享使用情况的数据集。这个数据集记录了华盛顿特区Capital Bikeshare项目中自行车的租赁模式,包括了骑行的持续时间、开始和结束日期时间、起始和结束站点、使用的自行车编号、用户类型(注册会员或临时用户)等信息。这些数据可以帮助分析和预测自行车共享系统的需求模式,以及了解用户行为和偏好。 数据集的特点包括: 时间范围:覆盖了四年多的时间,提供了长期的数据观察。 细节丰富:包含了每次骑行的详细信息,如日期、时间、天气条件、季节等,有助于深入分析。 用户分类:数据中区分了注册用户和临时用户,可以分析不同用户群体的使用习惯。 天气和季节因素:包含了天气情况和季节信息,可以研究这些因素对骑行需求的影响。 通过分析这个数据集,可以得出关于自行车共享使用模式的多种见解,比如一天中不同时间段的使用高峰、不同天气条件下的使用差异、季节性变化对骑行需求的影响等。这些信息对于城市规划者、交通管理者以及自行车共享服务提供商来说都是非常宝贵的,可以帮助他们优化服务、提高效率和满足用户需求。同时,这个数据集也