记录器、记录方法及组件、检测方法及组件、云系统与流程

1.本技术涉及计算机技术领域，特别涉及一种记录器、记录方法及组件、检测方法及组件、云系统。


背景技术：

2.目前，应用程序的系统调用列表需要依赖syscall(system call的略写)采集工具(比如sysdig)才能完成信息记录，且记录应用程序系统调用信息的过程中，需要有经验的业务人员、内核开发人员的参与，人工参与容易出错且效率较低。
3.因此，如何快速确定应用程序的系统调用，是本领域技术人员需要解决的问题。


技术实现要素：

4.有鉴于此，本技术的目的在于提供一种记录器、记录方法及组件、检测方法及组件、云系统，以快速确定应用程序的系统调用。其具体方案如下：
5.第一方面，本技术提供了一种记录器，所述记录器为软件组件、且部署于云系统中的每个节点，包括：
6.确定模块，用于确定携带有第一标签的目标容器；
7.记录模块，用于记录所述目标容器中所有进程或部分指定进程的系统调用信息。
8.可选地，所述记录模块具体用于：
9.在所述目标容器的测试过程中，记录所述目标容器中所有进程或部分指定进程的系统调用信息。
10.可选地，所述记录模块具体用于：
11.若系统内核中当前运行的任一进程为所述目标容器中需记录系统调用信息的进程，则将该进程的进程id和相应的系统调用信息成对记录。
12.可选地，所述记录模块具体用于：
13.若系统内核中当前运行的任一进程的进程挂载目录属于所述目标容器，且该进程携带有第二标签，则确定该进程为所述目标容器中需记录系统调用信息的进程。
14.第二方面，本技术提供了一种记录方法，应用于上述任一项所述的记录器，包括：
15.确定携带有第一标签的目标容器；
16.记录所述目标容器中所有进程或部分指定进程的系统调用信息。
17.第三方面，本技术提供了一种检测方法，包括：
18.利用上述任一项所述的记录器、记录得到的目标容器中所有进程或部分指定进程的系统调用信息，检测所述目标容器运行过程中的系统调用。
19.第四方面，本技术提供了一种云系统，包括：多个节点，每个节点部署有上述任一项所述的记录器，至少一个节点部署有管理器和筛选器，所述管理器和所述筛选器为软件组件；
20.其中，所述管理器，用于将所述记录器记录得到的目标容器中所有进程或部分指
定进程的系统调用信息，分发至所述云系统中的每个节点；
21.所述筛选器，用于为所述目标容器添加第一标签。
22.第五方面，本技术提供了一种检测装置，包括：
23.检测单元，用于利用上述任一项所述的记录器、记录得到的目标容器中所有进程或部分指定进程的系统调用信息，检测所述目标容器运行过程中的系统调用。
24.第六方面，本技术提供了一种电子设备，包括：
25.存储器，用于存储计算机程序；
26.处理器，用于执行所述计算机程序，以实现前述公开的方法。
27.第七方面，本技术提供了一种可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的方法。
28.第八方面，本技术提供了一种计算机程序产品，包括计算机指令，当计算机指令在计算机上运行时，使得计算机可以执行前述公开的方法。
29.通过以上方案可知，本技术提供了一种记录器，所述记录器为软件组件、且部署于云系统中的每个节点，包括：确定模块，用于确定携带有第一标签的目标容器；记录模块，用于记录所述目标容器中所有进程或部分指定进程的系统调用信息。
30.本技术在云系统中的每个节点上都部署一个记录器，该记录器中的确定模块能够确定携带有第一标签的目标容器；该记录器中的记录模块能够记录目标容器中所有进程或部分指定进程的系统调用信息。如此该记录器就可以记录目标容器中所有进程或部分指定进程的系统调用信息，整个过程以容器为单位自动化进行，技术难度低，因此能够快速确定容器系统调用名单。
31.相应地，本技术提供的一种记录方法及组件、检测方法及组件、云系统，也同样具有上述技术效果。
附图说明
32.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
33.图1为本技术公开的一种记录器示意图；
34.图2为本技术公开的一种记录方法流程图；
35.图3为本技术公开的一种系统调用信息记录方法流程图；
36.图4为本技术公开的一种seccomp profile任务生成以及执行流程示意图；
37.图5为本技术公开的一种ebpf controller组件收集信息的流程图；
38.图6为本技术公开的一种电子设备示意图；
39.图7为本技术公开的另一种电子设备示意图。
具体实施方式
40.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于
本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
41.当前，可以使用seccomp安全模块限制进程的系统调用(system call)，seccomp是linux系统内核2.6.12版本引入的安全模块，因此在确定某一应用程序的系统调用名单后，可以利用seccomp模块使相应应用仅调用该名单内的系统调用。也就是说，在使用seccomp防护系统安全之前，首先需要明确程序可用的系统调用有哪些。当前使用的syscall采集工具需要依靠人工对syscall进行筛选，具体问题有：人工筛选不适用于大规模的云原生应用，因为效率太低，自动化程度低，不适合大规模普及；采集工具得到的seccomp profile(系统调用名单)的路径过于复杂并且依赖于工具本身，也很容易出错。
42.可见，应用程序的系统调用列表需要依赖syscall采集工具才能确定，且确定应用程序系统调用的过程中，需要有经验的业务人员、内核开发人员的参与，人工参与容易出错且效率较低。为此，本技术提供了一种系统调用信息记录方案，能够快速确定应用程序的系统调用名单。一般地，应用程序可以是容器应用。一般可以使用一个容器来运行小型微服务或软件进程，容器包含所有必要的可执行文件、二进制代码、库和配置文件。
43.在一种示例中，可以构建云原生(cloud native)的容器应用。cloud native是一个组合词。cloud表示适应范围为云平台，native表示应用程序从设计之初即考虑到云环境，因此云原生指：为云而设计，此类应用能在云上以最佳状态运行，其能够充分利用和发挥云平台的弹性和分布式优势。当然，本技术可针对云原生容器应用进行系统调用名单的收集。
44.下面对本技术实施例提供的一种记录器进行介绍，下文描述的一种记录器可以与下述各实施例相互参照。
45.参见图1所示，本技术实施例公开了一种记录器，该记录器为软件组件、且部署于云系统中的每个节点，包括：确定模块，用于确定携带有第一标签的目标容器；记录模块，用于记录目标容器中所有进程或部分指定进程的系统调用信息。
46.在一种实施方式中，记录模块具体用于：在目标容器的测试过程中，记录目标容器中所有进程或部分指定进程的系统调用信息。由于目标容器在上线之前需要进行测试，而测试目标容器会无一遗漏地测试该容器的全部功能，那么目标容器需要的系统调用就会无一遗漏地在测试过程中发生。因此在测试目标容器时，记录该目标容器中所有进程或部分指定进程的系统调用信息，那么待目标容器测试完成后，汇总测试过程中记录的所有系统调用信息，既完成了目标容器的测试，又得到了目标容器的系统调用名单。
47.在本实施例中，携带有第一标签的目标容器即：需要进行系统调用信息收集的容器。由于一个节点中可能部署有很多容器，而并非所有容器都需要进行系统调用信息的记录，因此对需要进行系统调用记录的容器标记第一标签。并且本实施例在测试容器的过程中记录其系统调用，因此在测试目标容器时，若确定目标容器携带有第一标签，则在目标容器的测试过程中，记录目标容器中所有进程或部分指定进程的系统调用信息；待目标容器测试完成，汇总测试过程中记录的各个进程的系统调用信息，就能够得到目标容器的系统调用名单。
48.在一种实施方式中，记录模块具体用于：若系统内核中当前运行的任一进程为目标容器中需记录系统调用信息的进程，则将该进程的进程id和相应的系统调用信息成对记
录。例如：以进程id作为key值，以系统调用信息作为value值，将当前发生的系统调用记录成一个键值对。
49.在一种实施方式中，记录模块具体用于：若系统内核中当前运行的任一进程的进程挂载目录属于目标容器，且该进程携带有第二标签，则确定该进程为目标容器中需记录系统调用信息的进程。可见，第二标签用于标记目标容器中需要记录系统调用的进程，因此基于第二标签可判断出系统内核中当前运行的进程是否需要记录系统调用信息。
50.由于一个容器中可能有很多进程，而当前系统也需要很多进程支持其运行，所以当前系统中可能有很多进程都需要进行系统调用，这些进程有的属于目标容器，有的不属于目标容器。因此，为了明确哪些进程的系统调用信息需要记录，哪些不需要记录，可以区分以下两种情况进行设计。情况一：若目标容器中的所有进程的系统调用都需要记录，那么判断进行系统调用的进程是否属于目标容器即可，只要确定进行系统调用的进程属于目标容器，就记录相应进程的系统调用信息。情况二：若仅需要记录目标容器中个别进程的系统调用信息，那么不仅要判断进行系统调用的进程是否属于目标容器，还要判断进行系统调用的进程是否是目标容器中需要记录系统调用的进程，如果都满足，就记录相应进程的系统调用信息。
51.在一种实施方式中，情况一对应的具体实现步骤可以包括：在系统内核中有进程运行时，记录系统内核中当前运行的任一进程的进程id和进程挂载目录；若基于进程挂载目录确定当前运行的该进程属于目标容器，则确定该进程为目标容器中需记录系统调用信息的进程，因此将该进程的进程id和相应的系统调用信息成对记录。其中，基于进程挂载目录可以看出进程是否属于目标容器所在目录，由此即可判断出系统内核中当前运行的进程是否属于目标容器。系统内核指：当前节点的系统内核。
52.在一种实施方式中，情况二对应的具体实现步骤可以包括：在系统内核中有进程运行时，记录系统内核中当前运行的任一进程的进程id和进程挂载目录；若当前运行的该进程携带有第二标签、且基于进程挂载目录确定当前运行的该进程属于目标容器，则确定该进程为目标容器中需记录系统调用信息的进程，在该进程发起系统调用时，将该进程的进程id和相应的系统调用信息成对记录。其中，第二标签用于标记目标容器中需要记录系统调用的进程，因此基于第二标签可判断出系统内核中当前运行的进程是否需要记录系统调用信息。
53.需要说明的是，该记录器可以基于下文公开的系统调用信息记录方法设计得到。
54.其中，一个进程的系统调用信息一般以列表的形式记录，那么可以汇总一个容器中不同进程的系统调用信息，得到容器的系统调用名单，当然在汇总的结果中，需要以进程id区分不同进程的系统调用信息。在一种示例中，可以将目标容器中需要记录系统调用的进程记录为一个进程名单，那么在汇总时，基于该进程名单确定是否有遗漏或重复信息。因此在一种实施方式中，可以基于目标容器中需收集系统调用信息的进程名单，合并已记录的各个进程的系统调用信息。该进程名单在容器测试的过程中记录得到。
55.可见，本实施例在云系统中的每个节点上都部署一个记录器，该记录器中的确定模块能够确定携带有第一标签的目标容器；该记录器中的记录模块能够记录目标容器中所有进程或部分指定进程的系统调用信息。如此该记录器就可以记录目标容器中所有进程或部分指定进程的系统调用信息，整个过程以容器为单位自动化进行，技术难度低，因此能够
快速确定容器系统调用名单。
56.下面对本技术实施例提供的一种记录方法进行介绍，下文描述的一种记录方法与上文描述的一种记录器可以相互参照。
57.参见图2所示，本技术实施例公开了一种记录方法，应用于上述实施例所述的记录器，包括：
58.s201、确定携带有第一标签的目标容器。
59.s202、记录目标容器中所有进程或部分指定进程的系统调用信息。
60.由于目标容器在上线之前需要进行测试，而测试目标容器会无一遗漏地测试该容器的全部功能，那么目标容器需要的系统调用就会无一遗漏地在测试过程中发生。因此在测试目标容器时，记录该目标容器中所有进程或部分指定进程的系统调用信息，那么待目标容器测试完成后，汇总测试过程中记录的所有系统调用信息，既完成了目标容器的测试，又得到了目标容器的系统调用名单。因此在一种实施方式中，记录目标容器中所有进程或部分指定进程的系统调用信息，包括：在目标容器的测试过程中，记录目标容器中所有进程或部分指定进程的系统调用信息。
61.在本实施例中，为了记录目标进程的系统调用信息，一般在进程申请系统调用时进行记录，而为了明确当前发生的系统调用是哪个进程发起的，可以将当前发生的系统调用和发起的进程id对应记录，例如：以进程id作为key值，以系统调用信息作为value值，将当前发生的系统调用记录成一个键值对。因此在一种实施方式中，记录目标容器中所有进程或部分指定进程的系统调用信息，包括：若系统内核中当前运行的任一进程为目标容器中需记录系统调用信息的进程，则将该进程的进程id和相应的系统调用信息成对记录。
62.由于一个容器中可能有很多进程，而可能不是所有进程的系统调用都需要记录，因此存在如下两种情况。情况一：若目标容器中的所有进程的系统调用都需要记录，那么在确定进行系统调用的进程属于目标容器时，就记录该进程的系统调用信息。情况二：若仅需要记录目标容器中个别进程的系统调用信息，那么不仅要判断进行系统调用的进程是否属于目标容器，还要判断进行系统调用的进程是否是目标容器中需要记录系统调用的进程，如果都满足，就记录相应进程的系统调用信息。在一种实施方式中，记录目标容器中所有进程或部分指定进程的系统调用信息，包括：若系统内核中当前运行的任一进程的进程挂载目录属于目标容器，且该进程携带有第二标签，则确定该进程为目标容器中需记录系统调用信息的进程。此时目标容器中携带有第二标签的进程是需记录系统调用信息的进程，故对应上述情况二。
63.可见，本实施例在云系统中的每个节点上都部署一个记录器，该记录器能够确定携带有第一标签的目标容器，记录目标容器中所有进程或部分指定进程的系统调用信息。如此该记录器就可以记录目标容器中所有进程或部分指定进程的系统调用信息，整个过程以容器为单位自动化进行，技术难度低，因此能够快速确定应用程序的系统调用名单，且借助测试流程最终确定的程序系统调用名单比较完整。
64.下面对本技术实施例提供的一种检测方法进行介绍，下文描述的一种检测方法与上文描述的一种记录器以及一种记录方法可以相互参照。
65.本技术实施例公开了一种检测方法，包括：利用上述实施例所述的记录器、记录得到的目标容器中所有进程或部分指定进程的系统调用信息，检测目标容器运行过程中的系
统调用。该检测方法可以运行于云系统中的任意节点。
66.其中，该记录器为软件组件、且部署于云系统中的每个节点，包括：确定模块，用于确定携带有第一标签的目标容器；记录模块，用于记录目标容器中所有进程或部分指定进程的系统调用信息。
67.在一种实施方式中，记录模块具体用于：在目标容器的测试过程中，记录目标容器中所有进程或部分指定进程的系统调用信息。
68.在一种实施方式中，记录模块具体用于：若系统内核中当前运行的任一进程为目标容器中需记录系统调用信息的进程，则将该进程的进程id和相应的系统调用信息成对记录。例如：以进程id作为key值，以系统调用信息作为value值，将当前发生的系统调用记录成一个键值对。
69.在一种实施方式中，记录模块具体用于：若系统内核中当前运行的任一进程的进程挂载目录属于目标容器，且该进程携带有第二标签，则确定该进程为目标容器中需记录系统调用信息的进程。可见，第二标签用于标记目标容器中需要记录系统调用的进程，因此基于第二标签可判断出系统内核中当前运行的进程是否需要记录系统调用信息。
70.可见，若一个节点得到记录器记录的结果(即容器的系统调用白名单)，那么该节点就能利用此系统调用白名单检测相应容器在自身中的系统调用情况。例如：判断该容器中的各个进程在当前节点中的系统调用与白名单里记录的系统调用是否一致，不一致时告警；一致时，输出相应的提示信息。如果不一致时，可以认为存在攻击异常情况，此时可进一步分析相应进程的操作行为、所操作的文件等，以及时定位并解决问题。
71.下面对本技术实施例提供的一种云系统进行介绍，下文描述的一种云系统与上文描述的一种记录器、一种记录方法以及一种检测方法可以相互参照。
72.本技术实施例公开了一种云系统，包括：多个节点，每个节点部署有上述任一项的记录器，至少一个节点部署有管理器和筛选器，管理器和筛选器为软件组件；其中，管理器，用于将记录器记录得到的目标容器中所有进程或部分指定进程的系统调用信息，分发至云系统中的每个节点；筛选器，用于为目标容器添加第一标签。
73.其中，筛选器可以为目标容器中的任意进程添加第二标签。
74.其中，管理器和筛选器是云系统中的软件服务，可以运行在某一个节点上，也可以在多个节点备份运行，以在：要收集的容器较多时，分担压力。
75.任意节点中的记录器能够实现如下功能：在目标容器的测试过程中，记录目标容器中所有进程或部分指定进程的系统调用信息；在确定某一节点的系统内核中运行的任一进程为目标容器中需记录系统调用信息的进程时，将该进程的进程id和相应的系统调用信息成对记录；在节点系统内核中当前运行的任一进程的进程挂载目录属于目标容器，且该进程携带有第二标签时，确定该进程为目标容器中需记录系统调用信息的进程。
76.当然，本实施例中的记录器也可以看作下文所述的ebpf controller组件，管理器可以看作下文所述的manager组件，筛选器可以看作下文所述的webhook controller组件。关于本实施例中各个组件更加具体的工作过程可以参考其他实施例中公开的相应内容，在此不再进行赘述。
77.下面对本技术实施例提供的一种检测装置进行介绍，下文描述的一种检测装置与上文描述的一种记录器、一种记录方法以及一种检测方法可以相互参照。
78.本技术实施例公开了一种检测装置，包括：检测单元，用于利用上述任一实施例所述的记录器、记录得到的目标容器中所有进程或部分指定进程的系统调用信息，检测目标容器运行过程中的系统调用。
79.若一个节点得到记录器记录的结果(即容器的系统调用白名单)，那么该节点利用检测装置就能利用此系统调用白名单检测相应容器在自身中的系统调用情况。例如：利用检测装置判断该容器中的各个进程在当前节点中的系统调用与白名单里记录的系统调用是否一致，不一致时告警；一致时，输出相应的提示信息。如果不一致时，可以认为存在攻击异常情况，此时可进一步分析相应进程的操作行为、所操作的文件等，以及时定位并解决问题。当然，检测方法和检测装置也可以实现其他相应信息的检测。
80.下面对本技术实施例提供的一种系统调用信息记录方法进行介绍，下文描述的一种系统调用信息记录方法与上文描述的一种记录器、一种记录方法、一种检测方法及检测装置可以相互参照。
81.参见图3所示，本技术实施例公开了一种系统调用信息记录方法，应用于云系统中的任一节点，包括：
82.s301、在目标容器的测试过程中，记录目标容器中目标进程的系统调用信息。
83.在本实施例中，为了记录目标进程的系统调用信息，一般在进程申请系统调用时进行记录，而为了明确当前发生的系统调用是哪个进程发起的，可以将当前发生的系统调用和发起的进程id对应记录，例如：以进程id作为key值，以系统调用信息作为value值，将当前发生的系统调用记录成一个键值对。在一种实施方式中，记录目标容器中目标进程的系统调用信息，包括：若目标进程发起系统调用，则将目标进程的进程id和相应的系统调用信息成对记录。其中，可以利用键值对实现成对记录。
84.由于目标容器中可能有很多进程，而当前系统也需要很多进程支持其运行，所以当前系统中可能有很多进程都需要进行系统调用，这些进程有的属于目标容器，有的不属于目标容器。因此，为了明确哪些进程的系统调用信息需要记录，哪些不需要记录，可以区分以下两种情况进行设计。情况一：若目标容器中的所有进程的系统调用都需要记录，那么判断进行系统调用的进程是否属于目标容器即可，只要确定进行系统调用的进程属于目标容器，就记录相应进程的系统调用信息。情况二：若仅需要记录目标容器中个别进程的系统调用信息，那么不仅要判断进行系统调用的进程是否属于目标容器，还要判断进行系统调用的进程是否是目标容器中需要记录系统调用的进程，如果都满足，就记录相应进程的系统调用信息。
85.在一种实施方式中，情况一对应的具体实现步骤可以包括：在系统内核中有进程运行时，记录系统内核中当前运行的任一进程的进程id和进程挂载目录；若基于进程挂载目录确定当前运行的该进程属于目标容器，则将当前运行的该进程确定为目标进程，并执行若目标进程发起系统调用，则将目标进程的进程id和相应的系统调用信息成对记录的步骤。其中，基于进程挂载目录可以看出进程是否属于目标容器所在目录，由此即可判断出系统内核中当前运行的进程是否属于目标容器。系统内核指：某一节点的系统内核。
86.在一种实施方式中，情况二对应的具体实现步骤可以包括：在系统内核中有进程运行时，记录系统内核中当前运行的任一进程的进程id和进程挂载目录；若当前运行的该进程携带有第二标签、且基于进程挂载目录确定当前运行的该进程属于目标容器，则将当
前运行的该进程确定为目标进程，并执行若目标进程发起系统调用，则将目标进程的进程id和相应的系统调用信息成对记录的步骤。其中，第二标签用于标记目标容器中需要记录系统调用的进程，因此基于第二标签可判断出系统内核中当前运行的进程是否需要记录系统调用信息。
87.需要说明的是，一个进程需要的系统调用可能有至少一个，因此一个进程的系统调用信息一般以列表的形式记录。
88.s302、待目标容器测试完成，汇总测试过程中记录的各个目标进程的系统调用信息，得到目标容器的系统调用名单。
89.其中，各个目标进程为：目标容器中的所有进程或部分指定进程。由于目标容器在上线之前需要进行测试，而测试目标容器会无一遗漏地测试该容器的全部功能，那么目标容器需要的系统调用就会无一遗漏地在测试过程中发生。因此在测试目标容器时，记录该目标容器中所有进程或部分指定进程的系统调用信息，那么待目标容器测试完成后，汇总测试过程中记录的所有系统调用信息，既完成了目标容器的测试，又得到了目标容器的系统调用名单。
90.由于一个进程的系统调用信息一般以列表的形式记录，那么汇总不同进程的系统调用信息时，汇总这些进程的系统调用列表即可，当然在汇总的结果中，需要以进程id区分不同进程的系统调用信息。在一种示例中，可以将目标容器中需要记录系统调用的进程记录为一个进程名单，那么在汇总时，基于该进程名单确定是否有遗漏或重复信息。因此在一种实施方式中，汇总测试过程中记录的各个目标进程的系统调用信息，包括：基于目标容器中需收集系统调用信息的进程名单，合并各个目标进程的系统调用信息。该进程名单在容器测试的过程中记录得到。
91.需要说明的是，当前节点中可能部署有很多容器，而并非所有容器都需要进行系统调用的记录，因此可以对需要进行系统调用记录的容器进行标记。因此在一种实施方式中，还包括：在测试目标容器之前，若确定目标容器携带有第一标签，则执行在目标容器的测试过程中，记录目标容器中目标进程的系统调用信息；待目标容器测试完成，汇总测试过程中记录的各个目标进程的系统调用信息，得到目标容器的系统调用名单的步骤。
92.其中，当前节点可以是云系统中的一个服务器节点，而一个容器可能因负载均衡等原因在不同节点上运行，因此在一种实施方式中，可以将目标容器的系统调用名单分发至云系统中的其他节点，以使各节点基于系统调用名单运行目标容器。
93.可见，本实施例无需特意运行程序来确定其系统调用名单，且整个过程自动化进行，技术难度低，因此能够快速确定容器的系统调用名单。并且，由于程序一般是全面测试，因此借助测试流程最终确定的程序系统调用名单比较完整。
94.下述实施例以容器应用为例，进一步介绍本技术。本实施例的核心思想是：在对容器应用进行集成测试时，开启seccomp profile(容器系统调用信息白名单)生成任务，从而通过测试流程充分激发容器的系统调用行为，以保证采集到的容器syscall的完整性。也即：将seccomp profile的生成融入测试流程一并完成。
95.为实现本实施例，需要设计以下组件：manager组件、webhook controller组件、ebpf controller组件。其中，manager组件负责上报seccomp profile生成任务，并对seccomp profile生成任务进行监控。webhook controller组件负责筛选需要记录系统调
用名单的容器应用，并对选中的容器应用添加seccomp profile生成任务标签(即第一标签)。ebpf controller组件负责对带有seccomp profile生成任务标签的容器进行seccomp profile录制。
96.具体的，可以借助ebpf(extended berkeley packet filter)实现进程系统调用等信息的收集，ebpf是linux内核中一个非常灵活与高效的类虚拟机组件，能够在许多内核hook点安全地执行字节码。因此借助ebpf能够hook内核中发生的系统调用等。具体的，ebpf controller组件即借助ebpf实现的组件，能够实时收集系统内核运行的进程pid，pid对应使用的syscall，pid对应的执行命令(command line)，以及进程对应的挂载目录，将这些信息保存在自定义的bpf映射结构体中。当每次内核中发生进程运行事件，该进程的上述信息都能被ebpf controller收集到。
97.容器测试完成后，ebpf controller可以收集得到容器id对应的进程列表，利用该列表对照前述记录的bpf映射结构体，就得到了容器对应的seccomp profile。假设容器中的所有进程的系统调用都需要被记录。整个过程均为代码实现，即：seccomp profile生成是自动进行的，只需要为容器绑定seccomp profile任务标签，即可通过webhook controller组件开启seccomp profile生成任务。
98.在一种示例中，seccomp profile生成任务的创建至执行完成的整个过程可以参照图4。
99.如图4所示，该过程包括以下实现步骤：
100.1、开发者向云服务中心申请创建一个带有ebpf标签的云应用，webhook controller会对该云应用进行筛选，如果发现其带有ebpf标签，则为该云应用增加seccomp profile标签(即第二标签)。其中，ebpf标签用于标记：相应云应用在测试的同时，收集其系统调用名单。云应用以至少一个容器的形式运行。为一个云应用添加标签后，其中的各个容器也有该标签。
101.2、ebpf controller检查云应用是否带有seccomp profile标签，如果该云应用带有seccomp profile标签，则针对云应用中的各个容器开始进行执行任务，此时会生成seccomp profile的名称，并保存进profile列表。
102.3、ebpf controller组件在云系统的每个节点都有一个副本，从而使带有seccomp profile标签的应用被分配至任意节点进行测试时，都能在测试流程中完成系统调用名单的收集。当任一节点第一次进行profile录制时，ebpf controller会加载bpf对象文件(ebpf controller所属的文件)至linux内核，同时开启事件监听，此时内核中的进程事件就会源源不断地从linux内核发送到ebpf controller中。ebpf controller持续更新容器对应的pid列表。pid对应的syscall列表保存在bpf映射结构体中，该结构体在内核中持续更新。
103.4、当云应用测试完成后，删除测试环境中的云应用。当有删除云应用操作时，ebpf controller组件会查找该云应用是否匹配seccomp profile，如果匹配上标签，则对该云应用进行syscall收集整理，得到最终的syscall列表。具体的，ebpf controller通过云应用中的容器id，可以得到每个容器测试过程中记录的进程id列表。据此列表对照bpf映射结构体，即可确定一个容器测试过程中涉及的系统调用列表。在bpf映射结构体中，一个容器包括的每个进程id对应有一个syscall列表。也即：一个进程对应一组系统调用信息，而汇总
容器中所有进程的系统调用信息，就能得到该容器的系统调用信息。由此，即可得到云应用中的每个容器的系统调用信息白名单。
104.5、为使测试通过的云应用能够在各个节点上正常运行，manager组件会检查集群(即云系统)seccomp profile状态，当发现一个新增的seccomp profile，会将该seccomp profile分发到集群的每个节点，这样云应用实例在集群的每个节点上，都可以使用相应的seccomp profile。
105.6、使云应用指定挂载已经生成的seccomp profile，以实现seccomp的安全加固，从而保证云原生应用系统调用层面的安全。
106.在图4所示的流程中，ebpf controller具体通过以下步骤完成信息收集，具体请参见图5。如图5所示，ebpf controller中的具体实现步骤可以包括：每次进程向linux内核发起系统调用申请时，bpf程序会通过相应程序附加执行点，对此时发起系统调用的进程进行信息记录，并且将信息保存在bpf map(bpf映射结构体)中。具体的，ebpf controller将ebpf对象文件加载到linux内核，得到bpf程序，bpf程序通过程序附加点附加到linux内核中。bpf程序主要记录的信息有进程pid、pid对应的进程执行命令、pid对应的syscall id、pid对应的挂载目录，这几种信息都会记录到bpf map中。
107.在往bpf map中记录信息时，如果当前执行的进程信息已经记录在bpf map中，只需要根据情况更新相应的信息即可。如果当前进程没有记录在bpf map中，需要在bpf map中增加一条键值对，并且将新pid信息通过环形缓冲区以事件的形式上报给ebpf controller，ebpf controller将上报的信息保存在用户空间的map中。当内核中有新增pid事件发送过来，ebpf controller更新容器对应的pid列表。当容器测试结束时，ebpf controller通过pid对应syscall列表和容器对应的pid列表生成seccomp profile。
108.可见，本技术生成seccomp profile的整个过程自动化进行，提高了生成效率。在容器测试过程中使用ebpf技术直接通过linux内核层面采集进程对应的syscall，可以保证容器syscall序列的完整性。这种方式可以很好地与devops敏捷开发流程结合使用，在自动化流程中加入相应的seccomp profile标签即可。也可以很好地适配云原生应用。使用人员不需要了解内核技术，降低了seccomp防护门槛。
109.下面对本技术实施例提供的一种电子设备进行介绍，下文描述的一种电子设备与上文描述的相应方法及装置可以相互参照。
110.参见图6所示，本技术实施例公开了一种电子设备，包括：
111.存储器601，用于保存计算机程序；
112.处理器602，用于执行所述计算机程序，以实现上述任意实施例公开的方法。
113.请参考图7，图7为本实施例提供的另一种电子设备示意图，该电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processing units，cpu)322(例如，一个或一个以上处理器)和存储器332，一个或一个以上存储应用程序342或数据344的存储介质330(例如一个或一个以上海量存储设备)。其中，存储器332和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对数据处理设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储介质330通信，在电子设备301上执行存储介质330中的一系列指令操作。
114.电子设备301还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341。例如，windows servertm，mac os xtm，unixtm，linuxtm，freebsdtm等。
115.在图7中，应用程序342可以是执行前述实施例提供的方法的程序，数据344可以是执行前述实施例提供的方法所需的或产生的数据。
116.上文所描述的相应方法中的步骤可以由电子设备的结构实现。
117.下面对本技术实施例提供的一种可读存储介质进行介绍，下文描述的一种可读存储介质与上文描述的相应方法、装置及设备可以相互参照。
118.一种可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。
119.下面对本技术实施例提供的一种计算机程序产品进行介绍，下文描述的一种计算机程序产品与上文描述的相应方法、装置及设备可以相互参照。
120.一种计算机程序产品，包括计算机指令，当计算机指令在计算机上运行时，使得计算机可以执行前述公开的方法。
121.本技术涉及的“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法或设备固有的其它步骤或单元。
122.需要说明的是，在本技术中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本技术要求的保护范围之内。
123.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。
124.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的可读存储介质中。
125.本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本技术的方法及其核心思想；同时，对于本领域的一般技术人员，依据本技术的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本技术的限制。