CN114172726B - 一种基于容器环境的访问控制方法及系统 - Google Patents

Abstract

本申请实施例提供一种基于容器环境的访问控制方法及系统，涉及网络安全技术领域，该基于容器环境的访问控制方法包括：先获取源容器的源容器标识；并获取具有源容器标识的通信报文并缓存通信报文；然后确定接收通信报文的目的容器；并根据源容器标识与目的端防护产品客户端，进行基于容器标识的握手验证；当握手验证通过时，将缓存的通信报文发送至目的端防护产品客户端，以使目的端防护产品客户端将通信报文转发至目的容器，可见，该方法访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

Description

一种基于容器环境的访问控制方法及系统

技术领域

本申请涉及通信安全技术领域，具体而言，涉及一种基于容器环境的访问控制方法及系统。

背景技术

随着互联网的不断发展，虚拟化技术和云计算服务也随之发展，相应的通信安全也越来越收到重视。可以通过访问控制以控制用户对服务器、目录、文件等网络资源的访问，从而提升通信安全。现有的访问控制方法通常为基于IP地址的访问控制，依靠底层Iptables实现，需要获取明确的容器对外的IP地址，才能进行访问控制，然而在实践中发现，现有方法依赖通信网络识别IP信息进行访问控制，多层NAT转换导致识别过程复杂，地址转换之后无法实现跨计算节点的容器到容器端到端的访问控制。可见，现有方法访问控制过程复杂，且无法实现跨计算节点的容器到容器端到端的访问控制，从而导致网络安全防护性能差。

发明内容

本申请实施例的目的在于提供一种基于容器环境的访问控制方法及系统，访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

本申请实施例第一方面提供了一种基于容器环境的访问控制方法，应用于源端防护产品客户端，包括：

获取源容器的源容器标识；

获取具有所述源容器标识的通信报文并缓存所述通信报文；其中，所述源容器与所述源端防护产品客户端部署于源计算节点内；

确定接收所述通信报文的目的容器；

根据所述源容器标识与目的端防护产品客户端，进行基于容器标识的握手验证；其中，所述目的容器与所述目的端防护产品客户端部署于目的计算节点内；

当握手验证通过时，将缓存的所述通信报文发送至所述目的端防护产品客户端，以使所述目的端防护产品客户端将所述通信报文转发至所述目的容器。

在上述实现过程中，先获取源容器的源容器标识；并获取具有源容器标识的通信报文并缓存通信报文；然后确定接收通信报文的目的容器；并根据源容器标识与目的端防护产品客户端，进行基于容器标识的握手验证；当握手验证通过时，将缓存的通信报文发送至目的端防护产品客户端，以使目的端防护产品客户端将通信报文转发至目的容器，可见，该方法访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

进一步地，所述获取源容器的源容器标识，包括：

当检测到源容器的进程启动时，提取所述源容器的相关属性标签；

根据所述相关属性标签，确定所述源容器的源容器标识。

进一步地，所述获取具有所述源容器标识的通信报文并缓存所述通信报文，包括：

下发预设的进程管理策略至所述源容器对应的源端系统内核，以使所述源端系统内核根据所述进程管理策略与所述源容器的进程进行关联，并将与所述源容器的进程对应的通信报文打上所述源容器标识；其中，所述源容器、所述源端防护产品客户端以及所述源端系统内核三者部署于所述源计算节点内；

根据所述源容器标识获取重定向的所述通信报文，所述通信报文为所述源容器发送至所述源端系统内核的报文；

缓存所述通信报文。

进一步地，所述根据所述源容器标识与目的端防护产品客户端，进行基于容器标识的握手验证，包括：

发送包括所述源容器标识的连接请求至目的端防护产品客户端；

判断是否接收到所述目的端防护产品客户端发送的包括目的容器标识的连接请求确认信息；

如果是，则根据预设的源端安全策略确定所述源容器标识与所述目的容器标识对应的第一通信策略；

判断所述第一通信策略是否为流量放行策略；

如果是，则向所述目的端防护产品客户端发送最终确认信息，以表示通过与所述目的端防护产品客户端之间的握手验证。

进一步地，所述方法还包括：

当判断出未接收到所述连接请求确认信息时，或者当判断出所述通信策略不为流量放行策略时，则根据所述源容器标识和所述目的容器标识生成访问控制认证失败记录信息，以表示未通过与所述目的端防护产品客户端之间的握手验证。

本申请实施例第二方面提供了一种基于容器环境的访问控制方法，应用于目的端防护产品客户端，包括：

获取目的容器的目的容器标识；

根据所述目的容器标识与源端防护产品客户端，进行基于容器标识的握手验证；其中，所述目的容器与所述目的端防护产品客户端部署于目的计算节点内；

当握手验证通过时，接收所述源端防护产品客户端发送的通信报文；

将所述通信报文转发至所述目的容器。

在上述实现过程中，获取目的容器的目的容器标识；根据目的容器标识与源端防护产品客户端，进行基于容器标识的握手验证；当握手验证通过时，接收源端防护产品客户端发送的通信报文；将通信报文转发至目的容器。可见，该方法访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

进一步地，所述根据所述目的容器标识与源端防护产品客户端，进行基于容器标识的握手验证，包括：

接收源端防护产品客户端发送的包括源容器标识的连接请求；

根据预设的目的端安全策略确定所述源容器标识与所述目的容器标识对应的第二通信策略；

判断所述第二通信策略是否为流量放行策略；

如果是，则向所述源端防护产品客户端发送包括所述目的容器标识的连接请求确认信息；

判断是否接收到所述源端防护产品客户端发送的最终确认信息；

如果是，则执行所述的接收所述源端防护产品客户端发送的通信报文。

本申请实施例第三方面提供了一种基于容器环境的访问控制系统，所述基于容器环境的访问控制系统包括源计算节点和目的计算节点，所述源计算节点包括源端防护产品客户端、源容器以及源端系统内核，所述目的计算节点包括目的端防护产品客户端和目的容器，其中，

所述源端防护产品客户端，用于获取源容器的源容器标识；

所述源容器，用于发送通信报文至所述源端系统内核；

所述源端系统内核，用于为所述通信报文打上所述源容器标识，并将具有所述源容器标识的所述通信报文重定向至所述源端防护产品客户端；

所述源端防护产品客户端，用于接收具有所述源容器标识的所述通信报文并缓存所述通信报文；以及确定接收所述通信报文的目的容器；

所述源端防护产品客户端，用于根据所述源容器标识，进行与所述目的端防护产品客户端的基于容器标识的握手验证；当握手验证通过时，将缓存的所述通信报文发送至所述目的端防护产品客户端；

所述目的端防护产品客户端，用于将所述通信报文转发至所述目的容器。

在上述实现过程中，源端防护产品客户端获取源容器的源容器标识；源容器发送通信报文至源端系统内核；源端系统内核为通信报文打上源容器标识，并将具有源容器标识的通信报文重定向至源端防护产品客户端；源端防护产品客户端接收具有源容器标识的通信报文并缓存通信报文；以及确定接收通信报文的目的容器；源端防护产品客户端根据源容器标识，进行与目的端防护产品客户端的基于容器标识的握手验证；当握手验证通过时，将缓存的通信报文发送至目的端防护产品客户端；目的端防护产品客户端将通信报文转发至目的容器，可见，该系统访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

本申请实施例第四方面提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请实施例第一方面中任一项所述的基于容器环境的访问控制方法。

本申请实施例第五方面提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例第一方面中任一项所述的基于容器环境的访问控制方法。

附图说明

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

图1为本申请实施例提供的一种基于容器环境的访问控制方法的流程示意图；

图2为本申请实施例提供的另一种基于容器环境的访问控制方法的流程示意图；

图3为本申请实施例提供的一种基于容器环境的访问控制系统的结构示意图；

图4是本申请实施例提供的一种获取重定向的通信报文的示意图；

图5是本申请实施例提供的一种缓存重定向的通信报文的示意图；

图6是本申请实施例提供的一种基于容器标识的握手验证的流程示意图；

图7是本申请实施例提供的一种在握手验证通过之后源容器与目的容器之间的通信示意图。

图标：300-源计算节点；310-源端防护产品客户端；320-源容器；330-源端系统内核；400-目的计算节点；410-目的端防护产品客户端；420-目的容器；430-目的端系统内核；500-前端管理页面。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

实施例1

请参看图1，图1为本申请实施例提供了一种基于容器环境的访问控制方法的流程示意图。其中，该基于容器环境的访问控制方法应用于源端防护产品客户端，包括：

S101、当检测到源容器的进程启动时，提取源容器的相关属性标签。

本申请实施例中，源容器具体为容器或者pod等，对此本申请实施例不作限定。

本申请实施例中，容器controller group ，简称为 Cgroup，用于限制和隔离一组进程对系统资源的使用。对不同资源的具体管理是由各个子系统分工完成的。

S102、根据相关属性标签，确定源容器的源容器标识。

本申请实施例中，实施上述步骤S101~步骤S102，能够获取源容器的源容器标识。

本申请实施例中，以最简单的模型为例，一个pod或者是一个容器，给定一个源容器标识相当于给他起一个名字，在防控策略配置的时候，直接去配源容器标识，不需要配置其网络层信息。底层的访问控制识别的也是源容器标识，依靠在Cgroup中标记自定义的源容器标识（即Cgroup mark），把Linux的某个进程的所有外发流量数据包上打对应容器的源容器标识，有了这个标记以后，可以识别数据包身份，即这个外发流量具体对应的是哪个pod或容器。

本申请实施例中，源端防护产品客户端，又称为安全服务容器（top agent）。

本申请实施例中，该方法的应用场景前提是，在通信两端节点上，即源计算节点和目的计算节点上，部署安全服务容器（top agent），top agent中包含了标签控制逻辑和防御功能，用来管理源容器和目的容器之间所配置的访问控制策略。

本申请实施例中，源端防护产品客户端上预先部署有访问控制策略，该访问控制策略包括源容器标识和目的容器标识之间的访问控制策略。

本申请实施例中，分布在两个计算节点的pod进程启动后，会被同在节点内的topagent 识别发现，top agent通过标签提取器提取pod的相关属性标签，其中，该相关属性标签包括进程pid、label（用户给的标签）、进程名字等信息，对此本申请实施例不作限定。

本实施例的目的是建立从一个计算节点的应用podA访问另一个节点的数据库podB的通信连接，且podA和podB的访问控制策略以标识形式配置。

S103、下发预设的进程管理策略至源容器对应的源端系统内核，以使源端系统内核根据进程管理策略与源容器的进程进行关联，并将与源容器的进程对应的通信报文打上源容器标识。

本申请实施例中，源容器、源端防护产品客户端以及源端系统内核三者部署于源计算节点内。

请一并参阅图4，图4是本申请实施例提供的一种获取重定向的通信报文的示意图。如图4所示，当容器计算节点1发送通信报文至容器计算节点2时，该容器计算节点1为源节点，相应地，PodA为源容器，容器计算节点1内的top agent为源端防护产品客户端，容器计算节点1内的系统内核为源端系统内核。在容器计算节点1与目的计算节点建立连接时，发送出带有Cgroup mark的数据包会通过底层Iptables NFQ实现重定向，将syn、syn ack、ack包重定向到top agent中，top agent作为安全防护组件，掌握访问控制策略，可以做对应的策略匹配，同时pod标签属性信息的提取也已在top agent中完成，由此，实现以“Cgroup mark—进程pid—访问控制策略”的对应关系匹配。

本申请实施例中，源端防护产品客户端会给节点里的pod进程分配一个Cgroupmark（即源容器标识） ，并下发进程管理策略（即Cgroup策略）到系统内核，进程管理策略要求将Cgroup mark值写入进程pid的子目录下，这个过程在系统内核的Cgroup完成，即系统内核的Cgroup会与该进程实现指定关联，从而把进程的pid对应的流量打上源容器标识，以此来标记该pod进程启动后的所有数据包，之后此进程下所有数据包都将打上该源容器标识。

在步骤S103之后，还包括以下步骤：

S104、根据源容器标识获取重定向的通信报文，通信报文为源容器发送至源端系统内核的报文。

本申请实施例中，该通信报文具体为UDP（User Datagram Protocol）报文。

S105、缓存通信报文。

本申请实施例中，当容器计算节点1发送通信报文至容器计算节点2时，则容器计算节点1为源计算节点，容器计算节点2为目的计算节点；当容器计算节点2发送通信报文至容器计算节点1时，则容器计算节点2为源计算节点，容器计算节点1为目的计算节点。

请一并参阅图5，图5是本申请实施例提供的一种缓存重定向的通信报文的示意图。如图5所示，由源容器发往目的容器的UDP报文经重定向至源端防护产品客户端之后，其会将该报文先进行缓存。

本申请实施例中，实施上述步骤S103~步骤S105，能够获取具有源容器标识的通信报文并缓存通信报文；其中，源容器与源端防护产品客户端部署于源计算节点内。

在步骤S105之后，还包括以下步骤：

S106、确定接收通信报文的目的容器。

S107、发送包括源容器标识的连接请求至目的端防护产品客户端。

在步骤S107之后，还包括以下步骤：

S108、判断是否接收到目的端防护产品客户端发送的包括目的容器标识的连接请求确认信息，如果是，执行步骤S109~步骤S110；如果否，执行步骤S112。

S109、根据预设的源端安全策略确定源容器标识与目的容器标识对应的第一通信策略。

S110、判断第一通信策略是否为流量放行策略，如果是，执行步骤S111；如果否，执行步骤S112。

S111、向目的端防护产品客户端发送最终确认信息，以表示通过与目的端防护产品客户端之间的握手验证，并执行步骤S113。

S112、根据源容器标识和目的容器标识生成访问控制认证失败记录信息，以表示未通过与目的端防护产品客户端之间的握手验证，并结束本流程。

本申请实施例中，实施上述步骤S107~步骤S112，能够根据源容器标识与目的端防护产品客户端，进行基于容器标识的握手验证；其中，目的容器与目的端防护产品客户端部署于目的计算节点内。

请一并参阅图6，图6是本申请实施例提供的一种基于容器标识的握手验证的流程示意图。如图6所示，包括以下步骤：

步骤1、源端防护产品客户端发送连接请求，附带自己的标签信息，即源容器标识。

步骤2、目的端防护产品客户端根据接收到的连接请求中的源容器标识与目的容器标识在目的端防护产品客户端的访问控制策略中，检测由“源容器标识”至“目的容器标识”的第二通信策略是否为流量放行，如果是，则进行三次握手的下一步，发送连接请求确认信息，附带自己的目的容器标识。

当第二通信策略不是流量放行时，则表示策略未通过，则不发送连接请求确认信息，此时对端会三次握手超时，相当于验证失败，进入步骤5。

步骤3、源端防护产品客户端接收到对方发送的连接请求确认信息，根据连接请求确认信息中的目的容器标识，则源端防护产品客户端的访问控制策略中，检测由“源容器标识”至“目的容器标识”的第一通信策略是否为流量放行，如果是，发送最终确认信息。

当第一通信策略不是流量放行时，则表示策略未通过，则不发送最终确认信息，此时对端会三次握手超时，相当于验证失败，进入步骤5。

步骤4、在步骤3之后，源端防护产品客户端完成访问控制验证，表示由源容器发往目的容器的UDP流量是可以放行的，则执行步骤S113。

步骤5、三次握手超时或者策略不通过时，表示访问控制认证失败。

在步骤S112之后，还包括以下步骤：

S113、当握手验证通过时，将缓存的通信报文发送至目的端防护产品客户端，以使目的端防护产品客户端将通信报文转发至目的容器。

请一并参阅图7，图7是本申请实施例提供的一种在握手验证通过之后源容器与目的容器之间的通信示意图。如图7所示，当UDP的访问验证通过之后，将发送缓存在源端UDP报文缓存中的通信报文。

本申请实施例中，源端防护产品客户端会将已经验证通过的对端信息（即源容器标识-目的容器标识）缓存在自己端的已验证通过的对端信息中，下次再向验证过的对端发送UDP报文时，就不用进行握手验证，直接放行即可。

本申请实施例中，针对UDP报文的基于标签的访问控制过程，通过模拟三次握手附带自己的标签信息给对端，然后双方根据策略完成访问控制实现。

本申请实施例中，提出了一种容器环境下UDP报文基于标签的访问控制的系统，在进行握手验证时，进行UDP访问控制的token认证，认证通过则表示模拟三次握手完成。该方法可以应用于云安全、容器安全等场景用，解决容器之间UDP传输中基于属性标签端到端的访问控制问题，不受IP变动影响。由于UDP是不可靠的通信，并没有类似TCP三次握手的过程。

可见，实施本实施例所描述的基于容器环境的访问控制方法，访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

实施例2

请参看图2，图2为本申请实施例提供的另一种基于容器环境的访问控制方法的流程示意图。如图2所示，其中，该基于容器环境的访问控制方法应用于目的端防护产品客户端，包括：

S201、获取目的容器的目的容器标识。

S202、接收源端防护产品客户端发送的包括源容器标识的连接请求。

S203、根据预设的目的端安全策略确定源容器标识与目的容器标识对应的第二通信策略。

本申请实施例中，实施上述步骤S202~步骤S206，访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

S204、判断第二通信策略是否为流量放行策略，如果是，执行步骤S205~步骤S206；如果否，则表示未通过握手验证，结束本流程。

S205、向源端防护产品客户端发送包括目的容器标识的连接请求确认信息。

在步骤S205之后，还包括以下步骤：

作为一种可选的实施方式，判断

S206、判断是否接收到所述源端防护产品客户端发送的最终确认信息，如果是，执行步骤S207~步骤S208；如果否，则表示未通过握手验证，结束本流程。

S207、当握手验证通过时，接收源端防护产品客户端发送的通信报文。

本申请实施例中，实施上述步骤S202~步骤S207，能够根据目的容器标识与源端防护产品客户端，进行基于容器标识的握手验证；其中，目的容器与目的端防护产品客户端部署于目的计算节点内。

在步骤S207之后，还包括以下步骤：

S208、将通信报文转发至目的容器。

本申请实施例中，实施该方法能够与源端防护产品客户端之间进行UDP进行token认证，以进行握手验证，解决容器安全项目中，基于UDP流量的基于标签的访问控制问题。

可见，实施本实施例所描述的基于容器环境的访问控制方法，访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

实施例3

请参看图3，图3为本申请实施例提供的一种基于容器环境的访问控制系统的系统构架示意图。如图3所示，该基于容器环境的访问控制系统包括源计算节点300和目的计算节点400，源计算节点300包括源端防护产品客户端310、源容器320以及源端系统内核330，目的计算节点400包括目的端防护产品客户端410和目的容器420，其中，

源端防护产品客户端310，用于获取源容器320的源容器320标识；

源容器320，用于发送通信报文至源端系统内核330；

源端系统内核330，用于为通信报文打上源容器320标识，并将具有源容器320标识的通信报文重定向至源端防护产品客户端310；

源端防护产品客户端310，用于接收具有源容器320标识的通信报文并缓存通信报文；以及确定接收通信报文的目的容器420；

源端防护产品客户端310，用于根据源容器320标识，进行与目的端防护产品客户端410的基于容器标识的握手验证；当握手验证通过时，将缓存的通信报文发送至目的端防护产品客户端410；

目的端防护产品客户端410，用于将通信报文转发至目的容器420。

本申请实施例中，该目的计算节点400还包括目的端系统内核430。

本申请实施例中，该基于容器环境的访问控制系统还包括前端管理页面500，用于管理源端防护产品客户端310和目的端防护产品客户端410。

本申请实施例中，通过源容器发送给目的容器的UDP流量的访问控制实现过程包括：agent流量缓存、agent模拟三次握手验证、agent策略验证之后发送UDP通信报文三个过程来完成UDP基于标签的访问控制。

本申请实施例中，部署安全容器agent对应图3中源端防护产品客户端310或者目的端防护产品客户端410，该agent会将前端管理页面500下发的访问控制配置缓存到自己本地的访问控制策略中。

本申请实施例中，源/目的端防护产品客户端会添加Cgroup标记，借助Iptablesnfq重定向流量到源端防护产品客户端310或者目的端防护产品客户端410。换言之，会将由源/目的容器发往源/目的系统内核的流量引入到相对应的源/目的端防护产品客户端。

本申请实施例中，流量引入到源/目的端防护产品客户端，源/目的端防护产品客户端将根据访问控制策略决定是否放行流量，完成访问控制。换言之，源/目的端防护产品客户端将在内部完成访问控制校验。

本申请实施例中，容器安全防护中，对UDP流量，基于标签的访问控制。不受限于容器中IP地址是否变化，仅通过容器标识进行识别对端。

本申请实施例中，模拟三次握手过程中，附带容器标识到对端，并在关键步骤进行访问控制的校验，从而进行访问控制。

本申请实施例中，对于基于容器环境的访问控制系统的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。

可见，实施本实施例所描述的基于容器环境的访问控制系统，访问控制过程简单，且能够实现跨计算节点的容器到容器端到端的访问控制，从而提高网络安全防护性能。

本申请实施例提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请实施例1或实施例2中任一项基于容器环境的访问控制方法。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例1或实施例2中任一项基于容器环境的访问控制方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，也可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (8)

1.一种基于容器环境的访问控制方法，其特征在于，应用于源端防护产品客户端，包括：

获取源容器的源容器标识；

获取具有所述源容器标识的通信报文并缓存所述通信报文；其中，所述源容器与所述源端防护产品客户端部署于源计算节点内；

确定接收所述通信报文的目的容器；

根据所述源容器标识与目的端防护产品客户端，进行基于容器标识的握手验证；其中，所述目的容器与所述目的端防护产品客户端部署于目的计算节点内；

当握手验证通过时，将缓存的所述通信报文发送至所述目的端防护产品客户端，以使所述目的端防护产品客户端将所述通信报文转发至所述目的容器；

其中，所述根据所述源容器标识与目的端防护产品客户端，进行基于容器标识的握手验证，包括：

发送包括所述源容器标识的连接请求至目的端防护产品客户端；

判断是否接收到所述目的端防护产品客户端发送的包括目的容器标识的连接请求确认信息；

如果是，则根据预设的源端安全策略确定所述源容器标识与所述目的容器标识对应的第一通信策略；

判断所述第一通信策略是否为流量放行策略；

如果是，则向所述目的端防护产品客户端发送最终确认信息，以表示通过与所述目的端防护产品客户端之间的握手验证。

2.根据权利要求1所述的基于容器环境的访问控制方法，其特征在于，所述获取源容器的源容器标识，包括：

当检测到源容器的进程启动时，提取所述源容器的相关属性标签；

根据所述相关属性标签，确定所述源容器的源容器标识。

3.根据权利要求1所述的基于容器环境的访问控制方法，其特征在于，所述获取具有所述源容器标识的通信报文并缓存所述通信报文，包括：

下发预设的进程管理策略至所述源容器对应的源端系统内核，以使所述源端系统内核根据所述进程管理策略与所述源容器的进程进行关联，并将与所述源容器的进程对应的通信报文打上所述源容器标识；其中，所述源容器、所述源端防护产品客户端以及所述源端系统内核三者部署于所述源计算节点内；

根据所述源容器标识获取重定向的所述通信报文，所述通信报文为所述源容器发送至所述源端系统内核的报文；

缓存所述通信报文。

4.根据权利要求1所述的基于容器环境的访问控制方法，其特征在于，所述方法还包括：

当判断出未接收到所述连接请求确认信息时，或者当判断出所述通信策略不为流量放行策略时，则根据所述源容器标识和所述目的容器标识生成访问控制认证失败记录信息，以表示未通过与所述目的端防护产品客户端之间的握手验证。

5.一种基于容器环境的访问控制方法，其特征在于，应用于目的端防护产品客户端，包括：

获取目的容器的目的容器标识；

根据所述目的容器标识与源端防护产品客户端，进行基于容器标识的握手验证；其中，所述目的容器与所述目的端防护产品客户端部署于目的计算节点内；

当所握手验证通过时，接收所述源端防护产品客户端发送的通信报文；

将所述通信报文转发至所述目的容器；

其中，所述根据所述目的容器标识与源端防护产品客户端，进行基于容器标识的握手验证，包括：

接收源端防护产品客户端发送的包括源容器标识的连接请求；

根据预设的目的端安全策略确定所述源容器标识与所述目的容器标识对应的第二通信策略；

判断所述第二通信策略是否为流量放行策略；

如果是，则向所述源端防护产品客户端发送包括所述目的容器标识的连接请求确认信息；

判断是否接收到所述源端防护产品客户端发送的最终确认信息；

如果是，则执行所述的接收所述源端防护产品客户端发送的通信报文；

其中，所述源容器与所述源端防护产品客户端部署于源计算节点内。

6.一种基于容器环境的访问控制系统，其特征在于，所述基于容器环境的访问控制系统包括源计算节点和目的计算节点，所述源计算节点包括源端防护产品客户端、源容器以及源端系统内核，所述目的计算节点包括目的端防护产品客户端和目的容器，其中，

所述源端防护产品客户端，用于获取源容器的源容器标识；

所述源容器，用于发送通信报文至所述源端系统内核；

所述源端系统内核，用于为所述通信报文打上所述源容器标识，并将具有所述源容器标识的所述通信报文重定向至所述源端防护产品客户端；

所述源端防护产品客户端，用于接收具有所述源容器标识的所述通信报文并缓存所述通信报文；以及确定接收所述通信报文的目的容器；

所述源端防护产品客户端，用于根据所述源容器标识，进行与所述目的端防护产品客户端的基于容器标识的握手验证；当握手验证通过时，将缓存的所述通信报文发送至所述目的端防护产品客户端；其中，所述握手验证过程包括：发送包括所述源容器标识的连接请求至目的端防护产品客户端；判断是否接收到所述目的端防护产品客户端发送的包括目的容器标识的连接请求确认信息；如果是，则根据预设的源端安全策略确定所述源容器标识与所述目的容器标识对应的第一通信策略；判断所述第一通信策略是否为流量放行策略；如果是，则向所述目的端防护产品客户端发送最终确认信息，以表示通过与所述目的端防护产品客户端之间的握手验证

所述目的端防护产品客户端，用于将所述通信报文转发至所述目的容器。

7.一种电子设备，其特征在于，所述电子设备包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行权利要求1至5中任一项所述的基于容器环境的访问控制方法。

8.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行权利要求1至5任一项所述的基于容器环境的访问控制方法。