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

随着容器编排技术的成熟，KUbemeteS也逐渐成为云计算的标准，但其使用的场景也各不相同。在KUberneteS集群环境下实现多租户场景下，仍然面临着诸如：权限管理，资源隔离，平台内部网络安全，资源调度等问题。本文主要介绍在公司内部多租户场景下，Kubernetes集群的管理。RBAC权限管理企业内部容器平台：业务可控，组织架构复杂，更加注重权限的细粒度管理。Kubemetes提供namespace作为基础的资源隔离单位和基于RBAC的权限管理方式，可以说Kubernetes多租户的实现离不开这两个核心内容。RBAC作为一种基于角色的并且灵活的访问控制机制且相较于其他的权限管理插件更加广泛，在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可理解对资源对象拥有的权限，就是给定对资源可以对做什么。例如：公司信息部经理，可以管理公司的信息部。创建绑定角色的用户。例如：李四绑定角色。例如：李四能力强，让他担任信息部部门经理。用下面两个集群来说明Role,RoleBinding和ClusterRole,ClusterRoleBinding。NamespacelNamespace4roleBinding*I<olelK一一Iadminro2JlXolelroleBindingadminrole2Namcspacc2roleBindingNamespc3roleBinding*yadminrole2roleladminrole2espacel,roleBindingr<oleNamespace2ClUSterR,IeBindinq4roleBindingfoleyroleBinding，K8s集群1NameSPaCe4roleBindingrole1.K8s集群2adminroleNamcspacc5.JroleBindingrolel集群1：为每个名称空间(NameSPaCe)中，定义都定义了一个名称空间的管理员的角色，然后使用R。IeBinding将AdminRole关联到用户上，来让指定用户成为此名称空间中的管理员。这样做很显然，非常繁琐。集群2：在Kubernetes集群级别创建一个AdminROIe,然后在使用RoleBinding来引用它，并将它和自己名称空间中的用户关联，这样该用户就成功的拥有了对当前名称空间的管理员权限。总的来说：RoleBinding即可以绑定名称空间内部的Role,又可以绑定ClUSterROle,但RoleBinding绑定后，具体化的Role是具体化成本名称空间的RoleoClusterRoleBinding仅可绑定ClusterRole,它具体化的Role,就可访问整个集群中所有的资源。由于RBAC的灵活的权限管理能力，更加适用于复杂的多租户厂家下用户的权限管理中，针对不同的需求制定不同的权限管理策略。如：集群管理员权限具有集群的管理权限为租户创建和分配命名空间各类策略(RAMRBACNetWOrkPoliCy/quota)的CRUD租户管理员权限拥有管理其在Kubernetes的namespace以及namespace中运行程序的管理权限普通租户权限拥有管理其在Kubernetes的namespace中运行的所有资源的只读权限Pod资源调度APIServer接受客户端提交Pod对象创建的请求后，会由调度器程(kube-scheduler),在当前集群中选择一最佳可用的节点接收并运行，并不是指定的节点。如需要将POd资源按照需求调度，则就需要指定相关的调度策略。KUbemeteS集群的调度器：Scheduler(默认调度器)。其核心目标是基于资源的可用性将各Pod资源公平地分布于集群节点之上。完成调度的操作步骤：节点预选节点优先级排序节点优选与6'J5三pod节点预选策略预选策略就是节点过滤器，执行预选操作时，调度器将对每个节点基于配置适用的预选策略以特定的次序逐一筛查，并根据一票否决制进行节点淘汰，如若预选后不存在任何一个满足条件的节点，则Pod处于Pending状态，直至至少一个节点可用为止。预选策略根据其是否可以接受配置参数，又将预选策略为可配置策略和静态策略，可以配置策略可以在预选过程中结合用户自定义调度逻辑。如何让Pod在部署时调度至指定的Kubernetes集群中具体Node节点或者带着某一类标签的节点，可以通过节点亲和调度来实现。节点亲和调度硬亲和调度，硬亲和度的实现时强制性的，Pod调度时必须要满足的条件，不存满足条件节点时，Pod则处于pending状态。软亲和调度，软亲和调度是一种柔性调度，倾向于将Pod调度到某类特定节点上运行，调度器尽量满足调度到满足条件的节点，在无法满足需求时，退而求次选择不满足条件的节点上运行。权重Weight定义优先级，1-100值越大优先级越局。requiredDuringSchedulinglgnoredDuringExecution和PreferredDuringschedulinglgnoredDuringExecution名字中的后半段IgnOredDUringEXeCUtiOn隐藏含义所指，在Pod资源基于节点亲和性规则调度至某节点之后，节点标签发生了改变而不在符合此类节点亲和性规则时，调度器不会将Pod对象从此节点移除，因为它仅对新建的Pod对象生效。在选择节点调度的策略时一般建议选择节点软亲和调度，不会因为目标节点资源不存在导致，适用非特殊的Pod,不会因Pod无法启动，从而导致无法对外提供服务。而在运行特殊的Pod需要运行在特定的计算资源的情况时，此时选择节点硬亲和策略进行调度将Pod调度至特定的节点运行。Pod资源亲和调度在出于高效通信的需求,有时需要将一些Pod调度到相近甚至是同一区域位置（比如同一节点、机房）等等，比如业务的前端Pod和后端Pod,此时这些POd对象之间的关系可以叫做亲和性。同时出于安全性的考虑，也会把一些POd之间进行隔离，此时这些POd对象之间的关系叫做反亲和性（anti-affinity）o调度器把第一个Pod放到任意位置，然后和该Pod有亲和或反亲和关系的Pod根据该动态完成位置编排，这就是Pod亲和性和反亲和性调度的作用。Pod的亲和性定义也存在硬亲和性和软亲和性的区别，其约束的意义和节点亲和性类似。Pod的亲和性调度要求各相关的POd对象运行在同一位置，而反亲和性则要求它们不能运行在同一位置。这里的位置实际上取决于节点的位置拓扑，拓扑的方式不同，Pod是否在同一位置的判定结果也会有所不同。如果基于各个节点的kubernetes.io/hostname标签作为评判标准，那么会根据节点的hostname去判定是否在同一位置区域。污点和容忍度污点（taints）是定义在节点上的一组键值型属性数据，其作用与节点亲和调度恰恰相反，用来让节点拒将特定的Pod调度到该节点上，除非该Pod对象具有容纳节点污点的容忍度。而容忍度（tolerations）是定义在Pod对象上的键值型数据，用来配置让Pod对象可以容忍节点的污点。Kubernetes使用PodToleratesNodeTaints预选策略和TaintTolerationPriority优选函数来完成这种调度方式。污点容忍度：NoScheduIe:不能容忍此污点的新Pod对象不能调度到该节点上，属于强制约束，节点现存的Pod对象不受影响。PreferNoSchedule：NOSChedUIe属于柔性约束，即不能容忍此污点的Pod对象尽量不要调度到该节点，不过无其他节点可以调度时也可以允许接受调度。NoExecute：不能容忍该污点的新POd对象不能调度该节点上，强制约束，节点现存的Pod对象因为节点污点变动或Pod容忍度的变动导致无法匹配规则，Pod对象就会被从该节点上去除。优选函数（节点优选）预选策略筛选出一个节点列表就会进入优选阶段，在这个过程调度器会向每个通过预选的节点传递一系列的优选函数来计算其优先级分值，优先级分值介于O-Io之间，其中0表示不适用，10表示最适合托管该POd对象。另外，调度器还支持给每个优选函数指定一个简单的值，表示权重，进行节点优先级分值计算时，它首先将每个优选函数的计算得分乘以权重，然后再将所有优选函数的得分相加，从而得出节点的最终优先级分值。权重可以让管理员定义优选函数倾向性的能力，其计算优先级的得分公式如下：finalScoreNode=(weight1*priorityFunc1)+(weight2*priorityFunc2)+实际上我们大多数的时候做的Pod资源调度都是在节点预选策略中的可配置预选策略来实现完成。Pod服务质量Kubernetes允许节点资源对limits的过载使用，意味着节点可能无法同时满足其上面所有Pod对象以资源满载的方式运行。在节点内存资源紧张时，是通过Pod的优先来决定Pod对象终止的顺序。根据Pod对象的limits和request属性，Kubernetes将Pod对象归类Guaranteed>Burstable和BestEffort三个服务质量。对于QoS类为Guaranteed的Pod：Pod中的每个容器必须指定内存请求和内存限制，并且两者要相等。Pod中的每个容器必须指定CPU请求和CPU限制，并且两者要相等。这类Pod资源具有最高优先级。如果满足下面条件,将会指定Pod的QoS类为Burstable：当Pod设置的CPU或者内存限制资源与请求资源不相等时，此类Pod具有中等优先级。对于QoS类为BestEffort的Pod：Pod中的容器必须没有设置内存和CPU限制或请求。此类Pod优先级别为最低级别。requests和IimitS没看设置requests小于IimitSrequests等于IirnitS内存资源紧缺时，BeStEffort类别的POd将首当其冲地被终止，因为系统不为其提供任何级别的资源保证，换来的好处是在用时做到尽可能的占用资源。当BestEffort类别的Pod不存在时，Burstable类别的Pod将会被终止。Guaranteed类别的Pod拥有最高优先级，它们不会被杀死，除非其内存资源需求超限，或者OOM时没有其他更低优先级的Pod资源存在。每个运行状态容器都有其OoM得分，得分越高越会被优先杀死。OOM得分主要根据两个维度来计算：由QoS类别继承而来的默认分值和容器可用内存资源比例。同等级优先级的Pod资源在OOM时，与自身的requests属性相比，其内存占用比例最大的POd对象将首先被杀死。OoM是内存耗尽时的处理机制，与可压缩资源CPU无关，CPU资源无法获得保证时，Pod仅仅时暂时获取不到相应资源而已。因此，在针对POd的QoS等级，调整部署时Pod相应的服务等级，可在计算资源紧缺时保证服务的可用性。集群内部网络访问策略&流量控制Kubernetes基于namespace实现环境隔离，但是namespace不能对不同的namespace之间的网络层访问做出有效的网络隔离，因此需要做出有效的网络访问策略来阻断集群内不同的namespace中的服务，未发生或已发生的未经允许的访问。默认情况下Pod对象可以接受来自任何源的流量，也向外部发出期望的所有流量，KUberneteS集群部署CanaI网络插件，网络策略也位于特定的命名空间中，NetworkPolicy对象资源使用标签选择Pod,并定义选定Pod所允许的通信规则。在附加网络策略机制后，Pod对象会因NetPolicy对象的选定而被隔离。NetworkPolicy提供了基于策略的网络控制，用于隔离应用并减少攻击面。使用标签选择器模，并通过策略控制他们之间的流量以及来自外部的流量。设置IngreSS策略，可以允许或拒绝哪些流量访问哪些Podo设置Egress策略，可以拒绝Pod的流量对外进行访问。配置实例：功能：通过使用标签选择器（包括namespaceSelector和podSelector）来控制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隔离好，还是label隔离好？A：用namespace隔离好，namespace是KUbemeteS提出的作为基础隔离资源的的单位，而Iabel标签，是用来做资源标记的，需要进行资源选择时使用。Q：请问RBAC中的ServiceAccount和User区别是什么？它们有什么区别和应用场景呢？谢谢。A：ServiceAccount是集群内部服务账号，用于集群内表明要执行的具体操作，如创建，删除，修改，查看等；User是常规用户，用来管理使用。Q：RABC可以实现权限管理某种角色只能管理某些POd吗？比如这个产品线只管自己产品线的Pod?是在同一个ns的。A：RABC权限管理支持ROIe和CIUSterRoIe两类角色，其中Role作用于名称空间级别（namespace）,ClusterRole作用于整个集群。RABC可以用户授权对名称空间内的Pod资源进行管理。Q：你们开发对线上Kubernetes是什么权限，怎么管理？A：开发对线上Kubernetes只有只读权限，通过Rbac进行权限控制。Q：关于网络选择，Ingress策略和EgreSS适用场景该怎么选择？A：IngreSS适用为流量入站时的网络控制策略，而Egress适用于流量出站时的网络控制策略。附解决K8s多租户集群安全隔离难题解决多租户集群的安全隔离问题对于企业上云而言至关重要。本文讨论了Kubernetes多租户集群的概念和常见的应用模式、企业内共享集群的业务场景以及Kubernetes现有的安全管理功能。什么是多租户集群首先，我们讨论一下“租户”是什么。租户的概念不仅是集群用户，还包括构成计算、网络、存储和其他资源的工作负载集。在多租户集群中，对单个集群中不同租户进行隔离，这样恶意租户就无法攻击其他租户，共享集群资源也能合理地分配给租户。根据隔离的安全级别，可以将集群分为软隔离(SoftMulti-tenancy)和硬隔离(HardMUlti-tenancy)。软隔离适用于企业内的多租户集群，因为默认情况下不会有恶意租户。在这种情况下，软隔离主要是保护内部团队之间的业务并防护可能的安全攻击。硬隔离适用于那些提供对外服务的服务提供商。由于业务模式，不能保证不同租户中业务用户的安全背景，所以集群中的租户和Kubernetes系统可能会相互攻击，这时需要严格的隔离以确保安全性。下面会对不同的多租户方案进行更详细的描述。SoftMulti-tenancy Nonadversarialtenants Differentdepartment/teamsinthesamecompany Nottryingtohjrmothertenants FocusonpreventingaccidentsHardMulti-tenancy Adversarialtenants Differentkindsofuserswhohasnorelationtoeachother Tryingtoexploitthesystem Focusonsecuringandisolatingeachtenant多租户使用场景下面介绍两种不同隔离要求的企业多租户方案：企业内共享集群的多租户这种场景下，所有集群用户都来自企业，这也是许多Kubernetes集群客户的使用场景。由于服务用户的身份是可控的，因此这种业务模式的安全风险也相对可控，毕竟老板可以直接开掉有问题的员工。根据企业内部人员的结构，企业可以通过命名空间，按照逻辑对不同部门或团队的资源进行隔离。另外，定义具有以下角色的业务人员：集群管理员具有集群管理功能，例如伸缩容、添加节点等为租户管理员创建并分配命名空间管理各种策略，例如RAM、RBACNetworkPolicy以及quota租户管理员至少拥有集群RAM只读权限管理租户中相关人员的RBAC配置租户用户在租户命名空间允许范围内使用Kubernetes资源除了用户角色的访问控制之外，我们还要确保命名空间之间的网络隔离，不同命名空间之间只允许白名单内的跨租户应用程序请求。CMarSaaS和KaaS服务模型中的多租户在SaaS多租户场景中，Kubernetes集群中的租户是SaaS平台和SaaS控制平面上的服务应用程序实例。在这种场景下，平台的服务应用程序实例分为不同的命名空间。服务的最终用户无法与Kubernetes控制平面组件进行交互。这些最终用户可以通过自定义的SaaS控制平面访问和使用SaaS控制台，使用服务或部署业务，如下左图所示。例如，假设博客平台已部署并在多租户集群上运行。在这种情况下，租户是每个客户的博客实例和平台的控制平面。平台控制平面和每个托管博客都在不同的命名空间中运行。KaaS多租户方案通常与云服务提供商有关。在这种场景下，业务平台的服务通过Kubernetes控制平面直接暴露给不同租户的用户。最终用户可以使用服务提供商提供的KubernetesAPI或其他扩展AP1.为了满足隔离要求，不同的租户同样需要使用命名空间按照逻辑对访问进行隔离，同时确保不同租户的网络和资源配额的隔离。与企业内的共享集群相反，这里的最终用户都来自非受信区域，所以可能会有在服务平台上运行恶意代码的恶意租户。对此，SaaS和KaaS服务模型中的多租户集群需要更强的安全隔离。在这种场景下，Kubernetes现有的原生功能还无法满足安全要求，因此需要在运行时进行内核级别的隔离来增强此业务场景中的租户安全性。实施多租户架构在规划和实施多租户集群时.，我们首先要通过资源隔离模型来使用Kubernetes的资源隔离层，该模型会将集群本身、命名空间、节点、Pod和容器分别分层。当不同租户的应用程序负载共享相同的资源模型时，就可能会产生安全风险，因此，在实施多租户时，要控制每个租户可访问的资源域。在资源调度层面，还要确保处理敏感信息的容器只能运行在独立的资源节点上。当不同租户的负载共享同一资源域时，我们可以使用运行时的资源调度控制策略来降低跨租户攻击的风险。尽管Kubernetes现有安全性和调度功能不足以实现租户之间的完全安全隔离，但是可以通过命名空间隔离租户使用的资源域，并使用RBAC>PodSecurityPolicy>NetworkPolicy等策略模型来控制租户的资源访问范围以及资源调度功能。这种方法具有可靠的安全隔离能力。以下部分重点介绍基于Kubernetes原生安全功能的多租户实践。访问控制NetworkPolicyNetworkPolicy控制不同租户业务Pod之间的网络流量，并通过白名单进行跨租户业务的访问控制。PodSecurityPolicyPodsecurityPolicies(PSP)是Kubernetes中原生集群维度的资源模型，可以在创建Pod请求的准入阶段验证该行为是否满足相应PSP的要求，例如检查Pod是否使用主机的网络、文件系统、指定端口或PID命名空间。另外，它能限制租户内的用户启用特权容器，还会根据绑定的策略将相应的SecurityContext添加到Pod,包括容器运行时的UlD、GID以及添加或删除的内核功能等设置。OPAOpenPolicyAgent(OPA)是一种功能强大的策略引擎，支持解耦的策略决策服务。目前，社区已经有了成熟的Kubernetes集成解决方案。当现有RBAC在命名空间级别上的隔离不能满足企业应用程序复杂的安全需求时，OPA可以在对象模型级别提供细粒度的访问策略控制。另外，OPA还支持7层NetworkPolicy定义以及基于标签和注释的跨命名空间访问控制，可以有效增强Kubernetes原生的NetworkPolicyo资源调度资源配额(ResourceQuota)和限制范围(1.imitRange)在多租户场景中，不同的团队或部门会共享集群资源，这可能导致资源竞争问题，需要通过限制每个租户的资源使用配额来解决。ResourceQuota用于限制总资源请求，以及租户对应命名空间下所有Pod的资源。1.imitRange用于设置租户的命名空间中Pod的默认资源请求和限制值。另外，我们还可以限制租户的存储资源配额和对象数量配额。Pod优先级(Priority)和抢占(Preemption)从Kubernetes1.14版本开始，Pod优先级和抢占功能已成为重要组成部分。容器优先级表示调度队列中处于pending状态容器的优先级。由于节点资源不足或其他原因而无法调度高优先级的Pod时，调度程序会尝试驱逐低优先级的Pod,来保证可以先调度、部署高优先级的Podo在多租户方案中，优先级和抢占的设置可以用来保护租户中重要业务应用程序的可用性。此外，Pod优先级与ResourceQuota搭配使用可将租户配额限制设为指定的优先级。专用节点(DedicatedNodes)注意：恶意租户可能绕过节点taint和tolerance机制强制实施策略。以下内容仅适用于企业内受信任租户的集群，或租户无法直接访问Kubernetes控制平面的集群。通过为集群中的某些节点添加taint,可以将这些节点提供给指定租户专用。在多租户场景中，当集群中包含GPU节点时，可以使用taint为需要GPU资源的业务应用程序服务团队保留这些节点。集群管理员可以使用诸如effect：“NoSchedule”之类的标签向节点添加污点，这样就只能调度具有相应tolerance设置的Pod到该节点。但是，恶意租户会将相同的tolerance设置添加到Pod上来访问此节点，因此，仅使用节点taint和tolerance机制无法确保目标节点在非信任多租户集群中的安全性。保护敏感信息一REST的secret加密在多租户集群中，不同的租户用户共享一套相同的etcd存储。当最终用户访问Kubernetes控制平面时，要保护好SeCret数据，以避免访问控制策略配置不正确时导致敏感信息泄漏。总结总部署多租户体系架构时，首先要确定相应的应用场景，包括租户内用户和应用程序的可信度和对应的安全隔离程度。另外，为满足基本的安全隔离要求，最好执行以下几点：启用Kubernetes集群默认安全配置启用RBAC,禁止匿名用户访问启用secretsencryption,保护敏感信息根据CISKubernetes基准执行安全配置启用准入控制器，例如NodeRestriction、AlwaysPullImages和PodsecurityPoIicy使用PSP控制Pod部署的特权模式，并在Pod运行时控制Pod的安全上下文配置NetworkPolicyDocker运行时启用SeccompAppArmor和SE1.inux对监控、日志记录等服务进行多租户隔离当使用诸如SaaS和KaaS之类的服务模型时，或者无法保证租户下用户的可信度时，可以使用以下更强力的隔离措施：使用OPADENG动态策略引擎在网络或对象级别进行细粒度的访问控制部署安全容器，在容器运行时进行内核级隔离对监视、日志记录、存储和其他服务实施全面的多租户隔离解决方案。