CN109542590B - Docker集群多租户下虚拟Socket通信的方法 - Google Patents

Abstract

本发明公开了一种Docker集群多租户下虚拟Socket通信的方法和系统，使容器内进程可调用Docker服务，允许对租户在Swarm集群范围内的所有资源进行操作，实现数据隔离，调用者无需身份认证，无需改造容器应用。其技术方案为：在多租户共享主机场景下，租户容器通过虚拟Docker Socket不能访问其他租户的容器，也无法通过创建特权容器等方式来实现特权提升，从而保证系统安全和租户数据安全。虚拟Docker Socket支持与Docker API兼容的Docker Swarm API，容器可通过在镜像内安装Docker CLI，以Shell脚本形式通过虚拟Docker Socket调用Docker/Docker Swarm服务。代理服务自动识别调用来源容器及所属租户，简化调用代码编写，并避免显示传入认证信息导致有泄漏的安全风险。

Description

Docker集群多租户下虚拟Socket通信的方法

技术领域

本发明涉及Docker Swarm集群中实现的技术，具体涉及Docker Swarm集群多租户场景下的虚拟Docker Socket跨主机通信方法和系统。

背景技术

在多租户共享Docker主机的情况下，容器管理平台通常禁止容器挂载DockerSocket后向主机上的Docker服务发送请求，因为这会导致租户越权访问到同主机上其他租户的容器，甚至获得主机系统操作权限。但目前大量容器需要调用Docker服务来实现服务发现等功能，禁止容器挂载Docker Socket后，此类容器就需要进行改造以使用容器管理平台提供的私有API作为替代，从而又带来厂商锁定等新问题。

公有云平台通常采用虚拟机来实现多租户隔离，此时容器挂载Docker Socket虽然没有越权的问题，但由于通过Docker Socket只能访问到当前主机上的Docker服务，无法对集群内其他主机上的容器进行操作。

举一个具体的例子，某容器应用集成了一个负载均衡组件(例如Nginx容器)来对多个服务容器做反向代理和负载均衡，该负载均衡组件的实现逻辑如下：

以Nginx镜像为基础，添加一个服务发现脚本作为容器入口。容器启动后，该脚本通过挂载真实的Docker Socket调用Docker服务获取当前主机上所有服务容器(根据指定标签过滤)，然后生成对应Nginx配置后启动或重启Nginx。

然而，该负载均衡组件使用真实Docker Socket会存在以下限制或问题：

不同租户不能同时部署这个应用，因为通过真实的Docker Socket获取到的是主机上所有容器，即可能获取到其他租户运行在该主机的服务容器，导致负载均衡功能错乱；

服务容器只能和负载均衡组件运行在同一主机上，导致不具备水平扩展性和存在单点故障；

负载均衡组件一旦感染恶意程序，恶意程序可以借由Docker服务进行特权提升，获取主机系统的root权限。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种Docker集群多租户下虚拟Socket通信的方法和系统，使容器内进程可以通过虚拟Docker Socket调用Docker服务，允许对租户在Swarm集群范围内的所有容器、存储卷、网络等资源进行操作，能够自动感知读写虚拟Docker Socket的进程的所属租户来实现数据隔离，调用者无需身份认证，无需改造容器应用。

本发明的技术方案为：本发明揭示了一种Docker集群多租户下虚拟Socket通信的系统，包括Docker Swarm管理器、多个Docker Swarm节点以及一计算机程序，所述计算机程序运行后执行以下的步骤：

步骤1：虚拟Docker Socket技术在Docker Swarm节点上运行代理服务；

步骤2：由该代理服务创建虚拟Docker Socket文件以替换真实Docker Socket文件；

步骤3：Docker Swarm节点中的容器通过挂载的虚拟Docker Socket文件与代理服务通信，向代理服务发送Docker Swarm API调用；

步骤4：该代理服务获取调用端系统凭据及进程ID，识别调用来源对应的容器，将容器ID加入到HTTP请求头中，并代理请求到Docker Swarm管理器中的容器管理平台的Docker Swarm API访问端点；

步骤5：该代理服务通过API调用获取容器对应的租户及该租户下的所有容器列表；

步骤6：该代理服务通过某一应用服务的名称或标签获取到该应用服务下的容器列表。

根据本发明的Docker Swarm集群多租户下虚拟Docker Socket通信的系统的一实施例，所述计算机程序运行的步骤还包括步骤6之后的：

步骤7：当容器里需要创建一个容器或应用时，该代理服务创建容器的API请求到容器管理平台，再由容器管理平台调度容器创建任务到某一Docker Swarm节点上的节点代理chiwen-agent组件上，由该节点代理chiwen-agent组件调用Docker API来创建容器。

本发明还揭示了一种Docker集群多租户下虚拟Socket通信的方法，包括：

步骤1：虚拟Docker Socket技术在Docker Swarm节点上运行代理服务；

步骤2：由该代理服务创建虚拟Docker Socket文件以替换真实Docker Socket文件；

步骤3：Docker Swarm节点中的容器通过挂载的虚拟Docker Socket文件与代理服务通信，向代理服务发送Docker Swarm API调用；

步骤4：该代理服务获取调用端系统凭据及进程ID，识别调用来源对应的容器，将容器ID加入到HTTP请求头中，并代理请求到Docker Swarm管理器中的容器管理平台的Docker Swarm API访问端点；

步骤5：该代理服务通过API调用获取容器对应的租户及该租户下的所有容器列表；

步骤6：该代理服务通过某一应用服务的名称或标签获取到该应用服务下的容器列表。

根据本发明的Docker集群多租户下虚拟Socket通信的方法的一实施例，方法还包括步骤6之后的：

步骤7：当容器里需要创建一个容器或应用时，该代理服务创建容器的API请求到容器管理平台，再由容器管理平台调度容器创建任务到某一Docker Swarm节点上的节点代理chiwen-agent组件上，由该节点代理chiwen-agent组件调用Docker API来创建容器。

本发明还揭示了一种计算机可读存储介质，所述存储介质上存储有计算机程序，计算机程序运行后执行如上所述的方法。

本发明对比现有技术有如下的有益效果：本发明在多租户共享主机场景下，租户容器通过虚拟Docker Socket不能访问其他租户的容器，也无法通过创建特权容器等方式来实现特权提升，从而保证系统安全和租户数据安全。本发明的虚拟Docker Socket支持与Docker API兼容的Docker Swarm API，容器可以通过在镜像内安装Docker CLI，以Shell脚本的形式通过虚拟Docker Socket调用Docker/Docker Swarm服务，这与目前主流容器调用Docker服务的方式一致。此外，本发明自动感知读写虚拟Docker Socket的进程的所属租户来实现数据隔离，调用者无需身份认证，无需改造容器应用。本发明的代理服务自动识别调用来源容器及所属租户，大大简化调用代码编写，并避免显示传入认证信息导致有泄漏的安全风险。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的Docker集群多租户下虚拟Socket通信的系统的实施例的原理图。

图2示出了本发明的Docker集群多租户下虚拟Socket通信的方法的实施例的流程图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1示出了本发明的Docker集群多租户下虚拟Socket通信的系统的实施例的原理。请参见图1，本实施例的系统包括：Docker Swarm管理器(Docker Swarm Manager)、多个Docker Swarm节点(Docker Swarm Node)以及一计算机程序。计算机程序运行后执行以下的步骤(流程如图2所示)。

步骤S1：虚拟Docker Socket技术在主机上(Docker Swarm Node)运行代理服务(图示的①，chiwen-sock)。

步骤S2：由该代理服务创建虚拟Docker Socket文件(图示的②，Virtual DockerSocket)替换真实Docker Socket文件。由于该主机上的容器只能访问虚拟Docker Socket，而不能访问其他租户的容器，也无法通过创建特权容器等方式来实现特权提升，所以实现了系统的安全和租户的数据安全。

步骤S3：容器(图示的Container)通过挂载的虚拟Docker Socket文件与代理服务通信(图示的③)，向代理服务发送Docker Swarm API调用(图示的④)。

步骤S4：该代理服务通过getsockopt系统调用获取调用端(容器内部进程)的系统凭据(UNIX credential)及进程ID，从而识别调用来自哪个容器，将容器ID加入到HTTP请求头中，并代理请求到Docker Swarm管理器中的容器管理平台(图示的chiwen)的DockerSwarm API访问端点(图示的⑤)。最终由容器管理平台的Docker Swarm API进行处理并返回到容器内部的调用程序，与原生调用Docker API的方式一致，因此整个调用过程完全兼容Docker API及Docker Swarm API。

步骤S5：该代理服务通过API调用，获取容器对应的租户及该租户下的所有容器列表(图示的⑥)。由于是自动识别调用来源容器及所属租户，所以无需进行身份认证，避免显示的传入认证信息而导致安全风险。

步骤S6：该代理服务通过某一应用服务的名称或标签(Label)获取到该应用服务下的容器列表(图示的⑦)。

步骤S7：当容器里需要创建一个容器或应用时，该代理服务创建容器的API请求到容器管理平台(图示的chiwen)，再由容器管理平台调度容器创建任务到某一Docker Swarm节点上的节点代理(chiwen-agent)组件上(图示的⑧)，由chiwen-agent组件调用DockerAPI来创建容器。

上述经多租户改造的Docker Swarm服务就能够根据HTTP请求头上的租户ID信息来实现租户间数据访问控制，并拒绝越权操作请求。

以背景技术部分提到的例子为例来说明使用虚拟Docker Socket后就不存在背景技术中指出的限制或问题：

负载均衡组件仅能获取及操作同租户内的容器，不能看到或操作其他租户的容器；

服务容器可以运行在Docker Swarm集群管理的任一主机

恶意程序无法通过虚拟Docker Socket执行越权操作。

此外，本发明还公开了一种Docker集群多租户下虚拟Socket通信的方法的实施例，实施方法的步骤如图2所示，且在上述描述系统的内容中已经加以阐释，此处就不加赘述。

本发明还公开了一种计算机可读存储介质，存储介质上存储有计算机程序，计算机程序运行后执行如图2所示的方法，且在上述描述系统的内容中已经加以阐释，此处就不加赘述。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (3)

1.一种Docker集群多租户下虚拟Socket通信的系统，其特征在于，包括Docker Swarm管理器、多个Docker Swarm节点以及一计算机程序，所述计算机程序运行后执行以下的步骤：

步骤1：虚拟Docker Socket技术在Docker Swarm节点上运行代理服务；

步骤2：由该代理服务创建虚拟Docker Socket文件以替换真实Docker Socket文件；

步骤3：Docker Swarm节点中的容器通过挂载的虚拟Docker Socket文件与代理服务通信，向代理服务发送Docker Swarm API调用；

步骤4：该代理服务获取调用端系统凭据及进程ID，识别调用来源对应的容器，将容器ID加入到HTTP请求头中，并代理请求到Docker Swarm管理器中的容器管理平台的DockerSwarm API访问端点；

步骤5：该代理服务通过API调用获取容器对应的租户及该租户下的所有容器列表；

步骤6：该代理服务通过某一应用服务的名称或标签获取到该应用服务下的容器列表；

步骤7：当容器里需要创建一个容器或应用时，该代理服务创建容器的API请求到容器管理平台，再由容器管理平台调度容器创建任务到某一Docker Swarm节点上的节点代理chiwen-agent组件上，由该节点代理chiwen-agent组件调用Docker API来创建容器。

2.一种Docker集群多租户下虚拟Socket通信的方法，其特征在于，包括：

步骤1：虚拟Docker Socket技术在Docker Swarm节点上运行代理服务；

步骤2：由该代理服务创建虚拟Docker Socket文件以替换真实Docker Socket文件；

步骤3：Docker Swarm节点中的容器通过挂载的虚拟Docker Socket文件与代理服务通信，向代理服务发送Docker Swarm API调用；

步骤4：该代理服务获取调用端系统凭据及进程ID，识别调用来源对应的容器，将容器ID加入到HTTP请求头中，并代理请求到Docker Swarm管理器中的容器管理平台的DockerSwarm API访问端点；

步骤5：该代理服务通过API调用获取容器对应的租户及该租户下的所有容器列表；

步骤6：该代理服务通过某一应用服务的名称或标签获取到该应用服务下的容器列表；

步骤7：当容器里需要创建一个容器或应用时，该代理服务创建容器的API请求到容器管理平台，再由容器管理平台调度容器创建任务到某一Docker Swarm节点上的节点代理chiwen-agent组件上，由该节点代理chiwen-agent组件调用Docker API来创建容器。

3.一种计算机可读存储介质，其特征在于，所述存储介质上存储有计算机程序，计算机程序运行后执行如权利要求2所述的方法。

Images