CN112099911B - 一种基于Kubernetes构建动态资源准入控制器的方法 - Google Patents

Abstract

本发明公开了一种基于Kubernetes构建动态资源准入控制器的方法，属于云原生的技术领域。其包括补丁控制器、验证控制器、自动生成控制器和命令行控制器四个组件，包括如下步骤：初始化系统配置至kubernetes集群中，如果配置出错，则退出系统；初始化命令行控制器、启动补丁控制器、验证控制器、自动生成控制器，若任意一个控制器出错则不断重试，直至所有控制器均正常运行，当所有组件正常运行时表示准入系统正常运行。本发明能够确保应用程序在不断变化的控制环境中保持合规，加强系统的安全性，并降低运维人员集群管理的复杂度。

Description

一种基于Kubernetes构建动态资源准入控制器的方法

技术领域

本发明属于云原生的技术领域，尤其涉及一种基于Kubernetes构建动态资源准入控制器的方法。

背景技术

近年来，容器技术和Kubernetes平台持续升温，Kubernetes极大地提高了应用部署的速度和可管理性。全球范围内各行各业都在这一轻量级虚拟化方案上进行着积极而富有成效的探索，由于其灵活性、可扩展性和易用性，Kubernetes已成为容器编排器的事实标准，迅速落地并赋能产业，大大提高了资源利用效率和生产力。随着容器化的重要甚至核心业务越来越多，容器安全的重要性也在不断提高。

作为一项依然处于发展阶段的新技术，容器的安全性在不断地提高，也在不断地受到挑战。目前尚未存在针对kubernetes平台的动态资源准入方案，运维人员无法进行标准化的容器治理与配置管理，这无疑增大了Kubernetes集群管理的复杂程度。更重要的，没有一个合理的安全基准来提高kubernetes集群安全性，当集群被运行未授权的容器进而用于非法目的甚至反向控制集群，一旦造成客户损失将对企业造成了无法估量的影响。

发明内容

本发明的发明目的是提供一种基于Kubernetes构建动态资源准入控制器的方法，能够确保应用程序在不断变化的控制环境中保持合规，加强系统的安全性，并降低运维人员集群管理的复杂度。

为达到上述目的，本发明所采用的技术方案是：

一种基于Kubernetes构建动态资源准入控制器的方法，其包括补丁控制器、验证控制器、自动生成控制器和命令行控制器四个组件，包括如下步骤：

S1、初始化系统配置至kubernetes集群中，如果配置出错，则退出系统；

S2、初始化命令行控制器、启动补丁控制器、验证控制器、自动生成控制器，若任意一个控制器出错则不断重试，直至所有控制器均正常运行，当所有组件正常运行时表示准入系统正常运行；

S3、所述命令行控制器除了初始化时自动与kube-apiserver交互，其余皆由操作人员直接操作，用于验证和应用准入策略，与apiserver进行交互；

S4、所述补丁控制器、验证控制器、自动生成控制器在kube-apiserver处理请求的流程中分别实现三个钩子拦截请求，完成准入控制的逻辑。

进一步的，所述步骤S1中，所述系统配置包括：

补丁控制器、验证控制器的连接信息；

补丁控制器、验证控制器的验证信息；

处理来自补丁控制器、验证控制器的无法识别的错误信息提示。

进一步的，所述步骤S3中，所述命令控制器的操作步骤如下：

S3.1、命令行控制器启动后，验证系统已有的准入策略，如有不完整或出错的策略，打印到日志中并将该策略配置为停用状态,正常的策略配置为激活状态。命令行控制器将一直运行在后台中，等待新的命令；

S3.2、管理员或开发者进入命令行控制器，可以验证或应用准入策略，可将多个准入策略用于多个资源，

S3.3、命令行控制器通过kube-apiserver进行策略的读取、写入和激活等操作，策略最终由kube-apiserver写入etcd存储中；

S3.4、命令行控制器针对策略进行验证时，会判断该策略由哪个控制器进行操作，再调用响应的控制器进行策略验证,验证的内容包括格式是否准确，与现有策略是否冲突；

S3.5：命令行控制器针对策略进行应用时，先按照步骤S3.4进行策略验证,验通过后通过kube-apiserver将其写入集群，验证不通过则不允许提交。

进一步的，所述步骤S3.2中，所述准入策略包括补丁策略、验证策略和自动自动生成策略，每种策略分别对应一个控制器，分别为补丁控制器、验证控制器、自动生成控制器。

进一步的，所述步骤S4中，所述补丁控制器的操作步骤如下：

A1、补丁控制器收到kube-apiserver的请求；

A2、补丁控制器根据资源的类型，筛选出已激活的补丁策略，如果存在已激活的补丁策略，则初始化一个空白的补丁结构，进入下一个步骤，如不包含该种类型已激活的补丁策略，进入步骤A6；

A3、循环该种类型的所有补丁策略，如还有未处理的补丁策略，进入下一个步骤，循环结束后进入步骤A6；

A4、确认kube-apiserver传输的请求是否适用当前补丁策略，如果适用则进入下一个步骤，如不适用，返回步骤A3；

A5、使用补丁策略中的内容注入步骤A2中的补丁结构，返回步骤A3；

A6、构造一个响应，与步骤A2中的补丁一起编组，然后将其发送回kube-apiserver。

进一步的，所述步骤S4中，所述验证控制器的操作步骤如下：

B1、验证控制器收到kube-apiserver的请求；

B2、验证控制器根据资源的类型，筛选出已激活的验证策略，如果存在已激活的验证策略则进入下一个步骤，如不包含该种类型已激活的验证策略，标记验证通过并进入步骤B6；

B3、循环该种类型的所有验证策略，如还有未处理的验证策略，进入下一个步骤，循环结束后，标记验证通过并进入步骤B6；

B4、确认kube-apiserver传输的请求是否适用当前验证策略，如果适用则进入下一个步骤，如不适用，返回步骤B3。

B5、验证kube-apiserver的请求是否通过验证策略，如果不通过，标记验证不通过并进入步骤B6，如果通过，返回步骤B3；

B6、如果请求标记为验证通过，构造一个验证成功的响应，如果标记为失败，则构造一个验证失败的响应。然后将响应发送回kube-apiserver。

进一步的，所述步骤S4中，所述验证控制器的操作步骤如下：

C1、自动生成控制器监听kube-apiserver的事件,当有新的自动生成策略应用，如还未监听触发事件，便增加一个监听，使得自动生成控制器得以自动生成资源；

C2、收到kube-apiserver的事件后，生成控制器根据事件的类型，筛选出已激活的自动生成策略，如果存在已激活的自动生成策略，则初始化一个空白的资源描述yaml，进入下一个步骤，如不包含该种类型已激活的自动生成策略，直接结束；

C3、循环该种类型的所有自动生成策略，如还有未处理的自动生成策略，进入下一个步骤，循环结束后进入步骤C6；

C4、确认当前的事件是否适用自动生成策略，如果适用则进入下一个步骤，如不适用，返回步骤C3；

C5、使用自动生成策略中的内容补充到步骤C2中的资源描述yaml，返回步骤C3；

C6、构造一个请求，将资源描述yaml发至kube-apiserver，请求kube-apiserver生成该yaml文件中的资源。

由于采用上述技术方案，本发明具有以下有益效果：

本发明中的命令行控制器用于查看或修改准入系统配置和策略调试与开发，补丁控制器、验证控制器、自动生成控制器分别用于标准化kubernetes资源、拒绝运行kubernetes资源和自动生成kubernetes资源，本发明能够对kubernetes集群中的所有资源进行准入控制，能够确保应用程序在不断变化的控制环境中保持合规，加强系统的安全性，并降低运维人员集群管理的复杂度，提高大规模集群中的资源安全性。

附图说明

图1是本发明步骤S1的工作流程图；

图2是本发明步骤S3的工作流程图；

图3是本发明步骤S4的工作流程图。

具体实施方式

下面结合附图，对本发明的具体实施方式进行详细描述，但应当理解本发明的保护范围并不受具体实施方式的限制。

除非另有其它明确表示，否则在整个说明书和权利要求书中，术语“包括”或其变换如“包含”或“包括有”等等将被理解为包括所陈述的元件或组成部分，而并未排除其它元件或其它组成部分。

如图1-3所示，本发明公开了一种构建Kubernetes动态资源准入控制器的方法，包括：补丁控制器、验证控制器、自动生成控制器和命令行控制器四个组件。

命令行控制器(command line controller)用于查看或修改准入系统配置，也用于策略调试与开发。

补丁控制器(patch controller)、验证控制器(validate controller)、自动生成控制器(auto-generate controller)分别用于标准化kubernetes资源、拒绝运行kubernetes资源和自动生成kubernetes资源，是准入系统的核心组件。

本发明所属的资源准入控制的方法，可以对kubernetes集群中的所有资源进行准入控制，当前kubernetes的所有资源包括如下资源：

endpoints、ingresses、limitranges、services、nodes、persistentvolumeclaims、persistent volumes、pod templates、replicasets、statefulsets、storage classes、certificate signing requests、cluster rolebindings、clusterroles、component statuses、config maps、service accounts、networkpolicies、resource quotas、custom resource definition、controller revisions、namespaces、pod disruption budgets、pod security policies、podpreset、rolebindings、horizontal pod autoscalers、roles、secrets、deployments、cronjobs、daemonsets、jobs、pods。

本发明所述的kubernetes平台的动态资源准入控制方法包括如下步骤：

S1.初始化系统配置至kubernetes集群中，如果配置出错，则退出系统。系统配置包括：

1.补丁控制器、验证控制器的连接信息。

2.补丁控制器、验证控制器的验证信息。

3.处理来自补丁控制器、验证控制器的无法识别的错误信息提示。

S2.初始化命令行控制器、启动补丁控制器、验证控制器、自动生成控制器,任意一个控制器出错则不断重试，直至正常运行。当所有组件正常运行时表示准入系统正常运行。

S3.以下为命令行控制器(command line controller)的操作步骤，为系统控制平面，命令行控制器除了初始化时会自动与kube-apiserver交互，其余皆由操作人员直接操作，用于验证和应用准入策略，与apiserver进行交互。

S3.1.命令行控制器启动后，按照步骤S3.4验证系统已有的准入策略，如有不完整或出错的策略，打印到日志中并将该策略配置为停用状态，正常的策略配置为激活状态。命令行控制器将一直运行在后台中，等待新的命令。

S3.2.管理员或开发者进入命令行控制器，可以验证或应用准入策略，可将多个准入策略用于多个资源。

准入策略包含三种类型：补丁策略patch policy、验证策略validate policy和自动自动生成策略auto-generate policy，每种策略分别对应一个控制器：补丁控制器(patch controller)、验证控制器(validate controller)、自动生成控制器(auto-generate controller)。

策略使用yaml格式描述，支持通配符。

策略的内容包括：

1.策略名字name

2.策略的类型：补丁、验证或自动生成类型。

3.策略适用的资源，可以包含多种资源resource_kinds

4.策略的详细描述信息，例如镜像名、资源限制、添加标签等。

5.策略命中时的显示信息

S3.3.命令行控制器通过kube-apiserver进行策略的读取、写入和激活等操作。策略最终由kube-apiserver写入etcd存储中。

S3.4.命令行控制器针对策略进行验证时，会判断该策略由哪个控制器进行操作，再调用响应的控制器进行策略验证。验证的内容包括格式是否准确，与现有策略是否冲突等。

S3.5.命令行控制器针对策略进行应用时，先按照步骤S3.4进行策略验证。验通过后通过kube-apiserver将其写入集群，验证不通过则不允许提交。

S4.其为系统数据面的操作步骤，分别涉及补丁控制器、验证控制器、自动生成控制器的操作步骤，三个控制器在kube-apiserver处理请求的流程中分别实现三个钩子拦截请求，完成准入控制的逻辑。

准入系统初始化时，准入系统配置准入向kubernetes集群中注入了补丁控制器、验证控制器、自动生成控制器的地址和验证信息。

Kube-apiserver是kubernetes集群请求的统一入口。当kube-apiserver收到了资源创建或更新请求时，Kube-apiserver通过kuernetes的预置组件MutatingAdmissionWebhook触发补丁控制器(patch controller)。

补丁控制器返回响应至kube-apiserver后，kuernetes的预置组件ValidatingAdmissionWebhook会触发验证控制器(validate controller)。

验证控制器返回响应至kube-apiserver，开始执行请求。执行请求会在kubernetes集群的事件中记录下来。自动生成控制器(auto-generate controller)通过向kube-apiserver订阅特定的事件，由kube-apiserver触发自身的逻辑。

以下为补丁控制器(patch controller)的操作步骤:

A1.补丁控制器收到kube-apiserver的请求。

A2.补丁控制器根据资源的类型，筛选出已激活的补丁策略patch policy，如果存在已激活的补丁策略，则初始化一个空白的补丁结构，进入下一个步骤。如不包含该种类型已激活的补丁策略，进入步骤A6。

A3.循环该种类型的所有补丁策略，如还有未处理的补丁策略，进入下一个步骤。循环结束后进入步骤A6。

A4.确认kube-apiserver传输的请求是否适用当前补丁策略，例如补丁策略已存在、排除了当前时间段打补丁、补丁策略不操作当前用户请求、补丁策略未启用等等情况。如果适用则进入下一个步骤。如不适用，返回步骤A3。

A5.使用补丁策略中的内容注入步骤A2中的补丁结构，返回步骤A3。

A6.构造一个响应，与步骤A2中的补丁一起编组，然后将其发送回kube-apiserver。

以下为验证控制器(validate controller)的操作步骤:

B1.验证控制器收到kube-apiserver的请求。

B2.验证控制器根据资源的类型，筛选出已激活的验证策略validate policy，如果存在已激活的验证策略则进入下一个步骤。如不包含该种类型已激活的验证策略，标记验证通过并进入步骤B6。

B3.循环该种类型的所有验证策略，如还有未处理的验证策略，进入下一个步骤。循环结束后，标记验证通过并进入步骤B6。

B4.确认kube-apiserver传输的请求是否适用当前验证策略，例如排除了当前时间段验证、验证策略不验证当前用户请求、验证策略未启用等等情况。如果适用则进入下一个步骤。如不适用，返回步骤B3。

B5.验证kube-apiserver的请求是否通过验证策略。如果不通过，标记验证不通过并进入步骤B6。如果通过，返回步骤B3。

B6.如果请求标记为验证通过，构造一个验证成功的响应，如果标记为失败，则构造一个验证失败的响应。然后将响应发送回kube-apiserver。

以下为自动生成控制器(auto-generate controller)的操作步骤:

C1：自动生成控制器监听kube-apiserver的事件。当有新的自动生成策略auto-generate policy应用，如还未监听触发事件，便增加一个监听，使得自动生成控制器得以自动生成资源。

C2：收到kube-apiserver的事件后，生成控制器根据事件的类型，筛选出已激活的自动生成策略auto-generate policy，如果存在已激活的自动生成策略，则初始化一个空白的资源描述yaml，进入下一个步骤。如不包含该种类型已激活的自动生成策略，直接结束。

C3：循环该种类型的所有自动生成策略，如还有未处理的自动生成策略，进入下一个步骤。循环结束后进入步骤C6。

C4：确认当前的事件是否适用自动生成策略，例如排除了当前时间段自动生成、自动生成策略不响应当前用户请求、自动生成策略的资源已存在等等情况。如果适用则进入下一个步骤。如不适用，返回步骤C3。

C5：使用自动生成策略中的内容补充到步骤6.2中的资源描述yaml，返回步骤6.3。

C6：构造一个请求，将资源描述yaml发至kube-apiserver，请求kube-apiserver生成该yaml文件中的资源。

上述说明是针对本发明较佳实施例的详细说明，但实施例并非用以限定本发明的专利申请范围，凡本发明所提示的技术精神下所完成的同等变化或修饰变更，均应属于本发明所涵盖专利范围。

Claims (4)

1.一种基于Kubernetes构建动态资源准入控制器的方法，其包括补丁控制器、验证控制器、自动生成控制器和命令行控制器四个组件，其特征在于，包括如下步骤：

S1、初始化系统配置至kubernetes集群中，如果配置出错，则退出系统；

S2、初始化命令行控制器、启动补丁控制器、验证控制器、自动生成控制器，若任意一个控制器出错则不断重试，直至所有控制器均正常运行，当所有组件正常运行时表示准入系统正常运行；

S3、所述命令行控制器除了初始化时自动与kube-apiserver交互，其余皆由操作人员直接操作，用于验证和应用准入策略，与apiserver进行交互；

S4、所述补丁控制器、验证控制器、自动生成控制器在kube-apiserver处理请求的流程中分别实现三个钩子拦截请求，完成准入控制的逻辑；

所述补丁控制器的操作步骤如下：

A1、补丁控制器收到kube-apiserver的请求；

A2、补丁控制器根据资源的类型，筛选出已激活的补丁策略，如果存在已激活的补丁策略，则初始化一个空白的补丁结构，进入下一个步骤，如不包含该种类型已激活的补丁策略，进入步骤A6；

A3、循环该种类型的所有补丁策略，如还有未处理的补丁策略，进入下一个步骤，循环结束后进入步骤A6；

A4、确认kube-apiserver传输的请求是否适用当前补丁策略，如果适用则进入下一个步骤，如不适用，返回步骤A3；

A5、使用补丁策略中的内容注入步骤A2中的补丁结构，返回步骤A3；

A6、构造一个响应，与步骤A2中的补丁一起编组，然后将其发送回kube-apiserver；

所述验证控制器的操作步骤如下：

B1、验证控制器收到kube-apiserver的请求；

B2、验证控制器根据资源的类型，筛选出已激活的验证策略，如果存在已激活的验证策略则进入下一个步骤，如不包含该种类型已激活的验证策略，标记验证通过并进入步骤B6；

B3、循环该种类型的所有验证策略，如还有未处理的验证策略，进入下一个步骤，循环结束后，标记验证通过并进入步骤B6；

B4、确认kube-apiserver传输的请求是否适用当前验证策略，如果适用则进入下一个步骤，如不适用，返回步骤B3；

B5、验证kube-apiserver的请求是否通过验证策略，如果不通过，标记验证不通过并进入步骤B6，如果通过，返回步骤B3；

B6、如果请求标记为验证通过，构造一个验证成功的响应，如果标记为失败，则构造一个验证失败的响应，然后将响应发送回kube-apiserver；

所述自动生成控制器的操作步骤如下：

C1、自动生成控制器监听kube-apiserver的事件,当有新的自动生成策略应用，如还未监听触发事件，便增加一个监听，使得自动生成控制器得以自动生成资源；

C2、收到kube-apiserver的事件后，生成控制器根据事件的类型，筛选出已激活的自动生成策略，如果存在已激活的自动生成策略，则初始化一个空白的资源描述yaml，进入下一个步骤，如不包含该种类型已激活的自动生成策略，直接结束；

C3、循环该种类型的所有自动生成策略，如还有未处理的自动生成策略，进入下一个步骤，循环结束后进入步骤C6；

C4、确认当前的事件是否适用自动生成策略，如果适用则进入下一个步骤，如不适用，返回步骤C3；

C5、使用自动生成策略中的内容补充到步骤C2中的资源描述yaml，返回步骤C3；

C6、构造一个请求，将资源描述yaml发至kube-apiserver，请求kube-apiserver生成该yaml文件中的资源。

2.如权利要求1所述的基于Kubernetes构建动态资源准入控制器的方法，其特征在于，所述步骤S1中，所述系统配置包括：

补丁控制器、验证控制器的连接信息；

补丁控制器、验证控制器的验证信息；以及

处理来自补丁控制器、验证控制器的无法识别的错误信息提示。

3.如权利要求1所述的基于Kubernetes构建动态资源准入控制器的方法，其特征在于，所述步骤S3中，所述命令控制器的操作步骤如下：

S3.1、命令行控制器启动后，验证系统已有的准入策略，如有不完整或出错的策略，打印到日志中并将该策略配置为停用状态,正常的策略配置为激活状态，命令行控制器将一直运行在后台中，等待新的命令；

S3.2、管理员或开发者进入命令行控制器，可以验证或应用准入策略，可将多个准入策略用于多个资源，

S3.3、命令行控制器通过kube-apiserver进行策略的读取、写入和激活操作，策略最终由kube-apiserver写入etcd存储中；

S3.4、命令行控制器针对策略进行验证时，会判断该策略由哪个控制器进行操作，再调用响应的控制器进行策略验证,验证的内容包括格式是否准确，与现有策略是否冲突；

S3.5：命令行控制器针对策略进行应用时，先按照步骤S3.4进行策略验证,验通过后通过kube-apiserver将其写入集群，验证不通过则不允许提交。

4.如权利要求1所述的基于Kubernetes构建动态资源准入控制器的方法，其特征在于，所述步骤S3.2中，所述准入策略包括补丁策略、验证策略和自动生成策略，每种策略分别对应一个控制器，分别为补丁控制器、验证控制器、自动生成控制器。