问脉答记者问：为什么我们需要一套插件系统

故事是这样开始的\r

\r

## 1\r

\r

当我们开发一个容器安全工具时，我们自然希望在各种场景中复用这个工具。 \r

\r

例如：我们编写了一个图像后门扫描工具，希望在以下场景中使用它：\r

\r

1.本地扫描：当我们直接执行该工具时，它可以扫描本地图像，并输出图像中后门的检测结果；\r

\r

2、操作授权：我们可以编写一个Docker授权插件，自动执行工具来检测镜像后门，在拉取镜像、启动容器时拦截危险操作；\r

\r

3、远程扫描：我们希望通过该工具对远程仓库中的镜像进行扫描，帮助我们发现存在后门的镜像，为后续的修复、溯源等操作提供支持。 \r

\r

除此之外，我们还可以想到很多其他的使用场景，比如集成到CI/CD流程中进行扫描。但我们不妨以上述场景作为典型例子来开始讨论。 \r

\r

## 2\r

\r

一般情况下，为了方便开发和调试，我们开发的安全工具都会首先支持本地扫描功能。事实上，我们大多数时候都“超额实现”了这个目标：\r

\r

我们会花很多时间来装饰这个工具的输出函数。也许这个工具的一半代码都花在优化输出功能上，比如命令行颜色匹配、输出格式化和各种报告生成。这会增加可能优化的工作量。 \r

\r

##三\r

\r

**首先我们需要思考如何支持操作授权。 **\r

\r

显然，我们可以在镜像后门扫描工具的基础上添加一个子命令，并将其封装为Docker授权插件，但这需要处理很多复杂的细节。 \r

\r

因此，我们希望有一个开源的Docker授权插件项目，将我们的工具作为子进程调用，并根据工具的检测结果来决定是否阻止用户操作。如果有这样的Docker授权插件（或者如果不存在，我们可以自己制作一个），肯定会减少我们的工作量很多。 \r

\r

在我们开始通过互联网寻找或编写这样的Docker授权插件之前，我们不妨思考一个问题：它应该如何获取我们的检测结果？ \r

\r

\r

\r

**首先考虑解决方案，而不对工具本身进行任何修改**。 \r

\r

我们是否可以直接读取工具的输出和报告，并使用正则表达式来匹配检测结果？不管使用正则表达式可能会导致不匹配，但可以相信的一件事是，如果允许不同的安全工具作者自由地玩弄输出结果，一千个工具可能有一千种输出模式。因此，为了生成基于正则匹配的通用解决方案，工具作者只能提供与他的工具的输出匹配的正则表达式（我怀疑你在玩套娃），这违背了讨论这个问题的初衷。 \r

\r

**如果允许对工具本身进行一些修改，有哪些可行的解决方案？ **\r

\r

由于我们依赖子进程来执行工具，因此最简单的方法之一就是确定命令的退出状态代码。 \r

\r

例如：当状态码为0时，认为本次检查没有发现威胁，否则认为发现威胁并予以阻止。这确实是一个可行且易于接受的解决方案，但仍然存在一些问题。 \r

\r

## 四\r

\r

首先，状态码常用来表示程序是否执行成功并退出。那么当一个工具执行失败并返回非零状态码时（事实上，很多语言的标准库在遇到运行时异常时都会直接以非零状态码终止当前进程。大多数情况下，进程何时终止以及以什么状态码终止，并不在用户的控制之下。），是否意味着用户操作应该默认被阻止？ \r

\r

一些用户认为，所有安全工具都应该正常执行，报告没有威胁，才允许用户进行下一步，以确保不会遗漏任何安全问题；一些用户认为，尚处于试用阶段的安全工具的结果如果不能正常工作就应该被忽略（例如，当我在试用一个安全工具时，当运行过程中不断报错并返回非零状态码时，我想忽略它而不是影响我的其他操作）。他们只需要确保生产阶段的安全工具正常工作即可。 \r

\r

因此，一刀切处理非零状态码不一定能满足所有用户的需求。 \r

\r

其次，当发生阻塞时，我们往往希望向用户呈现完整的阻塞原因（比如哪个路径发现了哪个后门、哪个软件资产存在哪个重大漏洞），但子进程的状态码中并不包含这些信息。而如果此类工具没有其他渠道来报告具体的检测结果，我们只能尝试解析该工具的输出或报告（等等，为什么听起来这么熟悉），并重复我们之前认为与初衷相悖的旧正则匹配路径。 \r

\r

因此，如果想要以合理且可维护的方式向上述Docker授权插件提供检测结果，该工具应该以预定义的格式输出计算机可读的检测结果，供Docker授权插件解析和处理。 \r

\r

## 五\r

\r

**接下来我们想一下如何支持远程扫描。 **\r

\r

我们希望我们编写的工具能够提供一个子命令来接收远程仓库的URL及其身份验证信息。该子命令只需将对应的镜像tar包下载到本地并执行原始扫描代码即可。 \r

\r

当只需要执行一个安全工具时，这种想法很常见，但更多时候我们会担心一个威胁，因此需要同时执行多个检测工具。这种情况下，如果各个工具在使用时独立从远程下载镜像，除了会因重复下载镜像tar文件（注意镜像中一层的大小往往在几百MB量级）而占用大量网络带宽、因重复扫描导致效率低下外，一些公共仓库如Docker Hub还存在下载频率限制。 \r

\r

如果你不是Docker Hub 的付费用户，每个IP 每6 小时100 次拉取的限制确实是一个糟糕的体验（不要问我怎么知道的）\r

\r

我们想到了一个简单可行的解决方案：在执行各个工具之前，先将需要扫描的镜像下载到本地（无论是直接下载tar还是使用Pull命令），然后执行各个工具进行扫描，扫描完成之后再删除镜像以释放资源。 \r

\r

您是否注意到，这将远程仓库的扫描转换为本地扫描？扫描时，只需为每个工具指定下载的镜像，而不需要让工具知道远程仓库当前是否正在扫描。 \r

\r

这意味着即使该工具仅支持本地扫描，也可以在远程扫描场景中复用。 \r

\r

同时，为了使用方便，我们经常会编写一个远程扫描入口程序来接收扫描指令并相应完成镜像下载、工具调用和镜像卸载。 （听起来好像有框架）\r

\r

除了操作授权和远程扫描之外，我们还可以讨论很多其他使用场景的实现细节，而且我们总能发现，在新的场景下，工具总是需要进行或多或少的调整才能完美满足需求。事实上，使用场景的多样性以及它们之间的巨大差异使得在工具或SDK中堆积代码成为一项不可能完成的任务。 （有没有想过某个表情？）\r

\r

因此，我们会想办法通过抽象、适配等手段，将新的场景处理成已知的场景（比如远程扫描时扫描远程仓库而不是扫描本地仓库），从而达到在不同使用场景下复用现有工具的初衷。 \r

\r

## 六\r

\r

至此，插件系统的想法即将浮现：如上面提到的Docker授权插件和远程扫描的入口程序。我们将这样的程序称为宿主程序。他们负责处理每个使用场景的具体细节，并将其转化为针对容器、镜像等特定实体的扫描问题。相比之下，诸如上面提到的镜像后门扫描工具和镜像漏洞扫描工具，我们将此类程序称为插件。他们可以扫描特定实体（例如容器和图像）并发现其中的安全问题。 \r

\r

\r

\r

如上图所示，当用户对镜像或容器有安全检测需求时，只需向Host发送命令，告知Host具体扫描对象即可。 Host会枚举当前Plugins List中的插件Plugin B和C，依次调用B和C扫描指定对象，获取扫描结果输出给用户。 \r

\r

因此，宿主程序和插件是一对多的关系。在实际使用中，我们只需要先配置具体的主机程序，然后根据我们关心的安全问题插入和删除安全插件，最终得到我们期望的聚合检测结果。 \r

\r

\r

\r

**宿主进程和插件之间是否存在简单的单向父子进程调用关系？ **\r

\r

答案是否定的。上一篇讨论如何支持操作授权时，宿主进程需要收集插件输出的检测结果并进行处理，生成操作授权响应。在本文未讨论的场景中，还存在其他需要收集检测结果并进行定制处理的需求，例如生成检测报告文件、生成Syslog并转发到SIEM等。同样，对于插件的日志输出，您会希望支持收集、过滤等操作，以支持不同场景下的日志持久化、工具调试、界面展示等需求。 \r

\r

为了处理这些需要定制的插件生成的数据，我们需要打开插件到宿主进程的双向连接，并通过宿主进程向插件提供服务（Service），接受并处理插件生成的数据，还可以在插件中执行获取、修改某些系统配置项等各种操作。 \r

\r

## 七\r

\r

在闻麦SDK中，除了为容器安全相关实体设计了相应的API外，我们还设计并实现了插件系统。 （这就是我们上面讨论的方案）基于插件系统编写的安全工具只需要编写一次并在本地扫描场景中进行验证，然后就可以集成到不同使用场景的宿主程序中进行复用；同样，对于新的使用场景，只需要基于插件系统编写新的宿主程序，已经编写好的现有插件就可以复用。 \r

\r

去试试吧：【Chaitin工具】(https://stack.chaitin.com/tool/detail?id=3)、【libVeinMind: Chaitin容器感知与安全SDK】(https://github.com/chaitin/libveinmind)\r

\r

敬请期待，你会看到故事是这样继续的：基于vevemind系列如何编写插件详解.