一种基于sidecar方案的kubernetes业务容器安全性探测方法与流程

本发明涉及云计算安全领域，尤其是一种基于sidecar方案的kubernetes业务容器安全性探测方法。

背景技术：

随着微服务的热度不断上升，企业的业务上云也越来越普遍。越来越多的企业选择kubernetes集群来部署自己的应用，而docker作为实现微服务首选容器，在大规模部署的同时其安全性却没有引起足够的重视。目前有多种针对容器安全性的检测机制：

一类是针对容器镜像进行静态扫描，这类机制不能完全检测到运行时的异常行为

还有一类就是针对容器进行运行时安全检测，这类机制一般都需要对容器进行侵入式的修改，这无疑提高了业务部署的复杂度。

技术实现要素：

本发明所要解决的技术问题是：针对上述存在的问题，提供一种基于sidecar方案的kubernetes业务容器安全性探测方法，以对kubernetes业务容器做无侵入的运行时安全监测。

本发明采用的技术方案如下：

一种基于sidecar方案的kubernetes业务容器安全性探测方法，包括：

在内核中集成基于lsm和/或rootkit的安全模块；

在pod中为每一个需要监测和控制的kubernetes业务容器添加统一的sidecar容器，并为pod中的多容器开启共享进程命名空间；

sidecar容器中的监控进程与内核进行通讯，使sidecar容器中的监控进程和安全模块配合起来，根据sidecar容器中的安全监测选项，对kubernetes业务容器中的进程和文件系统进行监测和控制。

进一步地，所述在内核中集成基于lsm和/或rootkit的安全模块的方法为：

修改宿主机的内核代码，添加基于lsm的安全访问钩子，并在内核中开启内核服务，然后等待与sidecar容器中的监控进程进行通讯；

当不能修改宿主机的内核代码时，动态插入基于rootkit的安全监测模块，并在内核中开启内核服务，然后等待与sidecar容器中的监控进程进行通讯。

进一步地，在添加的sidecar容器中，能够根据业务需要自定义配置sidecar容器的安全监测选项。

进一步地，所述根据业务需要自定义配置sidecar容器的安全监测选项的方法为：通过环境变量配置覆盖sidecar容器中默认的安全监测选项。

进一步地，sidecar容器先于kubernetes业务容器启动。

进一步地，当发现kubernetes业务容器中的异常行文时，对异常行为进行的操作包括终止、告警和/或记录日志。

综上所述，由于采用了上述技术方案，本发明的有益效果是：

本发明实现了对kubernetes业务容器做无侵入的运行时安全监测，有效提高容器的安全性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明的基于sidecar方案的kubernetes业务容器安全性探测方法的原理框图。

图2为sidecar容器与kubernetes业务容器启动顺序示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明，即所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，一种基于sidecar方案的kubernetes业务容器安全性探测方法，其特征在于，包括：

在内核中集成基于lsm和/或rootkit的安全模块；

在pod中为每一个需要监测和控制的kubernetes业务容器添加统一的sidecar容器，并为pod中的多容器开启共享进程命名空间；sidecar容器中的监控进程与内核进行通讯，使sidecar容器中的监控进程和安全模块配合起来，根据sidecar容器中的安全监测选项，对kubernetes业务容器中的进程和文件系统进行监测和控制

sidecar容器中的监控进程与内核进行通讯，使sidecar容器中的监控进程和安全模块配合起来，根据sidecar容器中的安全监测选项，对kubernetes业务容器中的进程和文件系统进行监测和控制。

以下结合实施例对本发明的特征和性能作进一步的详细描述。

本实施例的基于sidecar方案的kubernetes业务容器安全性探测方法如下：

1、在内核中集成基于lsm和/或rootkit的安全模块；

(1)基于lsm的安全访问钩子

lsm机制的核心在于安全访问钩子(hook)，默认支持以下16类钩子：

可以通过修改宿主机的内核代码，添加基于lsm(linuxsecuritymodule)的安全访问钩子，并在内核中开启内核服务，然后等待与sidecar容器中的监控进程进行通讯；该基于lsm的安全访问钩子可以hook业务容器中的api(如程序执行、文件系统访问、网络访问、内存访问等api)，当基于lsm的安全访问钩子与sidecar容器中的监控进程进行通讯后，两者配合起来对kubernetes业务容器中的进程和文件系统等进行监测和控制。

(2)基于rootkit的安全监测模块

当不能修改宿主机的内核代码时，动态插入(如通过dkms(dynamickernelmodulesupport)方式插入)基于rootkit的安全监测模块，并在内核中开启内核服务，然后等待与sidecar容器中的监控进程进行通讯。rootkit技术同样是基于对vfs文件系统的hook，通过拦截vfs文件系统的api调用，同样能够监测和控制程序执行、文件系统访问、网络访问、内存访问等。由此，当基于rootkit的安全监测模块与sidecar容器中的监控进程进行通讯后，两者配合起来对kubernetes业务容器中的进程和文件系统进行监测和控制。

2.在pod中为每一个需要监测和控制的kubernetes业务容器添加统一的sidecar容器，并为pod中的多容器开启共享进程命名空间；

sidecar容器具有默认的安全监测配置，而实际使用时，在添加的sidecar容器中，能够根据业务需要自定义配置sidecar容器的安全监测选项。所述根据业务需要自定义配置sidecar容器的安全监测选项的方法为：通过环境变量配置覆盖sidecar容器中默认的安全监测选项。

另外，需要为pod中的多容器开启共享进程命名空间，可以通过v1.podspec中的shareprocessnamespace字段可启用该功能。当开启共享进程命名空间时，业务容器中的进程和文件系统对该pod中的所有其他容器(包括sidecar容器)都是可见，这包括了kubernetes业务容器中的/proc中所有可见信息，kubernetes业务容器的文件系统通过/proc/$pid/root链接对sidecar容器可见。由此，sidecar容器中的监控进程就可以对kubernetes业务容器中的进程和文件系统进行监测和控制。

3.sidecar容器中的监控进程与内核进行通讯，使sidecar容器中的监控进程和安全模块配合起来，根据sidecar容器中的安全监测选项，对kubernetes业务容器中的进程和文件系统等进行监测和控制。

如图2所示，根据kubernetes业务容器的定义，sidecar容器先于kubernetes业务容器启动，sidecar容器中的监控进程与内核进行通讯，根据sidecar容器中的安全监测选项(默认的安全监测选项或自定义配置的安全监测选项)，监测后续启动的kubernetes业务容器中的进程是否有异常行为，或监测kubernetes业务容器中的文件系统是否有异常行为(异常访问或异常挂载等操作)，对发现的异常行为进行包括终止、告警和/或记录日志的操作。

所述基于sidecar方案的kubernetes业务容器安全性探测方法的运行示例：

准备阶段：按照上述内容配置运行环境，然后按顺序启动sidecar容器和kubernetes业务容器。

运行阶段：sidecar容器会采集kubernetes业务容器中的可执行程序或动态库的hash值，然后通过sidecar容器的通道将这些hash值通知内核中的安全模块。内核中的安全模块按照规则，通过在rootkit或lsm中判断，首先检查准备执行该可执行程序的用户是否是指定用户，如果满足条件再检查可执行程序的hash值是否有效。非指定用户的操作将被放行，也就是内核中的安全模块不会影响宿主机的操作。而无效(hash值不匹配)的可执行程序或动态库将不允许执行或加载，内核中的安全模块将异常信息反馈给sidecar容器。

通过上述规则，kubernetes业务容器中的可执行程序和动态库的加载过程就会受到限制，即使容器中存在漏洞被攻击，也能限制攻击者通过执行攻击程序来破坏容器环境和宿主机环境。也就是说，通过本发明的方法，可对kubernetes业务容器做无侵入的运行时安全监测，有效提高容器的安全性。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。