Kubernetes集群在企业内部多租户共享场景下的管理.docx

《Kubernetes集群在企业内部多租户共享场景下的管理.docx》由会员分享，可在线阅读，更多相关《Kubernetes集群在企业内部多租户共享场景下的管理.docx（10页珍藏版）》请在课桌文档上搜索。

1、随着容器编排技术的成熟，KUbemeteS也逐渐成为云计算的标准，但其使用的场景也各不相同。在KUberneteS集群环境下实现多租户场景下，仍然面临着诸如：权限管理，资源隔离，平台内部网络安全，资源调度等问题。本文主要介绍在公司内部多租户场景下，Kubernetes集群的管理。RBAC权限管理企业内部容器平台：业务可控，组织架构复杂，更加注重权限的细粒度管理。Kubemetes提供namespace作为基础的资源隔离单位和基于RBAC的权限管理方式，可以说Kubernetes多租户的实现离不开这两个核心内容。RBAC作为一种基于角色的并且灵活的访问控制机制且相较于其他的权限管理插件更加广泛，

2、在Kubernetes集群中默认强制开启。RBAC中的核心概念：基于单个名称空间：Role,RoleBinding整个集群级别：ClusterRole,ClusterRoleBinding尊于角色的访问控制as权限，/jJ读get诵I写Write11定义角色赋予权限角色绑定角色,CIusterRoIe更新UPdate列出IiSt监视WatCh绑定角色I-I用户账户服务账户1. Role2. CIusterRoIe3. RoIeBinding4. CIusterRoIeBinding接下来说下RBAC的授权过程：创建Role（角色）。Role可理解对资源对象拥有的权限，就是给定对资源可以对做什么

3、。例如：公司信息部经理，可以管理公司的信息部。创建绑定角色的用户。例如：李四绑定角色。例如：李四能力强，让他担任信息部部门经理。用下面两个集群来说明Role,RoleBinding和ClusterRole,ClusterRoleBinding。NamespacelNamespace4roleBinding*IolelK一一Iadminro2JlXolelroleBindingadminrole2Namcspacc2roleBindingNamespc3roleBinding*yadminrole2roleladminrole2espacel,roleBindingrBurstable和Best

4、Effort三个服务质量。对于QoS类为Guaranteed的Pod：Pod中的每个容器必须指定内存请求和内存限制，并且两者要相等。Pod中的每个容器必须指定CPU请求和CPU限制，并且两者要相等。这类Pod资源具有最高优先级。如果满足下面条件,将会指定Pod的QoS类为Burstable：当Pod设置的CPU或者内存限制资源与请求资源不相等时，此类Pod具有中等优先级。对于QoS类为BestEffort的Pod：Pod中的容器必须没有设置内存和CPU限制或请求。此类Pod优先级别为最低级别。requests和IimitS没看设置requests小于IimitSrequests等于Iirnit

5、S内存资源紧缺时，BeStEffort类别的POd将首当其冲地被终止，因为系统不为其提供任何级别的资源保证，换来的好处是在用时做到尽可能的占用资源。当BestEffort类别的Pod不存在时，Burstable类别的Pod将会被终止。Guaranteed类别的Pod拥有最高优先级，它们不会被杀死，除非其内存资源需求超限，或者OOM时没有其他更低优先级的Pod资源存在。每个运行状态容器都有其OoM得分，得分越高越会被优先杀死。OOM得分主要根据两个维度来计算：由QoS类别继承而来的默认分值和容器可用内存资源比例。同等级优先级的Pod资源在OOM时，与自身的requests属性相比，其内存占用比例

6、最大的POd对象将首先被杀死。OoM是内存耗尽时的处理机制，与可压缩资源CPU无关，CPU资源无法获得保证时，Pod仅仅时暂时获取不到相应资源而已。因此，在针对POd的QoS等级，调整部署时Pod相应的服务等级，可在计算资源紧缺时保证服务的可用性。集群内部网络访问策略&流量控制Kubernetes基于namespace实现环境隔离，但是namespace不能对不同的namespace之间的网络层访问做出有效的网络隔离，因此需要做出有效的网络访问策略来阻断集群内不同的namespace中的服务，未发生或已发生的未经允许的访问。默认情况下Pod对象可以接受来自任何源的流量，也向外部发出期望的所有流

7、量，KUberneteS集群部署CanaI网络插件，网络策略也位于特定的命名空间中，NetworkPolicy对象资源使用标签选择Pod,并定义选定Pod所允许的通信规则。在附加网络策略机制后，Pod对象会因NetPolicy对象的选定而被隔离。NetworkPolicy提供了基于策略的网络控制，用于隔离应用并减少攻击面。使用标签选择器模，并通过策略控制他们之间的流量以及来自外部的流量。设置IngreSS策略，可以允许或拒绝哪些流量访问哪些Podo设置Egress策略，可以拒绝Pod的流量对外进行访问。配置实例：功能：通过使用标签选择器（包括namespaceSelector和podSelec

8、tor）来控制Pod之间的流量要决定三件事：控制对象：通过SPeC字段，podSelector等条件筛选流方向：Ingress（入Pod流量）+from,Egress（出POd流量）+to流特征：对端（通过name/PodSeIeCtOr）,IP段CipBlock）,协议（protocol）,端口（port）Q&AQ：如何实现各租户之间数据隔离和共享？如何实现各租户的需求个性化定制？A：不同项目程序运行在不同namespace中+NetpoIicy实现数据的隔离，反之则可实现数据共享的需求。Q：我们需要在同一个KubemetesCluster上部署dev和qa两套环境。是用namespace隔

9、离好，还是label隔离好？A：用namespace隔离好，namespace是KUbemeteS提出的作为基础隔离资源的的单位，而Iabel标签，是用来做资源标记的，需要进行资源选择时使用。Q：请问RBAC中的ServiceAccount和User区别是什么？它们有什么区别和应用场景呢？谢谢。A：ServiceAccount是集群内部服务账号，用于集群内表明要执行的具体操作，如创建，删除，修改，查看等；User是常规用户，用来管理使用。Q：RABC可以实现权限管理某种角色只能管理某些POd吗？比如这个产品线只管自己产品线的Pod?是在同一个ns的。A：RABC权限管理支持ROIe和CIUSt

10、erRoIe两类角色，其中Role作用于名称空间级别（namespace）,ClusterRole作用于整个集群。RABC可以用户授权对名称空间内的Pod资源进行管理。Q：你们开发对线上Kubernetes是什么权限，怎么管理？A：开发对线上Kubernetes只有只读权限，通过Rbac进行权限控制。Q：关于网络选择，Ingress策略和EgreSS适用场景该怎么选择？A：IngreSS适用为流量入站时的网络控制策略，而Egress适用于流量出站时的网络控制策略。附解决K8s多租户集群安全隔离难题解决多租户集群的安全隔离问题对于企业上云而言至关重要。本文讨论了Kubernetes多租户集群的概

11、念和常见的应用模式、企业内共享集群的业务场景以及Kubernetes现有的安全管理功能。什么是多租户集群首先，我们讨论一下“租户”是什么。租户的概念不仅是集群用户，还包括构成计算、网络、存储和其他资源的工作负载集。在多租户集群中，对单个集群中不同租户进行隔离，这样恶意租户就无法攻击其他租户，共享集群资源也能合理地分配给租户。根据隔离的安全级别，可以将集群分为软隔离(SoftMulti-tenancy)和硬隔离(HardMUlti-tenancy)。软隔离适用于企业内的多租户集群，因为默认情况下不会有恶意租户。在这种情况下，软隔离主要是保护内部团队之间的业务并防护可能的安全攻击。硬隔离适用于那些

12、提供对外服务的服务提供商。由于业务模式，不能保证不同租户中业务用户的安全背景，所以集群中的租户和Kubernetes系统可能会相互攻击，这时需要严格的隔离以确保安全性。下面会对不同的多租户方案进行更详细的描述。SoftMulti-tenancy Nonadversarialtenants Differentdepartment/teamsinthesamecompany Nottryingtohjrmothertenants FocusonpreventingaccidentsHardMulti-tenancy Adversarialtenants Differentkindsofusersw

13、hohasnorelationtoeachother Tryingtoexploitthesystem Focusonsecuringandisolatingeachtenant多租户使用场景下面介绍两种不同隔离要求的企业多租户方案：企业内共享集群的多租户这种场景下，所有集群用户都来自企业，这也是许多Kubernetes集群客户的使用场景。由于服务用户的身份是可控的，因此这种业务模式的安全风险也相对可控，毕竟老板可以直接开掉有问题的员工。根据企业内部人员的结构，企业可以通过命名空间，按照逻辑对不同部门或团队的资源进行隔离。另外，定义具有以下角色的业务人员：集群管理员具有集群管理功能，例如伸缩容

14、、添加节点等为租户管理员创建并分配命名空间管理各种策略，例如RAM、RBACNetworkPolicy以及quota租户管理员至少拥有集群RAM只读权限管理租户中相关人员的RBAC配置租户用户在租户命名空间允许范围内使用Kubernetes资源除了用户角色的访问控制之外，我们还要确保命名空间之间的网络隔离，不同命名空间之间只允许白名单内的跨租户应用程序请求。CMarSaaS和KaaS服务模型中的多租户在SaaS多租户场景中，Kubernetes集群中的租户是SaaS平台和SaaS控制平面上的服务应用程序实例。在这种场景下，平台的服务应用程序实例分为不同的命名空间。服务的最终用户无法与Kuber

15、netes控制平面组件进行交互。这些最终用户可以通过自定义的SaaS控制平面访问和使用SaaS控制台，使用服务或部署业务，如下左图所示。例如，假设博客平台已部署并在多租户集群上运行。在这种情况下，租户是每个客户的博客实例和平台的控制平面。平台控制平面和每个托管博客都在不同的命名空间中运行。KaaS多租户方案通常与云服务提供商有关。在这种场景下，业务平台的服务通过Kubernetes控制平面直接暴露给不同租户的用户。最终用户可以使用服务提供商提供的KubernetesAPI或其他扩展AP1.为了满足隔离要求，不同的租户同样需要使用命名空间按照逻辑对访问进行隔离，同时确保不同租户的网络和资源配额的

16、隔离。与企业内的共享集群相反，这里的最终用户都来自非受信区域，所以可能会有在服务平台上运行恶意代码的恶意租户。对此，SaaS和KaaS服务模型中的多租户集群需要更强的安全隔离。在这种场景下，Kubernetes现有的原生功能还无法满足安全要求，因此需要在运行时进行内核级别的隔离来增强此业务场景中的租户安全性。实施多租户架构在规划和实施多租户集群时.，我们首先要通过资源隔离模型来使用Kubernetes的资源隔离层，该模型会将集群本身、命名空间、节点、Pod和容器分别分层。当不同租户的应用程序负载共享相同的资源模型时，就可能会产生安全风险，因此，在实施多租户时，要控制每个租户可访问的资源域。在资

17、源调度层面，还要确保处理敏感信息的容器只能运行在独立的资源节点上。当不同租户的负载共享同一资源域时，我们可以使用运行时的资源调度控制策略来降低跨租户攻击的风险。尽管Kubernetes现有安全性和调度功能不足以实现租户之间的完全安全隔离，但是可以通过命名空间隔离租户使用的资源域，并使用RBACPodSecurityPolicyNetworkPolicy等策略模型来控制租户的资源访问范围以及资源调度功能。这种方法具有可靠的安全隔离能力。以下部分重点介绍基于Kubernetes原生安全功能的多租户实践。访问控制NetworkPolicyNetworkPolicy控制不同租户业务Pod之间的网络流量

18、，并通过白名单进行跨租户业务的访问控制。PodSecurityPolicyPodsecurityPolicies(PSP)是Kubernetes中原生集群维度的资源模型，可以在创建Pod请求的准入阶段验证该行为是否满足相应PSP的要求，例如检查Pod是否使用主机的网络、文件系统、指定端口或PID命名空间。另外，它能限制租户内的用户启用特权容器，还会根据绑定的策略将相应的SecurityContext添加到Pod,包括容器运行时的UlD、GID以及添加或删除的内核功能等设置。OPAOpenPolicyAgent(OPA)是一种功能强大的策略引擎，支持解耦的策略决策服务。目前，社区已经有了成熟的K

19、ubernetes集成解决方案。当现有RBAC在命名空间级别上的隔离不能满足企业应用程序复杂的安全需求时，OPA可以在对象模型级别提供细粒度的访问策略控制。另外，OPA还支持7层NetworkPolicy定义以及基于标签和注释的跨命名空间访问控制，可以有效增强Kubernetes原生的NetworkPolicyo资源调度资源配额(ResourceQuota)和限制范围(1.imitRange)在多租户场景中，不同的团队或部门会共享集群资源，这可能导致资源竞争问题，需要通过限制每个租户的资源使用配额来解决。ResourceQuota用于限制总资源请求，以及租户对应命名空间下所有Pod的资源。1.

20、imitRange用于设置租户的命名空间中Pod的默认资源请求和限制值。另外，我们还可以限制租户的存储资源配额和对象数量配额。Pod优先级(Priority)和抢占(Preemption)从Kubernetes1.14版本开始，Pod优先级和抢占功能已成为重要组成部分。容器优先级表示调度队列中处于pending状态容器的优先级。由于节点资源不足或其他原因而无法调度高优先级的Pod时，调度程序会尝试驱逐低优先级的Pod,来保证可以先调度、部署高优先级的Podo在多租户方案中，优先级和抢占的设置可以用来保护租户中重要业务应用程序的可用性。此外，Pod优先级与ResourceQuota搭配使用可将租

21、户配额限制设为指定的优先级。专用节点(DedicatedNodes)注意：恶意租户可能绕过节点taint和tolerance机制强制实施策略。以下内容仅适用于企业内受信任租户的集群，或租户无法直接访问Kubernetes控制平面的集群。通过为集群中的某些节点添加taint,可以将这些节点提供给指定租户专用。在多租户场景中，当集群中包含GPU节点时，可以使用taint为需要GPU资源的业务应用程序服务团队保留这些节点。集群管理员可以使用诸如effect：“NoSchedule”之类的标签向节点添加污点，这样就只能调度具有相应tolerance设置的Pod到该节点。但是，恶意租户会将相同的tole

22、rance设置添加到Pod上来访问此节点，因此，仅使用节点taint和tolerance机制无法确保目标节点在非信任多租户集群中的安全性。保护敏感信息一REST的secret加密在多租户集群中，不同的租户用户共享一套相同的etcd存储。当最终用户访问Kubernetes控制平面时，要保护好SeCret数据，以避免访问控制策略配置不正确时导致敏感信息泄漏。总结总部署多租户体系架构时，首先要确定相应的应用场景，包括租户内用户和应用程序的可信度和对应的安全隔离程度。另外，为满足基本的安全隔离要求，最好执行以下几点：启用Kubernetes集群默认安全配置启用RBAC,禁止匿名用户访问启用secret

23、sencryption,保护敏感信息根据CISKubernetes基准执行安全配置启用准入控制器，例如NodeRestriction、AlwaysPullImages和PodsecurityPoIicy使用PSP控制Pod部署的特权模式，并在Pod运行时控制Pod的安全上下文配置NetworkPolicyDocker运行时启用SeccompAppArmor和SE1.inux对监控、日志记录等服务进行多租户隔离当使用诸如SaaS和KaaS之类的服务模型时，或者无法保证租户下用户的可信度时，可以使用以下更强力的隔离措施：使用OPADENG动态策略引擎在网络或对象级别进行细粒度的访问控制部署安全容器，在容器运行时进行内核级隔离对监视、日志记录、存储和其他服务实施全面的多租户隔离解决方案。