CN116781301A - Cross-namespace container security protection methods, devices, equipment and media - Google Patents

Abstract

The invention provides a method, a device, equipment and a medium for protecting container safety across namespaces. Comprising the following steps: deploying master agents in the root namespaces; controlling a master agent to generate a remote agent in a root namespace under the condition that the master agent monitors that a remote namespace is newly built on a current network environment node; the running space of the remote agent is switched to a remote naming space, the remote agent is controlled to execute security protection in the remote naming space, and the master agent is controlled to execute security protection in the root naming space. According to the invention, the master agent is deployed, the remote agent is automatically generated along with the creation of the namespaces, and the communication traffic of the containers in the corresponding namespaces is intercepted through the NFQ mechanism, so that the safety protection of the containers in different namespaces and the inside of the namespaces can be effectively realized.

Description

Cross-namespace container security protection methods, devices, equipment and media

Technical field

The present invention relates to the field of network security technology, and specifically relates to a cross-namespace container security protection method, device, equipment and medium.

Background technique

In the field of network security technology, security protection in container environments is an end-to-end access control method. Access control is closely related to the network environment, and changes in the network environment will put new requirements on it.

Currently, the widely used container security protection methods mainly use ingress gateways to protect the container environment, and cloud native network policy technology to achieve protection.

However, since the ingress gateway can only provide north-south security services and cannot provide east-west security protection between any two containers, the network policy technology can only provide basic inter-container access control functions and can only target the transport layer. Group access control cannot implement advanced security functions of layers 4 to 7, and there is no content-based intrusion prevention, malicious code filtering and other functions.

In view of this, there is an urgent need to provide a new container security protection method to achieve east-west security protection across namespaces.

Contents of the invention

The present invention provides a cross-namespace container security protection to solve the technical problem of cross-namespace container security protection.

In a first aspect, the present invention provides a cross-namespace container security protection method, including:

Deploy the root namespace security protection component master agent in the root namespace;

When the master agent detects that a remote namespace is newly created on the current network environment node, control the master agent to generate a remote namespace security protection component remoteagent in the root namespace;

Switch the running space of the remote agent to the remote namespace;

Control the remote agent to perform security protection in the remote namespace, and control the masteragent to perform security protection in the root namespace;

The security protection functions of the remote agent and the master agent are consistent.

In one embodiment, controlling the remote agent to perform security protection in the remote namespace, and controlling the master agent to perform security protection in the root namespace include:

Utilize the address translation management tool NFQ in the system kernel to introduce the data packets in the remote namespace to the remote agent respectively, so that the remote agent can perform security of the data packets in the remote namespace. protection; protection

The NFQ is used to introduce the data packets in the root namespace to the master agent, so that the master agent can perform security protection on the data packets in the root namespace.

In one embodiment, after switching the running space of the remote agent to the remote namespace corresponding to the remote container, the method further includes:

Establish a remote procedure call client RPC client in the master agent, and establish a remote procedure call server RPC server in the remote agent;

Establish communication between the RPC client and the RPC server for the remote agent to send policy configuration information to the master agent;

The master agent uploads the policy configuration information to the management end;

The policy configuration information includes labels of existing protection policies, report logs, and monitoring information.

In one embodiment, after the master agent uploads the policy configuration information to the management end, it also includes:

The management end matches a public protection policy set from the policy library according to the policy configuration information, and delivers the public protection policy set to the master agent;

The master agent determines the intersection between the labels of each protection strategy in the public protection strategy set and the labels of the existing protection strategies in the remote agent as a public label;

The master agent delivers the protection policy related to the public label to the remote namespace.

In one embodiment, the management end matching the public protection policy set from the policy library according to the policy configuration information includes the management end performing the following operations:

Based on the tag matching algorithm, perform a preliminary screening of all protection strategies in the strategy library;

Clean all protection policies obtained through the preliminary screening to filter out empty protection policies and policies that do not match the remote namespace;

According to the policy configuration information, all the cleaned protection policies are intersected and deduplicated to obtain the public protection policy set.

In one embodiment, performing intersection deduplication on all protection policies after cleaning according to the policy configuration information to obtain the public protection policy set includes:

Calculate the tag feature vector corresponding to each of the cleaned protection strategies, and calculate the remote tag feature vector corresponding to the remoteagent tag;

Determine the duplicate protection strategy among all protection strategies based on the comparison result between the distance between each policy tag feature vector and the remote tag feature vector and the preset threshold;

Filter out the duplicate protection policies from all protection policies to obtain the public protection policy set.

In one embodiment, the master agent delivers the protection policy related to the public label to the remote namespace, including the master agent performing the following operations:

Determine the policy mode of each protection policy related to the public label; if the policy mode is the inbound mode, then write the public label of the protection policy to the dst area; if the policy mode is the outbound mode, then Write the public label of the protection strategy into the src area; if the policy mode is a bidirectional mode, write the public label of the protection strategy into the dst area and the src area;

If the policy mode of the protection policy is inbound mode, the target remote namespace is determined based on the matching degree between the tags in the dst area and the tags of each remote agent, so that the target remote namespace can store all Configure the above protection policy into the networksACL and xRules of the remote agent;

If the policy mode of the protection policy is outbound mode, determine the target remote namespace based on the matching degree between the tags in the src area and the tags of each remote agent, so that the target remote namespace can store all Configure the above protection policy into the ApplicationACLs and xRules of the remote agent;

If the policy mode of the protection policy is a two-way mode, the target remote namespace is determined based on the matching degree between the labels in the dst area and the src area and the labels of each remote agent for the target remote agent. The namespace configures the protection policy into networksACLs, ApplicationACLs, and xRules.

In a second aspect, the present invention provides a cross-namespace container security protection device, including:

The component deployment unit is used to deploy the root namespace security protection component masteragent in the root namespace;

A monitoring deployment unit is used to control the master agent to generate a remote namespace security protection component remote agent in the root namespace when the master agent detects that a new remote namespace is created on the current network environment node;

A space switching unit, used to switch the running space of the remote agent to the remote namespace;

A protection control unit, used to control the remote agent to perform security protection in the remote namespace, and to control the master agent to perform security protection in the root namespace;

The security protection functions of the remote agent and the master agent are consistent.

In a third aspect, the present invention provides an electronic device, including a memory and a memory storing a computer program. When the processor executes the program, the steps of the cross-namespace container security protection method described in the first aspect are implemented.

In a fourth aspect, the present invention provides a processor-readable storage medium. The processor-readable storage medium stores a computer program. The computer program is used to cause the processor to execute the cross-namespace operation described in the first aspect. Steps for container security methods. .

The cross-namespace container security protection method, device, equipment and medium provided by the present invention deploy a master agent and automatically generate a remote agent with the creation of the namespace, so as to realize that there is a remote agent protection component under each remote namespace. , and then intercept the communication traffic of containers in the corresponding namespace through the NFQ mechanism, which can effectively implement container security protection in different namespaces and within the namespace in the container environment.

Description of drawings

In order to explain the present invention or the technical solutions in the prior art more clearly, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are of the present invention. For some embodiments of the invention, those of ordinary skill in the art can also obtain other drawings based on these drawings without exerting creative efforts.

Figure 1 is one of the flow diagrams of the cross-namespace container security protection method provided by the present invention;

Figure 2 is a schematic structural diagram of a container environment deployment scenario provided by the present invention;

Figure 3 is the second schematic flow chart of the cross-namespace container security protection method provided by the present invention;

Figure 4 is a schematic diagram of the working principle of the safety protection component provided by the present invention;

Figure 5 is a schematic diagram of the principle of security protection after the remote security protection component provided by the present invention is established;

Figure 6 is a schematic flow chart of security policy configuration management provided by the present invention;

Figure 7 is a schematic flowchart of the security protection component provided by the present invention for transmitting policy information;

Figure 8 is the third schematic flowchart of the cross-namespace container security protection method provided by the present invention;

Figure 9 is a schematic structural diagram of a cross-namespace container security protection device provided by the present invention;

Figure 10 is a schematic structural diagram of the electronic device provided by the present invention.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present invention more clear, the technical solutions in the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention. , not all examples. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of the present invention.

It should be noted that in the description of the embodiments of the present invention, the terms "comprising", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or equipment including a series of elements It includes not only those elements but also other elements not expressly listed or inherent in the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or apparatus that includes the stated element. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

The terms "first", "second", etc. in the present invention are used to distinguish similar objects, but are not used to describe a specific order or sequence. It is to be understood that the figures so used are interchangeable under appropriate circumstances so that the embodiments of the present application can be practiced in orders other than those illustrated or described herein, and that "first," "second," etc. are distinguished Objects are usually of one type, and the number of objects is not limited. For example, the first object can be one or multiple. In addition, "and/or" indicates at least one of the connected objects, and the character "/" generally indicates that the related objects are in an "or" relationship.

Before introducing the cross-namespace container security protection method, device, equipment and medium provided by the present invention, the relevant knowledge points involved in the present invention will be briefly introduced.

The cross-namespace container security protection involved in the present invention is a method of end-to-end access control in the field of network security technology. Access control is closely related to the network environment, and changes in the network environment will put new requirements on it.

In traditional environments, network environments generally have the following characteristics:

(1) The network is relatively static, and most network protection rules are based on static IP addresses and ports;

(2) The interior is trusted by default, the network boundary is clear, and the access control mechanism is generally deployed at the network boundary;

(3) Most network traffic will pass through the gateway.

On this basis, access control in the container (pod) environment has the following characteristics:

(1) The starting, stopping and dynamic migration of containers are always happening, and IP allocation changes frequently;

(2) Mixed deployment of multiple applications, unclear boundaries, and extremely complex internal communication relationships make it impossible to set security protection strategies in advance;

(3) The visibility of east-west traffic between containers is poor. In order to detect and protect invisible traffic, the network policy rules (network policy) that come with the container platform are generally used, but layer 7 advanced access control cannot be achieved;

(4) Under the hybrid cloud model, there is a lack of common technology to achieve unified access control across cloud platforms, such as resource clouds and edge clouds, as well as business communication scenarios between clouds in different regions and different services. Unified access control cannot be achieved.

Among them, east-west traffic refers to the traffic between containers inside the data center, and north-south traffic refers to the traffic between containers inside the data center and outside the data center (such as the Internet).

Container technology can be regarded as a lightweight virtualization method that packages applications and necessary execution environments into container images, so that applications can run relatively independently directly on the host (physical machine or virtual machine). Containers isolate applications at the operating system layer and can run multiple independent application operating environments on the host kernel. Compared with traditional application testing and deployment, container deployment does not need to consider the compatibility of the application's operating environment in advance; and compared with traditional virtual machines, containers can run in the host machine without an independent operating system kernel, achieving more High operating efficiency and resource utilization.

With the continuous development of IT technology, the lightweight characteristics of containers have made this technology widely used in cloud computing. Since containers are more fine-grained identification units and do not have similar network attributes to traditional hardware devices like virtual machines, the communication between containers Security is undoubtedly a huge threat challenge.

In addition, container clusters provide various networking modes such as bridge network, MacVLAN, and overlay network. At the same time, containers and hosts share the operating system kernel, which introduces security risks in terms of isolation between containers and hosts and between containers. . Access control between containers includes network communication in different namespaces of the containers, and cannot be used for security protection like the traditional configuration of five-tuple access control policies. Multiple Network Address Translation (NAT) makes IP addressing very complex and difficult to implement. Access control is very difficult.

Table 1 List of types of namespaces

In addition, before introducing the present invention, some technical terms related to containers involved in the present invention are briefly introduced:

Namespace: As shown in Table 1, in order to ensure resource isolation between container processes and avoid mutual influence and interference, the Namespaces mechanism of the Linux kernel provides UTS, User, Mount, Network, PID, IPC and other namespaces. It implements six resource isolation functions including host name, user permissions, file system, network, process number, and inter-process communication. By calling the clone() function and passing in the corresponding system call parameters to create a container process, the corresponding resource content can be isolated.

Among them, virtual network cards Veth appear in pairs, just like the two ends of a pipe. Data entering from the veth at one end of the pipe will come out from the veth at the other end. In other words, you can use the veth interface to connect a network namespace to an external default namespace or global namespace, and the physical network cards exist in these namespaces. What veth-pair clears is the mutual access restrictions between the container network namespace and the host root namespace. One end of the veth-pair is on the host and the other end is in the container.

Cgroup: In the container, there are allocated specific proportions of CPU, IO, memory, network and other resources. This is the controller group, referred to as cgroup, which is used to limit and isolate the use of system resources by a group of processes. The specific management of different resources is completed by the division of labor of each subsystem.

Address Translation Management Tool NFQUEUE (abbreviated as NFQ): is an iptables and ip6tables target that delegates packet decisions to user-space software.

For example, the following rule will require that all packets destined for the package listen to the user's security plan. When a packet arrives at an NFQ destination, it enters the queue corresponding to the number given by the --queue-num option. NFQ is a technology that implements traffic redirection in the kernel.

Security protection component agent: The agent involved in the present invention refers to what is generally considered in the field as a container security engine. This engine can implement security protection such as inter-container access control and mainly uses NFQ to redirect data traffic. The agent's protection process is similar to adding a virtual firewall on the data packet communication line, which is consistent with the traditional security protection logic. The function of NFQ is equivalent to the role of a switch, directing data traffic to the security protection component agent.

However, due to the isolation effect of the Linux namespace, the agent can only provide security protection for traffic in the namespace where the agent process is located. That is, the agent cannot intercept communication traffic in other namespaces. Therefore, this protection method does not protect traffic across namespaces. The security protection of the container is useless.

Next, by analyzing the existing security protection methods for the container environment through ingress gateways and the native network policy protection methods, the improvement direction and improvement principle of the present invention will be further explained.

Regarding existing technology 1, a method for security protection of a container environment through an ingress gateway:

As the service entrance of the container, the Ingress gateway provides security protection functions such as permission control and intrusion prevention. Normally, service and pod IPs are only accessible within the cluster. Requests from outside the cluster need to be forwarded to the NodePort exposed by the service on the Node through load balancing, and then forwarded to the relevant Pod by kube-proxy. Ingress provides a collection of routing rules for requests entering the cluster. Ingress can provide services with URLs for external access to the cluster, load balancing, SSL termination, HTTP routing, etc. In order to configure these Ingress rules, the cluster administrator needs to deploy an Ingress controller, which monitors changes in Ingress and services, configures load balancing according to the rules, and provides access.

Therefore, what Ingress solves is the corresponding problem between domain names and services after new services are added. It is basically an ingress object, which is created, updated and loaded through yaml.

The Ingress Controller generates an Nginx configuration from the changes in Ingress, then writes this configuration to the Nginx Pod through the Kubernetes API, and then reloads it.

The connection request is intercepted by the load balancer, such as Nginx, and then the Ingress Controller learns the service corresponding to a certain domain name by interacting with the Ingress, and then learns the service address and other information by interacting with the kubernetes API; after synthesis, the configuration file is generated and written to the load balancer in real time. The load balancer then reloads the rule to realize service discovery, that is, dynamic mapping.

Through the analysis of the above-mentioned existing technology 1, it can be learned that it can only provide north-south security services and cannot provide east-west security protection between any two containers.

Regarding the second existing technology, the network policy protection method that comes with cloud native:

Network Policy provides policy-based network control to isolate applications and reduce the attack surface. It uses tag selectors to simulate traditional segmented networks and controls traffic between them and from outside via policies.

Network Policy is a resource type in kubernetes and belongs to a certain namespace. Its content logically contains two key parts. One part is the pod selector, which selects pods in the same namespace based on labels, and applies the rules defined in it to the selected pods; the other part is the rules, which are the network traffic in and out of the pod. The rules adopt a whitelist mode. Those that comply with the rules are passed and those that do not comply with the rules are rejected. The Network Policy mechanism can control the access control policy based on the transport layer quintuple between pods.

Through the analysis of the above-mentioned existing technology 1, it can be learned that it can only provide basic inter-container access control functions, and can only perform access control on transport layer quintuples. It cannot realize advanced security functions of layers 4-7 and has no based on Content intrusion prevention, malicious code filtering and other functions.

Different namespaces in the container environment are isolated from each other, and cross-namespace security protection cannot be implemented through a protection mechanism. For example, network communications in other namespaces cannot be securely protected in the root namespace.

In view of this, the cross-namespace container security protection method, device, equipment and medium provided by the present invention can effectively realize container security protection across namespaces and within namespaces in a container environment, that is, to solve the problem of container security between different namespaces. East-west security protection.

The following describes the cross-namespace container security protection method, device, equipment and medium provided by the present invention with reference to Figures 1-10.

Figure 1 is one of the flow diagrams of the cross-namespace container security protection method provided by the present invention. As shown in Figure 1, it mainly includes but is not limited to the following steps:

Step 101: Deploy the root namespace security protection component master agent in the root namespace.

Figure 2 is a schematic structural diagram of a container environment deployment scenario provided by the present invention. As shown in Figure 2, the container environment of the present invention includes a basic root namespace (root namespace) and multiple remote namespaces such as namespace1 and namespace2. …, also includes containers created directly under the root namespace.

The deployed security protection components are represented as agents in Figure 2. The security protection components include master agent and remote agent. The master agent is deployed in the root namespace, and other remote agents are copied from it. The security protection component agent mainly uses NFQ for redirection to obtain the data packets to be detected.

In the process of executing container security protection, first start a root namespace security protection component master agent process under the root namespace. This process can provide such things as access control, intrusion prevention, malicious code filtering, etc. to the containers in the root namespace. Security protection (similar to a virtualized firewall in a container environment).

In the root namespace, the network traffic of other remote namespaces cannot be seen. Then the master agent cannot obtain the data packets of other remote namespaces when using NFQ for redirection. Therefore, it can only obtain the data packets of other remote namespaces under each namespace. Only with an agent can cross-namespace security protection be achieved.

Step 102: When the master agent detects that a remote namespace is newly created on the current network environment node, control the master agent to generate a remote namespace security protection component remote agent in the root namespace.

Specifically, the present invention monitors the creation of new remote namespaces on nodes in the current network environment through the master agent under the root namespace. When it determines that a new remote namespace is created, the master agent will automatically identify it.

When the master agent recognizes the new container and creates a new remote namespace (for example, newly created namespace1), the master agent automatically starts a remote namespace security protection component remote agent in its namespace.

It should be noted that the newly started remote agent is a process with the same functions as the master agent and can provide the same security protection as the master agent, but it does not belong to any namespace at this time.

Step 103: Switch the running space of the remote agent to the remote namespace.

Figure 3 is the second flow diagram of the cross-namespace container security protection method provided by the present invention. As shown in Figure 3, the entire method generally includes the following steps:

Step 301: Deploy the root namespace security protection component in the root namespace;

Step 302: When the new namespace namespace1 is created, a remoteagent is generated in the root namespace;

Step 303, start enter ns to switch the running space of the generated remote agent to the newly created namespace1;

Step 304: The remote agent performs security protection actions in namespace1.

It should be noted that after creating the remoteagent (denoted as remote agent1) for the remote namespace namespace1 in the root namespace, the Linux system call enter ns is started to realize the kernel system call to switch the running space of the created remote agent1 to In the remote namespace namespace1 to be protected, for example: use the setns() function to add remote agent1 to the specified remote namespace namespace1.

At this time, the converted remote agent1 and the container under the newly created remote namespace namespace1 belong to the same namespace.

The above switching process of the namespace of remote agent1 is implemented by running code in the remote agent1 process. The code of the specific function calling process can be set as follows:

snprintf(path,sizeof(path),"%s/%s/ns/net",mountpoint,container_pid_env);

fd=open(path,O_RDONLY);

retval=setns(fd,0);

setns(fd,0).

After remote agent1 executes the setns system call, the namespace switching is completed. The namespace seen by remoteagent1 is the relevant data information of the new namespace.

Step 104: Control the remote agent to perform security protection in the remote namespace, and control the master agent to perform security protection in the root namespace.

Specifically, remote agent1 starts to perform security protection actions in namespace1 as an independent component, that is, it actively uses the underlying NFQ to introduce the traffic of the current namespace and performs security filtering and detection such as access control and intrusion prevention to solve the problem in the newly created remote In the namespace namespace1, there is a risk that the original security protection function will fail.

It should be noted that when remote agent1 executes iptables NFQ redirection in the remote namespace namespace1, it only targets the data packets of namespace1, thus achieving protection for the newly created container in namespace1.

In addition, under special circumstances, some special containers are created directly in the root namespace. Such containers are directly protected through the master agent under the root namespace.

Figure 4 is a schematic diagram of the working principle of the security protection component provided by the present invention. As shown in Figure 4, after a process distributed on two computing nodes in any namespace is started, it will be identified and discovered by the agent in the node. The agent extracts it through tags. The extractor extracts the relevant attribute labels of the container, including process pid, label (label given by the user), process name and other information.

When establishing a connection, the data packets sent by podA will be redirected through the NFQ of the underlying Iptables, and the data packets will be redirected to the container security engine agent. As a security protection component, the agent masters access control policies and can make corresponding policy matches.

After the policy interpretation is completed, the agent will release the data packet to continue transmission. When communicating with each other, the two ends of the communication (i.e. container computing node 1 and container computing node 2) will perform outbound policy matching and inbound policy matching respectively, so that Implement security protection for traffic within each namespace.

The cross-namespace container security protection method provided by the present invention can effectively realize the container environment by deploying a master agent, automatically generating a remote agent with the namespace creation, and intercepting the communication traffic of the container in the corresponding namespace through the NFQ mechanism. , different namespaces and container security protection within namespaces.

Based on the contents of the above embodiments, as an optional embodiment, the step 104 is to control the remoteagent to perform security protection in the remote namespace, and to control the master agent to perform security protection in the root namespace. Security protection, specifically includes:

Use the address translation management tool NFQ in the system kernel to introduce data packets in the remote namespace to the remote agent, so that the remote agent can perform security protection on the data packets in the remote namespace;

Use NFQ to introduce data packets in the root namespace to the master agent, so that the master agent can perform security protection on the data packets in the root namespace.

Figure 5 is a schematic diagram of the security protection principle after the remote security protection component provided by the present invention is established. As shown in Figure 5, when any remote agent executes iptables NFQ redirection in the namespace, it only targets the current remote namespace. The data packet data of the namespace realizes the protection of the containers in the newly created remote namespace.

In addition, under special circumstances, some special containers, that is, containers created directly in the root namespace, can directly use NFQ to introduce data packets in the root namespace to the master agent under the root namespace for security protection.

The cross-namespace container security protection method provided by the present invention, by copying the security protection policy of the master agent to the remote agent, establishes an independent protection component for each namespace, and comprehensively realizes cross-namespace security in the container environment. protection.

Based on the content of the above embodiment, as an optional embodiment, after switching the running space of the remote agent to the remote namespace corresponding to the remote container, it also includes:

Establish a remote procedure call client RPC client in the master agent, and establish a remote procedure call server RPC server in the remote agent; establish communication between the RPC client and the RPC server for the remote agent to transfer policy configuration information Sent to the master agent; the master agent uploads the policy configuration information to the management end.

Among them, the policy configuration information mainly includes labels of existing protection policies, report logs, and monitoring information.

After realizing switching the running space of the newly created remote agent to the remote namespace corresponding to the remote container, the present invention also provides a method for configuration management between the master agent and the remote agent.

Figure 6 is a schematic flow chart of security policy configuration management provided by the present invention. As shown in Figure 6, the method of creating a security protection component agent in each namespace has been described in detail in the above embodiment (in the root namespace Deploy the master agent in the remote namespace and deploy the remote agent in the remote namespace). If you configure the security policy separately for each remoteagent, it is obviously too complicated and unrealistic.

Therefore, the cross-namespace container security protection method provided by the present invention mainly includes the following steps in terms of configuration management:

Step 601, establish an RPC client in the master agent;

Step 602, establish an RPC server in each remote agent;

Step 603, the remote agent can send policy configuration information such as policy and report logs or monitoring information to the master agent through the RPC client;

Step 604: Send the above policy and policy configuration information such as report log or monitoring information to the management terminal through the master agent.

Specifically, the present invention establishes an RPC client through the master agent, and at the same time establishes an RPC server in each remoteagent. The RPC client communicates with each RPC server respectively, so that the remote agent can pass policy and report log or monitoring information and other policy configuration information through RPC client sends to masteragent.

Figure 7 is a schematic flowchart of the security protection component provided by the present invention for transmitting policy information. As shown in Figure 7, after the master agent uploads the policy configuration information to the management end, it also includes:

The management end matches the public protection policy set from the policy library according to the policy configuration information, and delivers the public protection policy set to the master agent; the master agent determines the label and remote agent of each protection policy in the public protection policy set. The intersection between the labels of existing protection policies is used as a public label; the master agent delivers the protection policy related to the public label to the remote namespace.

Specifically, after any remote agent sends the policy configuration information to the master agent, the master agent uploads the obtained policy configuration information to the management end.

At this time, for the management center, there is only one master agent that interacts with information, and it is responsible for issuing policies, sensing changes in containers under the namespace, sending and receiving logs, etc., while other remote agents only need to communicate with the master agent to achieve The management end performs comprehensive management of all remote agents through the master agent.

During the process of executing the above policy configuration management, when the master agent monitors that any remote namespace disappears, the remote agent will automatically exit. In other words, the remote agent will automatically create and exit following changes in the corresponding remote namespace, achieving a fully automated, transparent and insensitive state.

Figure 8 is the third flow diagram of the cross-namespace container security protection method provided by the present invention. As an optional embodiment, as shown in Figure 8, the specific processing method for remote agent security policy configuration management in the present invention can be Includes the following steps:

When the user starts a container resource, a new remote namespace will be created on the current network environment node accordingly. The master agent obtains the startup event by listening to the docker daemon process. The startup event will trigger the masteragent to start a remote agent (that is, the remote agent in Figure 8) for the container resource, which is responsible for maintaining the iptables rules and ipset of the remote namespace.

At the same time, the master agent contains a policy management service, which subscribes to policy events on the management side (the policy rules are sent to the master agent, which is called a policy event), and a policy library is pre-created on the management side. The policies are mainly divided into There are three modes: inbound mode, outbound mode, and two-way mode. The addition of policy library rules will be implemented through the management end.

Optionally, the management end mentioned in the above embodiment matches the public protection policy set from the policy library according to the policy configuration information, including the management end performing the following operations:

Based on the label matching algorithm, all protection policies in the policy library are initially screened; all protection policies obtained through the preliminary screening are cleaned to filter out empty protection policies and policies that do not match the remote namespace; according to For the policy configuration information, all the protection policies after cleaning are intersected and deduplicated to obtain a public protection policy set.

Since there are many policy rules in the policy library faced by the management end, the present invention uses a label matching algorithm and policy configuration information to match all protection policies associated with the remote agent that requests policy issuance from the policy library, and These protection strategies are constructed into a public protection strategy set and delivered to the master agent.

The cross-namespace container security protection method provided by the present invention uses the management end to perform a preliminary screening of all protection strategies in the policy library, and then the master agent further filters the set of public protection strategies obtained after the preliminary screening, which can improve the strategy. Configuration management efficiency.

Based on the contents of the above embodiments, as shown in Figure 8, as an optional embodiment, the management end matches the public protection policy set from the policy library according to the policy configuration information, which mainly includes but is not limited to execution by the management end. The following actions:

Based on the label matching algorithm, all protection policies in the policy library are initially screened; all protection policies obtained through the preliminary screening are cleaned to filter out empty protection policies and policies that do not match the remote namespace; according to For the policy configuration information, all the protection policies after cleaning are intersected and deduplicated to obtain a public protection policy set.

Specifically, when the management end receives a subscription request from the master agent, the management end will use the label matching algorithm to perform rule matching in the policy library to match the corresponding public protection policy set, and then use the matched public protection policy to All centralized policy rules are delivered to the agent for caching.

The label matching algorithm will traverse every protection policy in the policy library and discard the empty protection policies and the protection policies whose namespace does not match the remote agent.

As an optional embodiment, according to the policy configuration information, all the protection policies after cleaning are intersected and deduplicated to obtain the public protection policy set. Specifically, the master agent performs the following steps, including:

The master agent calculates the tag feature vector corresponding to each cleaned protection policy, and calculates the remote tag feature vector corresponding to the remoteagent tag; based on the distance between each policy tag feature vector and the remote tag feature vector and the predetermined Set the threshold comparison results to determine duplicate protection strategies among all protection strategies; filter out duplicate protection strategies from all protection strategies to obtain a public protection strategy set.

The master agent will further filter all the policy rules in the public protection policy set, and finally generate each remote agent that can be issued to the requested policy, including:

After receiving all the policy rules issued from the management side, the master agent first uses the labels of each policy rule and the labels of the remote agent to perform intersection deduplication processing; then, it uses the labels to filter out all policies that are not disabled.

It should be pointed out that whether it is policy rules, remote agent, or the container itself, it will be marked with labels. Intersection deduplication is to filter out identical tags and filter out the remaining tags that are not disabled.

Among them, the protection policy is divided into two states: enabled and disabled. Enabled means that the protection policy needs to be issued to take effect; disabled means that the protection policy does not need to be issued or is a issued protection policy.

Optionally, the present invention provides a specific execution method of the intersection deduplication algorithm, whose execution subject is Masteragent, which mainly includes but is not limited to the following steps:

(1) Policy label preprocessing: Read the union of subject and object of each protection policy label. Among them, Subject and object are fields in the protection policy, and each contains several tags. To clean the invalid values in the above tag protection policy, that is, to clean the invalid tags of all tags in a protection policy, for example, filter out only Key does not have such a label as value.

(2) Calculate the tag feature vector corresponding to the cleaned protection strategy: This invention expresses the frequency of occurrence of the protection strategy tag (the union obtained after cleaning in the previous step) in the form of a dictionary as {policytag: counts }.

Further, the label string (all characters of a protection policy label) is converted into a vector of length N in the form of 0 and 1 through the hash function, that is, expressed in dictionary form as {[01]{N}:counts} .

Next, 0 in the hash is mapped to -1, and then multiplied bitwise with the frequency of occurrence of the protection policy label, and the resulting feature vector set can be expressed as {[I(xn=1)-I((xn=0)] *counts|n∈(1,N)}.

Correspondingly, the same method is used to calculate the remote label feature vector corresponding to the remote agent's label.

(3) Calculate the distance between each protection policy label and the remote agent label:

According to the drawer principle, if the hash is divided into K+1 segments, then one segment of the repeated tags must have the same value. Based on this principle, the present invention corresponds to the tag feature vector related to each protection policy tag and the tag of the remote agent. After the bitwise XOR of the remote label feature vectors, the number of values is 1 is the distance between the two labels, that is

When the distance between a certain protection policy label and the label of the remote agent is less than or equal to the preset threshold, the protection policy label can be considered to be a duplicate label and will be deleted.

It should be noted that each protection policy label is issued from the management end, and the label of the remote agent can be directly read by the master agent.

In the cross-namespace container security protection method provided by the present invention, through the above two-level screening process, the protection strategies issued by the management end are screened and sorted out, and the protection strategies of the master agent and the remote agent created by it are obtained, so as to optimize policy distribution. the goal of.

Based on the content of the above embodiment, as an optional embodiment, the master agent delivers the protection policy related to the public label to the remote namespace, including the master agent performing the following operations:

Determine the policy mode of each protection policy related to the public label; if the policy mode is inbound mode, write the public label of the protection policy to the dst area; if the policy mode is outbound mode, write the public label of the protection policy to the dst area Write to the src area; if the policy mode is bidirectional mode, write the public label of the protection policy to the dst area and src area.

Further, if the policy mode of the protection policy is inbound mode, the target remote namespace is determined based on the matching degree between the label in the dst area and the label of each remoteagent, so that the target remote namespace can configure the protection policy to the remote In the agent's networksACL and xRules.

If the policy mode of the protection policy is outbound mode, determine the target remote namespace based on the matching degree between the label in the src area and the label of each remote agent, so that the target remote namespace can configure the protection policy to the remote agent. ApplicationACLs and xRules.

If the policy mode of the protection policy is bidirectional mode, determine the target remote namespace based on the matching degree between the labels in the dst area and src area and the labels of each remoteagent, so that the target remote namespace can configure the protection policy to networksACL, ApplicationACLs and xRules.

The cross-namespace container security protection method provided by the present invention finally determines the mode of each protection strategy. If a certain protection strategy is inbound mode, the protection label is written into dst (full name: destination, destination); if If a protection policy is in outbound mode, write the protection label in src (full name: source, source); if a protection policy is in bidirectional mode, write the protection policy label in both dst and src.

After all is completed, the master agent will deliver all protection policies to the remote agents with matching labels. Among them, if the policy label and the remote agent label are consistent, the two labels are considered to match.

Furthermore, when the remote agent receives the delivered protection policy, it will perform different operations based on the policy mode determined by the fields in the protection policy.

Specifically, after the protection policy is delivered, the process of finding the location of the remote agent that needs to be configured with the policy is as follows:

Inbound mode: When the mode matching the protection policy is inbound, the master agent will overall match the remote agent based on the protection policy label in dst. Since there are many remote agents, what we mean here is to match any protection policy label with the collection of all remote agents to lock the remote agent for which the policy needs to be configured.

After the protection policy reaches the remote agent, the remote agent will configure the protection policy into the networksACL and xRules of the remote agent.

Correspondingly, when the matched protection policy is in outbound mode, the master agent will match the remote agent as a whole based on the label in src to lock a certain remote agent for which the policy needs to be configured.

After the protection policy reaches the remote agent, it will configure the protection policy into ApplicationACLs and xRules.

Finally, if the matched protection policy is in bidirectional mode, the master agent will match all remote agents together based on the labels in dst and src.

After matching, the remote agent will configure the policy to networksACL, ApplicationACLs and xRules.

At this point, the entire policy issuance process is over.

The cross-namespace container security protection method provided by the present invention uses RPC to perform unified configuration of the mater agent to the remote agent. Through dynamic calculation of policies, the policies are deduplicated and filtered, and corresponding security policies for different containers are dynamically pulled. It realizes convenient security management of the remote management terminal for only one master agent, which improves the convenience of security policy issuance and security log collection, improves operation and maintenance efficiency, and facilitates the viewing and management of security events.

Figure 9 is a schematic structural diagram of the cross-namespace container security protection device provided by the present invention. As shown in Figure 9, it mainly includes a component deployment unit 91, a monitoring deployment unit 92, a space switching unit 93 and a protection control unit 94, where:

The component deployment unit 91 is mainly used to deploy the root namespace security protection component masteragent in the root namespace;

The monitoring and deployment unit 92 is mainly used to control the master agent to generate a remote namespace security protection component remote agent in the root namespace when the master agent detects that a new remote namespace is created on the current network environment node. ;

The space switching unit 93 is mainly used to switch the running space of the remote agent to the remote namespace;

The protection control unit 94 is mainly used to control the remote agent to perform security protection in the remote namespace, and to control the master agent to perform security protection in the root namespace.

Wherein, the security protection functions of the remote agent and the master agent are consistent.

It should be noted that the cross-namespace container security protection device provided by the embodiment of the present invention can execute the cross-namespace container security protection method described in any of the above embodiments during specific operation. This embodiment does not make any reference to this. Repeat.

The cross-namespace container security protection device provided by the present invention deploys a master agent and automatically generates a remote agent with the creation of the namespace, so as to realize that there is a remoteagent protection component under each remote namespace, and then intercepts and intercepts it through the NFQ mechanism. Corresponding to the communication traffic of containers in the namespace, it can effectively implement container security protection in different namespaces and within the namespace in the container environment.

Figure 10 is a schematic structural diagram of an electronic device provided by the present invention. As shown in Figure 10, the electronic device may include: a processor (processor) 1010, a communications interface (Communications Interface) 1020, a memory (memory) 1030 and a communication bus 1040. Among them, the processor 1010, the communication interface 1020, and the memory 1030 complete communication with each other through the communication bus 1040. The processor 1010 can call logical instructions in the memory 1030 to execute a cross-namespace container security protection method. The method includes: deploying the root namespace security protection component masteragent in the root namespace; monitoring the current network when the master agent When a remote namespace is newly created on the environment node, control the master agent to generate a remote namespace security protection component remoteagent in the root namespace; switch the running space of the remote agent to the remote namespace; Control the remote agent to perform security protection in the remote namespace, and control the master agent to perform security protection in the root namespace; the security protection functions of the remote agent and the master agent are consistent.

In addition, the above-mentioned logical instructions in the memory 1030 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program code. .

On the other hand, the present invention also provides a computer program product. The computer program product includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are read by a computer, When executed, the computer can execute the cross-namespace container security protection method provided by each of the above methods. The method includes: deploying the root namespace security protection component master agent in the root namespace; monitoring the current network environment in the master agent. When a remote namespace is newly created on the node, control the masteragent to generate a remote namespace security protection component remote agent in the root namespace; switch the running space of the remote agent to the remote namespace; control The remote agent performs security protection in the remote namespace and controls the master agent to perform security protection in the root namespace; the security protection functions of the remote agent and the master agent are consistent.

In another aspect, the present invention also provides a non-transitory computer-readable storage medium on which a computer program is stored. The computer program is implemented when executed by a processor to perform the cross-namespace container security protection provided by the above embodiments. Method, the method includes: deploying the root namespace security protection component master agent in the root namespace; when the master agent monitors that a remote namespace is newly created on the current network environment node, controlling the master agent to Generate a remote namespace security protection component remote agent in the root namespace; switch the running space of the remote agent to the remote namespace; control the remote agent to perform security protection in the remote namespace, and control all The master agent performs security protection in the root namespace; the security protection functions of the remote agent and the master agent are consistent.

The device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in One location, or it can be distributed across multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Persons of ordinary skill in the art can understand and implement the method without any creative effort.

Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the part of the above technical solution that essentially contributes to the existing technology can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., including a number of instructions to cause a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in various embodiments or certain parts of the embodiments.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that it can still be used Modifications are made to the technical solutions described in the foregoing embodiments, or equivalent substitutions are made to some of the technical features; however, these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims (10)

1. A cross-namespace container security protection method, which is characterized by including: Deploy the root namespace security protection component master agent in the root namespace; When the master agent detects that a remote namespace is newly created on the current network environment node, control the master agent to generate a remote namespace security protection component remoteagent in the root namespace; Switch the running space of the remote agent to the remote namespace; Control the remote agent to perform security protection in the remote namespace, and control the masteragent to perform security protection in the root namespace; The security protection functions of the remote agent and the master agent are consistent. 2. The cross-namespace container security protection method according to claim 1, characterized in that, the remote agent is controlled to perform security protection in the remote namespace, and the master agent is controlled to perform security protection in the root namespace. Implement security protection, including: Utilize the address translation management tool NFQ in the system kernel to introduce the data packets in the remote namespace to the remote agent respectively, so that the remote agent can perform security of the data packets in the remote namespace. protection; protection The NFQ is used to introduce the data packets in the root namespace to the master agent, so that the master agent can perform security protection on the data packets in the root namespace. 3. The cross-namespace container security protection method according to claim 1, characterized in that, after switching the running space of the remote agent to the remote namespace corresponding to the remote container, it further includes: Establish a remote procedure call client RPC client in the master agent, and establish a remote procedure call server RPC server in the remoteagent; Establish communication between the RPC client and the RPC server for the remote agent to send policy configuration information to the master agent; The master agent uploads the policy configuration information to the management terminal; The policy configuration information includes labels of existing protection policies, report logs, and monitoring information. 4. The cross-namespace container security protection method according to claim 3, characterized in that after the masteragent uploads the policy configuration information to the management end, it also includes: The management end matches a public protection policy set from the policy library according to the policy configuration information, and delivers the public protection policy set to the master agent; The master agent determines the intersection between the labels of each protection strategy in the public protection strategy set and the labels of the existing protection strategies in the remoteagent as a public label; The master agent delivers the protection policy related to the public label to the remote namespace. 5. The cross-namespace container security protection method according to claim 4, characterized in that the management end matches a public protection policy set from the policy library according to the policy configuration information, including the management end matching the public protection policy set from the policy library. The client performs the following operations: Based on the tag matching algorithm, perform a preliminary screening of all protection strategies in the strategy library; Clean all protection policies obtained through the preliminary screening to filter out empty protection policies and policies that do not match the remote namespace; According to the policy configuration information, all the cleaned protection policies are intersected and deduplicated to obtain the public protection policy set. 6. The cross-namespace container security protection method according to claim 5, characterized in that, according to the policy configuration information, all the protection policies after cleaning are intersected and deduplicated to obtain the public protection policy set, include: Calculate the label feature vector corresponding to each of the cleaned protection strategies, and calculate the remote label feature vector corresponding to the remote agent's label; Determine the duplicate protection strategy among all protection strategies based on the comparison result between the distance between each policy tag feature vector and the remote tag feature vector and the preset threshold; Filter out the duplicate protection policies from all protection policies to obtain the public protection policy set. 7. The container security protection method across namespaces according to claim 4, characterized in that the masteragent delivers the protection policy related to the public label to the remote namespace, including by the masteragent. Do the following: Determine the policy mode of each protection policy related to the public label; if the policy mode is the inbound mode, then write the public label of the protection policy to the dst area; if the policy mode is the outbound mode, then Write the public label of the protection strategy into the src area; if the policy mode is a bidirectional mode, write the public label of the protection strategy into the dst area and the src area; If the policy mode of the protection policy is the inbound mode, the target remote namespace is determined based on the matching degree between the tags in the dst area and the tags of each remoteagent, so that the target remote namespace can use the The protection policy is configured in the networksACL and xRules of the remote agent; If the policy mode of the protection policy is outbound mode, determine the target remote namespace based on the matching degree between the label in the src area and the label of each remoteagent, so that the target remote namespace can use the The protection policy is configured into the ApplicationACLs and xRules of the remote agent; If the policy mode of the protection policy is a two-way mode, the target remote namespace is determined based on the matching degree between the labels in the dst area and the src area and the labels of each remote agent for the target remote agent. The namespace configures the protection policy into networksACLs, ApplicationACLs, and xRules. 8. A cross-namespace container security protection device, characterized by including: The component deployment unit is used to deploy the root namespace security protection component master agent in the root namespace; A monitoring deployment unit is used to control the master agent to generate a remote namespace security protection component remote agent in the root namespace when the master agent detects that a new remote namespace is created on the current network environment node; A space switching unit, used to switch the running space of the remote agent to the remote namespace; A protection control unit, used to control the remote agent to perform security protection in the remote namespace, and to control the master agent to perform security protection in the root namespace; The security protection functions of the remote agent and the master agent are consistent. 9. An electronic device, comprising a processor and a memory storing a computer program, characterized in that when the processor executes the computer program, the cross-namespace container security described in any one of claims 1 to 7 is achieved. Steps of protective methods. 10. A non-transitory computer-readable storage medium with a computer program stored thereon, characterized in that when the computer program is executed by a processor, the cross-namespace storage method as described in any one of claims 1 to 7 is implemented. Steps for container security methods.