CN114462024A - 容器安全防护方法、装置、设备及存储介质 - Google Patents

Abstract

本公开提供了一种容器安全防护方法、装置、设备及存储介质，涉及安全检测技术领域。该方法包括：在容器镜像试启动时，提取容器中***调用的特征；基于***调用的特征，生成***调用白名单配置文件；在容器启动运行时，将***调用白名单配置文件添加到容器的配置文件中；基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用。本公开实施例提供的容器安全防护方法，采用白名单方式实现异常***调用的阻断，增强容器安全防护能力，降低风险。

Description

容器安全防护方法、装置、设备及存储介质

技术领域

本公开涉及安全检测技术领域，尤其涉及一种容器安全防护方法、装置、设备及存储介质。

背景技术

容器安全防护是保障微服务化及应用的重要手段之一。相关技术中，容器安全防护思路是通过依赖linux内核的namespace、cgroups实现容器的资源限制与隔离；使用Docker官方推荐使用的grsec内核补丁以提高容器宿主机的安全性；以及访问控制限制容器之间的互联。相关技术中缺乏容器内安全检测机制，仍存在较大的安全风险。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种容器安全防护方法、装置、设备及存储介质，至少在一定程度上克服相关技术中缺乏容器内安全检测机制，仍存在较大的安全风险的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种容器安全防护方法，包括：

在容器镜像试启动时，提取容器中***调用的特征；

基于***调用的特征，生成***调用白名单配置文件；

在容器启动运行时，将***调用白名单配置文件添加到容器的配置文件中；

基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用。

在本公开的一个实施例中，基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用之前，方法还包括：

根据容器的启动命令和启动配置文件，判断是否启动容器。

在本公开的一个实施例中，方法还包括：

在容器处于预设的提权逃逸状态时，禁止容器启动。

在本公开的一个实施例中，预设的提权逃逸状态包括如下状态中的至少一种：

特权模式启动容器、以root权限启动容器、检测到linux内核版本异常、检测到kubernetes版本异常、检测到Docker版本异常。

在本公开的一个实施例中，在容器镜像试启动时，提取容器中***调用的特征，包括：

在容器启动到稳定状态时，提取容器中***调用的如下特征中的至少一种：

容器中使用的二进制文件和库、容器中使用的可执行文件、容器中使用的libc函数。

在本公开的一个实施例中，在容器镜像试启动时，提取容器中***调用的特征之后，方法还包括：

通过objdump提取容器中***调用的特征中所有直接***调用；

基于***调用的特征，生成***调用白名单配置文件，包括：

基于所有直接***调用，生成***调用白名单配置文件。

在本公开的一个实施例中，基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用，包括：

根据提取的***调用列表对容器的***调用进行匹配，判断容器的***调用是否属于***调用白名单；

在容器的***调用属于***调用白名单时，执行容器的***调用；

在容器的***调用不属于***调用白名单时，禁止容器的***调用。

在本公开的一个实施例中，方法还包括：

在容器的主机操作***层设置***调用检测模块。

在本公开的一个实施例中，方法还包括：

在容器的容器引擎层设置容器配置检测模块。

根据本公开的另一个方面，提供一种容器安全防护装置，装置包括：

特征提取模块，用于在容器镜像试启动时，提取容器中***调用的特征；

白名单生成模块，用于基于***调用的特征，生成***调用白名单配置文件；

容器配置修改模块，用于在容器启动运行时，将***调用白名单配置文件添加到容器的配置文件中；

***调用控制模块，用于基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用。

根据本公开的再一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述的容器安全防护方法。

根据本公开的又一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的容器安全防护方法。

本公开的实施例所提供的容器安全防护方法，能够根据提取的容器中***调用的特征，生成***调用白名单配置文件，采用白名单方式实现异常***调用的阻断，增强容器安全防护，降低风险。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本公开实施例中一种Docker容器***示意图；

图2示出本公开实施例中Docker虚拟化的架构示意图；

图3示出相关技术中一种Docker架构示意图；

图4示出本公开实施例中一种Docker架构示意图；

图5示出本公开实施例中一种容器安全防护方法流程示意图；

图6示出相关技术中一种容器安全防护方法流程示意图；

图7示出本公开实施例中另一种容器安全防护方法流程示意图；

图8示出本公开实施例中一种容器安全防护装置示意图；

图9示出本公开实施例中一种计算机设备的结构框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

基于背景技术部分可知，相关技术中缺乏容器内安全检测机制，仍存在较大的安全风险。

具体地，由于缺乏容器内安全检测机制，仍存在容器逃逸、容器内提权行为等容器内运行进程的安全风险，有可能导致高权限的容器具有与宿主机root相同的权限，进而对宿主机发起恶意攻击。

为解决上述问题，本公开实施例提供一种容器安全防护方法、装置、设备及存储介质，在容器引擎(Docker Engine)层和主机操作***(Host os)层分别新增容器配置检测模块和***调用检测模块，通过提取容器二进制文件、依赖库以及所有直接的***调用，采用白名单方式实现异常***调用的阻断；通过周期性地检测容器启动命令和配置，发现异常的启动行为，并下发阻断策略中止不安全容器的启动，可以有效解决容器逃逸、容器内提权行为等容器内运行进程的检测困难问题。

为了便于理解，下面首先对本公开涉及到的相关技术及名词解释如下：

Docker是一个集开发、打包、运行应用于一体的开放式平台。Docker可以用来快速交付应用。使用Docker，可以将应用程序从你的基础设施中分离出来，并将基础设施当作一个管理平台。Docker可以加快打包时间，加快测试，加快发布，缩短开发及运行代码之间的周期。

Docker可以应用于如下场景：Web应用的自动化打包和发布；自动化测试和持续集成、发布；在服务型环境中部署和调整数据库或其他的后台应用；从头编译或者扩展现有的OpenShift或Cloud Foundry平台来搭建自己的PaaS环境。

在一个实施例中，如图1所示，Docker是一个Client-Server结构的***，Docker守护进程运行在主机上，然后通过Socket连接从客户端访问Docker守护进程。

Docker守护进程从客户端接受命令，并按照命令，管理运行在主机上的容器。

一个Docker容器，是一个运行时环境，可以简单理解为进程运行的集装箱。

Docker是一个开源的应用容器引擎，基于Go语言并遵从Apache2.0协议开源。

Docker可以让开发者打包应用以及依赖包到一个轻量级、可移植的容器中，然后发布到Linux机器上，也可以实现虚拟化。

在一些实施例中，Docker架构可以包括镜像(Image)、容器(Container)和仓库(Repository)。

Docker镜像是用于创建Docker容器的模板，比如Ubuntu***。

Docker镜像可以是一个只读的模板。包含了容器运行时所需要的文件***和一些参数。镜像是无状态的，也不会改变。镜像是用来创建容器的，可以使用Docker pull命令获取一个别人已创建好的镜像，或者使用Dockerbuild来构建一个自己的镜像。

Docker镜像，相当于是一个root文件***。比如官方镜像ubuntu:16.04就包含了完整的一套Ubuntu16.04最小***的root文件***。

Docker容器是独立运行的一个或一组应用，是镜像运行时的实体。

Docker容器就像是一个文件夹，容器中包含了应用运行所需的一切。每个容器都是一个隔离的和安全的应用平台。容器是镜像的一个实例，它是有状态的，而且随时会改变，容器一般是短暂的。

镜像和容器的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

Docker仓库可看成一个代码控制中心，用来保存镜像，可以理解为代码控制中的代码仓库。

一个Docker Registry中可以包含多个仓库；每个仓库可以包含多个标签(Tag)；每个标签对应一个镜像。通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过<仓库名>:<标签>的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以latest作为默认标签。

Docker使用客户端-服务器(C/S)架构模式，使用远程API来管理和创建Docker容器。Docker容器通过Docker镜像来创建。

Docker客户端通过命令行或者其他工具使用Docker SDK与Docker的守护进程通信。

Docker和kvm都是虚拟化技术，它们的主要差别在于：Docker有着比虚拟机更少的抽象层；Docker利用的是宿主机的内核，VM需要的是Guest OS。

VM(VMware)在宿主机器、宿主机器操作***的基础上创建虚拟层、虚拟化的操作***、虚拟化的仓库，然后再安装应用；

Container(Docker容器)，在宿主机器、宿主机器操作***上创建Docker引擎，在引擎的基础上再安装应用。

所以说，新建一个容器的时候，Docker不需要像虚拟机一样重新加载一个操作***，避免引导。Docker是利用宿主机的操作***，省略了这个复杂的过程。

图2示出了Docker虚拟化的架构：其中容器引擎(Docker Engine)201可以简单看成对Linux的NameSpace、Cgroup、镜像管理文件***操作的封装。Docker并没有和虚拟机一样利用一个完全独立的Guest OS实现环境隔离，它利用的是目前linux内核本身支持的容器方式实现资源和环境隔离。

简单的说，Docker是利用namespace实现***环境的隔离；利用Cgroup实现资源限制；利用镜像实现根目录环境的隔离。

Docker Host(主机)一个物理或者虚拟的机器用于执行Docker守护进程和容器。也就是图2中的，主机操作***202。

Docker Engine属于Docker的运行层。这是一套轻量化运行时及工具组合，负责管理容器、镜像、构建等等。它以原生方式运行在Linux***之上，并由以下元素构成：

Docker Daemon，运行在主机计算机之上；

Docker Client，负责与Docker Daemon通信以执行命令；

REST API，用于同Docker Daemon远程交互。

Docker Daemon直接将执行命令发送至Docker Client——例如构建、运行以及分发等等。Docker Daemon运行在主机设备之上，但作为用户，我们永远不会直接与该Daemon进行通信。Docker Client也可以运行在主机设备上，但并非必需。它亦能够运行在另一台设备上，并与运行在目标主机上的Docker Daemon进行远程通信。

Docker Client是最终用户的通信对象，可以将其视为Docker的UI。一切操作都将直接接入Docker Client，再由其将指令传递至Docker Daemon。

REST API，用于同Docker Daemon远程交互。

本公开实施例的容器安全防护方法可应用于Linux***中，通过容器技术作为底层技术，搭建相对独立的运行环境，该相对独立的运行环境较传统技术搭建的运行环境安全性较差。

相关技术中，容器安全防护思路是通过依赖Linux内核的Namespace、Cgroups实现容器的资源限制与隔离；使用Docker官方推荐使用GRSEC内核补丁以提高容器宿主机的安全性；以及访问控制限制容器之间的互联。

在一个示例中，如图3所示，可以通过在容器的容器引擎层301设置文件***度量模块3011、进程监控模块3012以及网络监控模块3013来提升容器的安全防护等级。但是，仍然缺乏容器内安全检测机制，仍存在容器逃逸、容器内提权行为等容器内运行进程的安全风险，有可能导致高权限的容器具有与宿主机root相同的权限，进而对宿主机发起恶意攻击。

如图4所示，本公开实施例中，在容器引擎层401和主机操作***层402分别新增容器配置检测模块4011和***调用检测模块4021，通过提取容器二进制文件、依赖库以及所有直接的***调用，采用白名单方式实现异常***调用的阻断；通过周期性地检测容器启动命令和配置，发现异常的启动行为，并下发阻断策略中止不安全容器的启动，可以有效解决容器逃逸、容器内提权行为等容器内运行进程的检测困难问题。

下面结合附图及实施例对本示例实施方式进行详细说明。

首先，本公开实施例中提供了一种容器安全防护方法，该方法可以由任意具备计算处理能力的电子设备执行。

图5示出本公开实施例中一种容器安全防护方法流程图，如图5所示，本公开实施例中提供的容器安全防护方法包括如下步骤：

步骤S502，在容器镜像试启动时，提取容器中***调用的特征；

步骤S504，基于***调用的特征，生成***调用白名单配置文件；

步骤S506，在容器启动运行时，将***调用白名单配置文件添加到容器的配置文件中；

步骤S508，基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用。

需要说明的是，在执行本公开实施例提供的容器安全防护方法前，如图4所示可以先在容器的Host os层设置***调用检测模块；在容器的Docker Engine层设置容器配置检测模块。

下面对上述步骤进行详细说明，具体如下所示：

上述步骤中的容器镜像可以是前文介绍中的容器镜像，可以是用于创建Docker容器的模板，比如Ubuntu***。

白名单的概念与“黑名单”相对应。例如：在电脑***里，有很多软件都应用到了黑白名单规则，操作***、防火墙、杀毒软件、邮件***、应用软件等，凡是涉及到控制方面几乎都应用了黑白名单规则。

黑名单启用后，被列入到黑名单的用户(或IP地址、IP包、邮件、病毒等)不能通过。如果设立了白名单，则在白名单中的用户(或IP地址、IP包、邮件等)会优先通过，不会被当成垃圾邮件拒收，安全性和快捷性都大大提高。将其含义扩展一步，那么凡有黑名单功能的应用，就会有白名单功能与其对应。

配置文件的相关介绍参考前文中对Docker的相关介绍，在此不再赘述。

上述步骤中，将***调用白名单配置文件添加到容器的配置文件中，也就是修改容器的配置文件。这里，修改容器的配置文件的方法有很多。

作为一个示例，在修改容器的配置文件时，可以先进入容器内部，sudo Dockerexec-it容器名或ID/bin/bash；然后，更新软件列表，安装vim命令，进而修改配置文件。

需要说明的是，在该示例中Docker中每个镜像都是单独的，如果在一个容器中安装了vim命令在其他容器中使用vim命令是不生效的所以需要在每个镜像中都安装vim或vi。

在一些实施例中，上述步骤S508基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用，可以具体实现如下：

根据提取的***调用列表对容器的***调用进行匹配，判断容器的***调用是否属于***调用白名单；

在容器的***调用属于***调用白名单时，执行容器的***调用；

在容器的***调用不属于***调用白名单时，禁止容器的***调用。

本公开实施例中引入了***调用检测模块，可以阻断告警容器的运行时未在***调用白名单的异常行为，优化了原有专利对进程白名单的判断，细化判断颗粒度，优化了相关技术中无法对白名单进程内的异常***调用的阻断告警的情况。

在本公开实施例中，Docker启动，然后修改容器启动的配置文件；并在容器镜像试启动时，提取容器中***调用的特征，通过objdump提取其中所有直接***调用，生成***调用白名单配置文件，运行时添加到容器的配置文件。

随后，容器启动命令检测、启动配置文件检测，容器正常启动后，持续监控容器***调用、用户权限，校验***调用白名单。

在一些实施例中，在容器镜像试启动时，提取容器中***调用的特征，可以包括：

在容器启动到稳定状态时，提取容器中***调用的如下特征中的至少一种：

容器中使用的二进制文件和库、容器中使用的可执行文件、容器中使用的libc函数。

其中，在容器镜像试启动时，提取容器中***调用的特征之后，该方法还可以包括：

通过objdump提取容器中***调用的特征中所有直接***调用；

相应地，基于***调用的特征，生成***调用白名单配置文件，可以包括：

基于所有直接***调用，生成***调用白名单配置文件。

在一些实施例中，在基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用之前，上述方法还可以包括：

根据容器的启动命令和启动配置文件，判断是否启动容器。

在容器处于预设的提权逃逸状态时，禁止容器启动；

在容器未处于预设的提权逃逸状态时，正常启动容器。

其中，预设的提权逃逸状态可以包括如下状态中的至少一种：

特权模式启动容器、以root权限启动容器、检测到linux内核版本异常、检测到kubernetes版本异常、检测到Docker版本异常。

这里，判断是否启动容器时，容器启动命令检测、启动配置文件检测，检测容器以不当配置启动的漏洞风险，如特权模式启动容器，以root权限启动容器，linux内核版本检测、Kubernetes版本检测、Docker版本检测等。

在一切正常时，容器正常启动，并持续监控容器***调用、用户权限；

在出现异常时，对异常的***调用进行告警。

本公开实施例中引入了容器配置检测模块，通过对容器启动前的配置、命令进行检测，对不安全的启动行为进行阻断告警，降低容器运行的安全风险。优化了相关技术中无法对特权模式启动的不安全行为阻断与监控的情况。

下面结合附图6和附图7说明本公开实施例与相关技术中容器安全防护方法的区别。

图6示出了一种相关技术中的容器安全防护方法，该方法可以包括如下步骤：

步骤S601，Docker启动；

步骤S602，监控镜像获取命令；

步骤S603，计算镜像hash基准值；

步骤S604，校验hash基准值；

在基准值不一致时，执行步骤S605，不启动容器；

在基准值一致时，执行步骤S606，启动容器；

步骤S606之后，执行如下步骤：

步骤S607，用户输入指定容器的管理策略，进程白名单；

步骤S608，校验容器的进程白名单；

在通过校验后，执行步骤S609，正常运行；

在未通过校验时，执行步骤S610，拦截告警。

这里，图6所述的方法可以应用在前文中图3所示的Docker架构中。下面结合附图7，说明本公开实施例提供的容器安全防护方法与图6中安全防护方法的区别。

如图7所示，以部署容器为示例，本公开实施例的具体实施步骤可以如下：

步骤S701，Docker启动；

步骤S702，修改容器启动的配置文件；

步骤S703，容器镜像试启动；

步骤S704，容器中***调用特征的提取；

步骤S705，通过objdump提取其中所有直接***调用，生成***调用白名单配置文件，运行时添加到容器的配置文件；

步骤S706，容器启动命令检测、启动配置文件检测；

在检测到异常时，执行步骤S707，禁止启动；

在未检测到异常时，执行步骤S708，容器正常启动，持续监控容器***调用、用户权限；

步骤S709，校验***调用白名单；

在通过校验后，执行步骤S710，正常调用；

在未通过校验时，执行步骤S711，禁止调用。

上述步骤S704可以具体包括提取启动到稳定状态容器中使用的二进制文件和库；提取容器中使用的可执行文件；提取容器中使用的libc函数。

上述步骤S706，用于检测容器以不当配置启动的漏洞风险，如特权模式启动容器，以root权限启动容器，linux内核版本检测、Kubernetes版本检测、Docker版本检测等。

本公开实施例提供的一种容器安全增强方法，在Docker和Host层分别新增容器配置检测模块和***调用检测模块，通过提取容器二进制文件、依赖库以及所有直接的***调用，采用白名单方式实现异常***调用的阻断；通过周期性地检测容器启动命令和配置，发现异常的启动行为，并下发阻断策略中止不安全容器的启动，可以有效解决容器逃逸、容器内提权行为等容器内运行进程的检测困难问题。

基于同一发明构思，本公开实施例中还提供了一种容器安全防护装置，如下面的实施例所述。由于该装置实施例解决问题的原理与上述方法实施例相似，因此该装置实施例的实施可以参见上述方法实施例的实施，重复之处不再赘述。

图8示出本公开实施例中一种容器安全防护装置示意图，如图8所示，该容器安全防护装置800包括：

特征提取模块802，用于在容器镜像试启动时，提取容器中***调用的特征；

白名单生成模块804，用于基于***调用的特征，生成***调用白名单配置文件；

容器配置修改模块806，用于在容器启动运行时，将***调用白名单配置文件添加到容器的配置文件中；

***调用控制模块808，用于基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用。

在一些实施例中，该容器安全防护装置800，还可以包括：

容器启动判断模块，用于基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用之前，根据容器的启动命令和启动配置文件，判断是否启动容器。

在一些实施例中，容器启动判断模块，还可以用于：

在容器处于预设的提权逃逸状态时，禁止容器启动。

在一些实施例中，预设的提权逃逸状态可以包括如下状态中的至少一种：

特权模式启动容器、以root权限启动容器、检测到linux内核版本异常、检测到kubernetes版本异常、检测到Docker版本异常。

在一些实施例中，在容器镜像试启动时，提取容器中***调用的特征，包括：

在容器启动到稳定状态时，提取容器中***调用的如下特征中的至少一种：

容器中使用的二进制文件和库、容器中使用的可执行文件、容器中使用的libc函数。

在一些实施例中，在容器镜像试启动时，提取容器中***调用的特征之后，还包括：

通过objdump提取容器中***调用的特征中所有直接***调用；

基于***调用的特征，生成***调用白名单配置文件，包括：

基于所有直接***调用，生成***调用白名单配置文件。

在一些实施例中，基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用，包括：

根据提取的***调用列表对容器的***调用进行匹配，判断容器的***调用是否属于***调用白名单；

在容器的***调用属于***调用白名单时，执行容器的***调用；

在容器的***调用不属于***调用白名单时，禁止容器的***调用。

在一些实施例中，还包括：

在容器的Host os层设置***调用检测模块。

在一些实施例中，还包括：

在容器的Docker Engine层设置容器配置检测模块。

本申请实施例提供的容器安全防护装置，可以用于执行上述各方法实施例提供的容器安全防护方法，其实现原理和技术效果类似，为简介起见，在此不再赘述。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为***、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“***”。

下面参照图9来描述根据本公开的这种实施方式的电子设备900。图9显示的电子设备900仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：上述至少一个处理单元910、上述至少一个存储单元920、连接不同***组件(包括存储单元920和处理单元910)的总线930。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元910执行，使得所述处理单元910执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，所述处理单元910可以执行上述方法实施例的如下步骤：

在容器镜像试启动时，提取容器中***调用的特征；

基于***调用的特征，生成***调用白名单配置文件；

在容器启动运行时，将***调用白名单配置文件添加到容器的配置文件中；

基于容器的配置文件中的***调用白名单配置文件，控制容器的***调用。

在一些实施例中，所述处理单元910还可以执行上述方法实施例的如下步骤：

根据容器的启动命令和启动配置文件，判断是否启动容器。

在一些实施例中，所述处理单元910还可以用于执行上述方法实施例的如下步骤：

在容器处于预设的提权逃逸状态时，禁止容器启动。

在一些实施例中，所述处理单元910还可以用于执行上述方法实施例的如下步骤：

通过objdump提取容器中***调用的特征中所有直接***调用；

基于***调用的特征，生成***调用白名单配置文件，包括：

基于所有直接***调用，生成***调用白名单配置文件。

存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)9201和/或高速缓存存储单元9202，还可以进一步包括只读存储单元(ROM)9203。

存储单元920还可以包括具有一组(至少一个)程序模块9205的程序/实用工具9204，这样的程序模块9205包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、***总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备900也可以与一个或多个外部设备940(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备900交互的设备通信，和/或与使得该电子设备900能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口950进行。

并且，电子设备900还可以通过网络适配器960与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。

如图9所示，网络适配器960通过总线930与电子设备900的其它模块通信。

应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质可以是可读信号介质或者可读存储介质。其上存储有能够实现本公开上述方法的程序产品。

在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。

本公开中的计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

在本公开中，计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。

这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。

可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

在一些示例中，计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

在具体实施时，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。

程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。

实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。

因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。

本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (12)

1.一种容器安全防护方法，其特征在于，所述方法包括：

在容器镜像试启动时，提取容器中***调用的特征；

基于所述***调用的特征，生成***调用白名单配置文件；

在容器启动运行时，将所述***调用白名单配置文件添加到容器的配置文件中；

基于所述容器的配置文件中的***调用白名单配置文件，控制所述容器的***调用。

2.根据权利要求1所述的方法，其特征在于，所述基于所述容器的配置文件中的***调用白名单配置文件，控制所述容器的***调用之前，所述方法还包括：

根据所述容器的启动命令和启动配置文件，判断是否启动所述容器。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

在所述容器处于预设的提权逃逸状态时，禁止所述容器启动。

4.根据权利要求3所述的方法，其特征在于，所述预设的提权逃逸状态包括如下状态中的至少一种：

特权模式启动容器、以root权限启动容器、检测到linux内核版本异常、检测到kubernetes版本异常、检测到容器版本异常。

5.根据权利要求1所述的方法，其特征在于，所述在容器镜像试启动时，提取容器中***调用的特征，包括：

在所述容器启动到稳定状态时，提取容器中***调用的如下特征中的至少一种：

容器中使用的二进制文件和库、容器中使用的可执行文件、容器中使用的libc函数。

6.根据权利要求5所述的方法，其特征在于，所述在容器镜像试启动时，提取容器中***调用的特征之后，所述方法还包括：

通过objdump提取所述容器中***调用的特征中所有直接***调用；

所述基于所述***调用的特征，生成***调用白名单配置文件，包括：

基于所述所有直接***调用，生成***调用白名单配置文件。

7.根据权利要求1所述的方法，其特征在于，所述基于所述容器的配置文件中的***调用白名单配置文件，控制所述容器的***调用，包括：

根据提取的***调用列表对容器的***调用进行匹配，判断容器的***调用是否属于***调用白名单；

在所述容器的***调用属于***调用白名单时，执行所述容器的***调用；

在所述容器的***调用不属于***调用白名单时，禁止所述容器的***调用。

8.根据权利要求1-7任一所述的方法，其特征在于，所述方法还包括：

在所述容器的主机操作***层设置***调用检测模块。

9.根据权利要求1-7任一所述的方法，其特征在于，所述方法还包括：

在所述容器的容器引擎层设置容器配置检测模块。

10.一种容器安全防护装置，其特征在于，所述装置包括：

特征提取模块，用于在容器镜像试启动时，提取容器中***调用的特征；

白名单生成模块，用于基于所述***调用的特征，生成***调用白名单配置文件；

容器配置修改模块，用于在容器启动运行时，将所述***调用白名单配置文件添加到容器的配置文件中；

***调用控制模块，用于基于所述容器的配置文件中的***调用白名单配置文件，控制所述容器的***调用。

11.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-9中任意一项所述容器安全防护方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-9中任意一项所述的容器安全防护方法。

Images