一种Kubernetes集群拟态防护方法和系统与流程

背景技术：

1、拟态防御的工作原理是：一个功能等价的异构执行体的集合f，0在t1时刻随机从f中选取k个执行体提供带有裁决机制的输入输出服务，在t2时刻作类似动作，在后续的时刻依次类推。在功能等价条件下，动态异构冗余构造的防御界内，在时空维度上具有多维动态重构机制，未知漏洞后门或者病毒木马及攻击链会随着防御场景作不确定性的改变。图1示出拟态防御的核心框架，即动态异构冗余架构5(dynamic heterogeneous redundancy，dhr)。

2、为便于理解本架构的工作原理与机制，在此以熟知的银行信贷系统来作类比，将动态异构冗余的思想与信贷业务做结合，通过建立

3、“拟态银行信贷系统”模型来了解拟态防御技术是如何实现“动态、异构、冗余”的机制。

4、0客户小明想要向银行申请贷款，需要经历贷款申请、受理调查、风险评估、贷款审批、合同签订、贷款发放的环节。

5、图2示出该贷款审批过程。在我们构造的“拟态银行信贷系统”

6、中，小明提交了贷款申请之后，一线人员会将贷款申请同时交给三个客户经理进行尽职调查，三个人的调查结果会同时交给业务管理部进5行风险评估。假如客户经理3业务不熟练，在调查过程中没有发现小明的材料有问题，客户经理1和客户经理2分别发现了问题，业务管理部会将三者的调查结果做比对进行风险评估。进一步地，根据风险评估的结果认定小明不符合贷款条件，信贷委员会不予审批。

7、与此同时，银行主管也得到了这个裁定结果，认为客户经理30有业务能力漏洞。接下来银行主管会责令他下岗重新培训，其位置由作为备份的客户经理m替代。

8、最终，一线人员会告知小明，其材料没有经过审批，无法贷款。

9、在图2所示模型中，一线人员对应dhr架构中的输入/输出代理，主要与外部做交互；三个不同的客户经理对应的是dhr架构中的异构执行体，是业务系统的核心处理模块；业务管理部和信贷委员会对应dhr架构中的多模裁决模块，用作处理结果的裁决；银行主管对应dhr架构中的负反馈控制器，用来对异构执行体，即客户经理进行上下线“清洗”，即业务培训调度。

10、其中，设置三个不同的客户经理同时处理一个业务，这体现了拟态防御中的异构与冗余思想。异构化要求功能等价，例如处理同一业务，但执行条件不同，例如人员自身的背景不同，但是由于人自身可能存在业务不精、工作时粗心马虎的情况，同一个业务被三个人同时处理可能有不同的结果，系统基于此来感知威胁，即风险。例如，本案例中小明材料造假，但是客户经理3没有审查出来，其实类似于网络安全中的漏洞利用攻击。客户经理3的业务不精即系统漏洞，没有审查出材料问题即漏洞被利用成功。

11、另外，银行主管在接收到裁决，即风险评估结果之后，会动态地调整客户经理3的岗位，这体现了拟态防御具备动态收敛的特性，确保系统安全性不随着时间的推移而降低。

12、因此，拟态防御的核心其实是一种闭环的安全框架，通过重构目标系统，实现从系统结构上确保业务处理安全的机制。

13、下面将描述kubernetes service服务与发布。首先描述kubernetes service与pod。

14、kubernetes通过服务service的形式向外部提供服务，当客户端client连接到kubernetes的service时，该连接被转发到支持该服务的容器集pod上。由于pod是有生命周期的，可以被创建，也可以被销毁，且pod在创建时，它的ip地址也是不稳定的。service的作用就在于通过标签来映射到对应的pod上，这样客户端就可以通过service提供的统一的入口地址，来访问后端具有相同标签的pod，service通过选择器selector参数来筛选拥有对应标签的pod。

15、图3示出service通过标签选择器将流量转发到对应的pod上的示意图。如图3所示，若干个pod上都被标识了不同的标签。此处用正方形和三角形代替。例如，带有正方形标签的pod数量为5个，带有三角形标签的pod数量为1个。当然，这里的数量是示例性的，带有正方形标签和三角形标签的pod可以为任意数量。

16、如图3所示，service标签选择器所选择的标签为正方形，所以client访问流量最终转发到5个带有正方形标签的pod上。

17、我们可以将pod看成能够提供服务的独立计算单元，它具有如下的特点：

18、1)每个pod都拥有自己的ip地址；

19、2)在pod中的所有容器共享相同的ip地址，彼此之间可以自由通信；

20、3)一个pod可以通过ip地址与集群内部的其他所有的pod进行通信，而不需要nat转换。

21、接下来描述kubernetes deployment，即部署。

22、容器的状态是不稳定的，并且容器的生命周期通常比较短暂，所以kubernetes在编排容器的过程中常常不直接使用pod，而是使用其他功能更加强大的组件。我们以最为常见的两类功能组件replication controller，即rc和deployment为例，来介绍他们的使用方法。rc和deployment主要是为了解决以下问题而存在的：

23、1)rc定义了一个期望的场景，及某种pod的副本数量replicas在任意时刻都符合某个预期值；

24、2)deployment是rc的升级，deployment除了能够实现rc功能以外，还包括对pod进行更新、回滚等操作。

25、图4示出service、pod、replicaset、deployment之间的关系图。如图4所示，标签选择器selector所选择的标签为正方形，replicaset通过标签选择器selector，控制带有该标签的pod的副本数量为5。当然，这里的数量是示例性的，带有正方形标签的pod可以为任意数量。deployment对pod进行更新、回滚等操作。

26、通过上面的介绍，我们就可以通过deployment来实现多种方式的发布，在此，我们介绍一种常用的滚动部署。应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚与旧组件不兼容的任何新组件。

27、图5示出deployment滚动更新发布的示意图。如图5所示，提供服务的pod副本数为3，通过滚动部署的更新，服务逐步由v1.0版本升级到v2.0版本。具体地说，在阶段1，v1.0的pod数量为3个；在阶段2，v1.0的pod数量为2个，v2.0的pod数量为1个；在阶段3，v1.0的pod数量为1个，v2.0的pod数量为2个；在阶段4，v2.0的pod数量为3个。在更新过程中，服务保持持续不中断。当然，这里的数量是示例性的。

28、除了滚动发布以外，常用于deployment的发布方式还包括：蓝绿部署和金丝雀部署。蓝绿部署指的是，应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。在这个方法中，两个相同的生产环境并行工作。

29、金丝雀部署指的是，首先在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。

30、接下来描述容器行为建模与异常行为检测。

31、将通过图6来简要介绍容器行为建模与异常行为检测的工作原理。

32、在测试环境下，用户可以保证容器没有被攻击，即容器内部的应用程序行为是正常的。在测试环境下收集容器行为信息，并基于该信息创建容器行为模型。

33、在生产环境下，容器中的程序行为是未知的，有可能受到攻击，此时记录生产环境下的容器行为，并将该行为与容器的行为模型进行对比，判断其行为是否是异常行为。如果该异常行为属于误判，则需要修改完善行为模型。如果异常行为不是误判，我们就可以认为容器遭受到了攻击，由此产生告警，并通知运维人员进行处理。

技术实现思路

1、借助于容器轻量化、易于移植、弹性伸缩等特点，容器集群编排工具kubernetes能够更加系统的编排和发布容器，同时支持一键化的滚动部署以及回滚操作。从提供容器编排服务的角度来看，kubernetes是一个非常好工具。

2、但是缺点是，kubernete在提供容器编排服务的同时，并未考虑容器的安全服务，对于容器运行过程中存在的安全风险，例如特权容器、容器逃逸、反弹shell操作、暴力破解等安全风险无能为力。

3、就现有的容器异常行为检测技术而言，一方面是容器行为模型学习不够准确，需要大量的学习数据才能够建立容器模型，且模型不一定是十分准确的，在异常行为检测时可能会出现误判的情况。另一方面，当产生异常行为结果的时候，需要有丰富运维经验的工程师来人为处理告警，无法进行有效的自动化处理。

4、针对上述问题，本发明提出一种主动发布式的kubernetes集群拟态防护方法，这是一种利用系统自身架构进行防御的安全解决方案，不需要额外的资源消耗就可以实现的内生安全机制。

5、一种kubernetes集群拟态防护方法，所述方法包括：

6、构建基于拟态防御技术的kubernetes集群防护系统，所述系统包括：动态异构冗余执行体单元、动态异构执行体选择器单元和动态控制器单元，其中，所述动态异构冗余执行体单元支持服务service的所有容器集pod的集合，所述集合中所有容器集pod的标签一致且是异构和冗余的，所述动态异构执行体选择器单元用于生成异构冗余执行体，所述动态控制器单元用于实现所述异构冗余执行体的更新与发布；

7、设置更新与发布参数，通过所述更新与发布参数以及所述基于拟态防御技术的kubernetes集群防护系统实现应用发布。

8、在所述方法中，所述更新与发布参数可以包括异构体个数、更新周期、同构体副本数和更新方式。

9、在所述方法中，所述异构冗余执行体内部的容器集pod可以是按照规律动态变化的，所述动态控制器单元通过包括更新周期和动态发布算法在内的参数来设定所述规律。

10、在所述方法中，应用发布的方式可以是滚动部署、蓝绿部署或金丝雀部署。

11、一种kubernetes集群拟态防护系统，所述系统包括：

12、动态异构冗余执行体单元，其支持服务service的所有容器集pod的集合，所述集合中所有容器集pod的标签一致且是异构和冗余的；

13、动态异构执行体选择器单元，其用于生成异构冗余执行体；以及

14、动态控制器单元，其用于实现所述异构冗余执行体的更新与发布；

15、所述系统设置更新与发布参数，通过所述更新与发布参数以及基于拟态防御技术的kubernetes集群防护系统实现应用发布。

16、在所述系统中，所述更新与发布参数可以包括异构体个数、更新周期、同构体副本数和更新方式。

17、在所述系统中，所述异构冗余执行体内部的容器集pod可以是按照规律动态变化的，所述动态控制器单元通过包括更新周期和动态发布算法在内的参数来设定所述规律。

18、在所述系统中，应用发布的方式可以是滚动部署、蓝绿部署或金丝雀部署。

19、利用本发明的方法，动态异构冗余执行体可以在时间和空间两个维度上实现结构上的相异性和冗余性的改变，包括对未知漏洞、后门等的改变，最大程度降低攻击者经验的可复现性和传播价值。这样，将攻击难度提升了三个层次，即从基于静态空间的单一确定目标攻击难度，增强为静态异构空间的多目标协同一致攻击难度，再增强为“动态异构空间、多元目标协同一致攻击”难度，难度等级呈非线性提升，即使攻击成功，也只是一次的，攻击成功的经验无法继承和复制。

20、此外，本发明相比于现有技术还具有如下优点。

21、1)现有service-pod架构采用同构的容器集pod集合来实现服务service功能。而本发明的容器集pod集合为异构执行体，且异构体的数量是可以选择设定的。

22、2)异构体容器集pod集合是主动更新的，动态更新周期t可以自由设定，同构的容器集pod副本数也是可以自由设定的。

23、3)本发明安全防御能力是基于kubernetes自身架构的，不需要额外引入安全能力，是一种内生的安全。

24、4)防御过程可以做到完全的自动化，设定好相关参数后，系统就可以实现自动的防御，不需要人为的参与。