CN111741010A

CN111741010A - Docker operation request processing method and device based on proxy and computing equipment

Info

Publication number: CN111741010A
Application number: CN202010684330.2A
Authority: CN
Inventors: 贺毅; 高斌; 杜雄
Original assignee: Beijing Shengxin Network Technology Co ltd
Current assignee: Beijing Shengxin Network Technology Co ltd
Priority date: 2020-07-16
Filing date: 2020-07-16
Publication date: 2020-10-02
Anticipated expiration: 2040-07-16
Also published as: CN111741010B

Abstract

The embodiment of the invention provides a method and a device for processing a Docker operation request based on an agent, a readable storage medium and a computing device, which can finely analyze and detect the Docker operation request, meet the container security requirements of user access control, malicious process detection and the like, and improve the security of container operation, and the method comprises the following steps: receiving a first Docker operation request sent by a container Docker client; analyzing a request head and a request body of the first Docker operation request to generate a detectable second Docker operation request; detecting whether the second Docker operation request meets a preset blocking rule, and if so, returning a request rejection message to the Docker client; otherwise, forwarding the first Docker operation request to the Docker server; and after forwarding the first Docker operation request to the Docker server, receiving response information of the Docker server to the first Docker operation request, and forwarding the response information to the Docker client.

Description

Docker operation request processing method and device based on proxy and computing equipment

Technical Field

The invention relates to the technical field of computer containers, in particular to a method and a device for processing a Docker operation request based on an agent, a readable storage medium and a computing device.

Background

A Docker container is a framework of a Client-Server (CS) architecture, and a Docker in common includes two parts, one part is a Client, i.e., a Docker Client, and the other part is a Server, i.e., a container mirror (Docker Daemon), which communicate through a Representational state transfer (REST) Application Programming Interface (API). The REST API is based on the HyperText Transfer Protocol (HTTP) Protocol, which provides natural support for the intermediate layer-based HTTP proxy. When a Docker is used, the inside of the executed commands such as Docker run and Docker ps can be converted into an HTTP request, and each requested resource has a Docker API corresponding to the resource. Therefore, all Docker requests can be intercepted through the HTTP proxy technology, and are further associated with corresponding Docker APIs through analyzing resources in the requests. For example, when the format of the request is found to be (POST/contacts/create), it is known that this is a request for creating a container, and it can be selected to forward the request Docker Daemon or discard, i.e. block the creation of the container, according to the service requirement.

Blocking a Docker container essentially blocks execution of the Docker API, which itself supports an Authorization plug-in (Authorization plugins) mechanism. The authorization plug-in can realize user access control based on authority, and the technical principle is that when a Docker Client terminal sends a Docker request, the Docker Daemon analyzes the request and then forwards HTTP header information of the request to the authorization plug-in, the authorization plug-in can generate an authorization passing or refusing reply after auditing, when the authorization passes, the Docker Daemon continues subsequent processing, and when the authorization result is refusing, the Docker Daemon directly returns an error to the Client and returns the reason of refusing. This is the case with the current twist lock authzblank plug-in.

Authorization plugins of Docker is access control based on rights, where the rights only aim at different users and cannot meet the more refined requirement of blocking a container aiming at requested content. For a container, it is relative, or custom, to determine whether it is malicious. For example, some clients need to limit that common users cannot create new containers, and only need to limit the authorization plug-in unit to not give the common users the right to create the containers; when the client needs to define that some binary files, such as curl, bash, etc., are not allowed to be launched in the container, the authorization plug-in cannot be implemented.

Disclosure of Invention

To this end, the present invention provides a broker-based Docker operation request processing method, apparatus, readable storage medium, computing device, in an effort to solve or at least mitigate at least one of the problems identified above.

According to an aspect of the embodiments of the present invention, a method for processing a Docker operation request based on a proxy is provided, including:

receiving a first Docker operation request sent by a Docker client;

analyzing a request head and a request body of the first Docker operation request to generate a detectable second Docker operation request;

detecting whether the second Docker operation request meets a preset blocking rule, and if so, returning a request rejection message to the Docker client; otherwise, forwarding the first Docker operation request to a Docker server;

after the first Docker operation request is forwarded to the Docker server, receiving response information of the Docker server to the first Docker operation request, and forwarding the response information to the Docker client.

Optionally, parsing a request header and a request body of the first Docker operation request to generate a detectable second Docker operation request, including:

determining a Docker command corresponding to the first Docker operation request according to a request head and a request body of the first Docker operation request;

extracting information of a specified field from the Docker command;

and storing the information of the specified field as a file with a specified format to obtain a detectable second Docker operation request.

Optionally, the information of the specified field includes:

docker operation, mirror image label and mirror image identification; alternatively, the first and second electrodes may be,

docker operation, mirror image label, mirror image identification, process name and process parameter; alternatively, the first and second electrodes may be,

user name, Docker operation, mirror image label, mirror image identification.

Optionally, the specified format is a json format.

Optionally, detecting whether the second Docker operation request meets a preset blocking rule includes:

analyzing the file with the specified format to acquire the information of the specified field;

determining whether the information of the designated field is matched with a preset blocking rule file; wherein the blocking rule file includes logical relationships between a plurality of specified fields constrained with a first key and the contents of a single specified field constrained with a second key.

Optionally, determining whether the information of the specified field matches a preset blocking rule file includes:

traversing the blocking rule file, taking each traversed first keyword as a root node of the current level, and taking contents on two sides of the first keyword as a left sub-tree and a right sub-tree of the next level respectively; for each subtree, using the data associated with the traversed second keyword as node elements to obtain a binary tree;

matching the information of the designated field with the binary tree node by node, and when any node is determined to be not successfully matched, determining that the second Docker operation request does not accord with a preset blocking rule; and when all the nodes are successfully matched, determining that the second Docker operation request conforms to a preset blocking rule.

Optionally, the first keyword includes: and or;

the second keyword includes: = and in; alternatively, the first and second electrodes may be,

the second keyword includes: and at least one of = in, begin, end, find, and matches.

According to still another aspect of an embodiment of the present invention, there is provided a container Docker operation request processing apparatus based on a broker, including:

the request agent unit is used for receiving a first Docker operation request sent by a Docker client;

the request analysis unit is used for analyzing a request head and a request body of the first Docker operation request and generating a detectable second Docker operation request;

a request detection unit, configured to detect whether the second Docker operation request meets a preset blocking rule, and if so, return a request rejection message to the Docker client through the request proxy unit; otherwise, forwarding the first Docker operation request to a Docker server through the request agent unit;

the request agent unit is further configured to forward the first Docker operation request to the Docker server, receive response information of the Docker server to the first Docker operation request, and forward the response information to the Docker client.

According to still another aspect of the present invention, there is provided a readable storage medium having executable instructions thereon, which when executed, cause a computer to perform the above-described proxy-based container Docker operation request processing method.

According to yet another aspect of the present invention, there is provided a computing device comprising: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors to perform the above-described proxy-based container Docker operation request processing method.

According to the technical scheme provided by the embodiment of the invention, a first Docker operation request sent by a container Docker client is received, a request head and a request body of the first Docker operation request are analyzed, a detectable second Docker operation request is generated, whether the second Docker operation request accords with a preset blocking rule or not is detected, if yes, a message of rejecting the request is returned to the Docker client, otherwise, the first Docker operation request is forwarded to a Docker server, after the first Docker operation request is forwarded to the Docker server, response information of the Docker server to the first Docker operation request is received, and the response information is forwarded to the Docker client; the method comprises the steps of simultaneously analyzing a request head and a request body of a Docker operation request, obtaining complete Docker operation information, converting the complete Docker operation information into a detectable second Docker operation request, and further detecting, so that the requirements of user access control and malicious process detection are met, and the safety of a Docker environment is improved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the invention and together with the description serve to explain the principles of the invention.

FIG. 1 is a block diagram of an exemplary computing device;

FIG. 2 is a flowchart of a method for proxy-based Docker operation request processing, according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of a binary tree structure according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of a system communication model according to an embodiment of the present invention;

fig. 5 is a schematic structural diagram of a broker-based Docker operation request processing apparatus according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

Fig. 1 is a block diagram of an example computing device 100 arranged to implement a broker-based Docker operation request processing method in accordance with the present invention. In a basic configuration 102, computing device 100 typically includes system memory 106 and one or more processors 104. A memory bus 108 may be used for communication between the processor 104 and the system memory 106.

Depending on the desired configuration, the processor 104 may be any type of processing, including but not limited to: a microprocessor (μ P), a microcontroller (μ C), a digital information processor (DSP), or any combination thereof. The processor 104 may include one or more levels of cache, such as a level one cache 110 and a level two cache 112, a processor core 114, and registers 116. The example processor core 114 may include an Arithmetic Logic Unit (ALU), a Floating Point Unit (FPU), a digital signal processing core (DSP core), or any combination thereof. The example memory controller 118 may be used with the processor 104, or in some implementations the memory controller 118 may be an internal part of the processor 104.

Depending on the desired configuration, system memory 106 may be any type of memory, including but not limited to: volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. System memory 106 may include an operating system 120, one or more programs 122, and program data 124. In some implementations, the program 122 can be configured to execute instructions on an operating system by one or more processors 104 using program data 124.

Computing device 100 may also include an interface bus 140 that facilitates communication from various interface devices (e.g., output devices 142, peripheral interfaces 144, and communication devices 146) to the basic configuration 102 via the bus/interface controller 130. The example output device 142 includes a graphics processing unit 148 and an audio processing unit 150. They may be configured to facilitate communication with various external devices, such as a display terminal or speakers, via one or more a/V ports 152. Example peripheral interfaces 144 may include a serial interface controller 154 and a parallel interface controller 156, which may be configured to facilitate communication with external devices such as input devices (e.g., keyboard, mouse, pen, voice input device, touch input device) or other peripherals (e.g., printer, scanner, etc.) via one or more I/O ports 158. An example communication device 146 may include a network controller 160, which may be arranged to facilitate communications with one or more other computing devices 162 over a network communication link via one or more communication ports 164.

A network communication link may be one example of a communication medium. Communication media may typically be embodied by computer readable instructions, data structures, program modules, and may include any information delivery media, such as carrier waves or other transport mechanisms, in a modulated data signal. A "modulated data signal" may be a signal that has one or more of its data set or its changes made in such a manner as to encode information in the signal. By way of non-limiting example, communication media may include wired media such as a wired network or private-wired network, and various wireless media such as acoustic, Radio Frequency (RF), microwave, Infrared (IR), or other wireless media. The term computer readable media as used herein may include both storage media and communication media.

Computing device 100 may be implemented as part of a small-form factor portable (or mobile) electronic device such as a cellular telephone, a Personal Digital Assistant (PDA), a personal media player device, a wireless web-watch device, a personal headset device, an application specific device, or a hybrid device that include any of the above functions. Computing device 100 may also be implemented as a personal computer, a server, a cluster of multiple computers, including both desktop and notebook computer configurations.

Among other things, one or more programs 122 of computing device 100 include instructions for performing a broker-based Docker operation request processing method in accordance with the present invention.

Fig. 2 illustrates a flowchart of a broker-based Docker operation request processing method 200 according to an embodiment of the present invention, the broker-based Docker operation request processing method 200 beginning at step S210.

In step S210, a first Docker operation request sent by a Docker client is received. In this step, a Docker operation request sent by the Docker client to the Docker server is obtained through an HTTP proxy technology, so as to facilitate subsequent analysis and detection.

Subsequently, in step S220, the request header and the request body of the first Docker operation request are parsed, and a detectable second Docker operation request is generated.

In this step, a request header (head) and a request body (body) of a Docker operation request (HTTP request) are analyzed, and more complete request content can be obtained compared to an Authorization plugin mechanism, so that blocking processing can be performed on a container more finely according to the request content. While the Docker itself supports the Authorization plugins, the bottom layer only forwards the user of the Docker request and the HTTP header information of the request to the plug-in, and the requested content (request body) is not forwarded, the Authorization plugins can only identify the type of the request, such as creating a container or executing a command, and for specific content, such as what command is executed and what parameters are used, the Authorization plugins cannot be obtained, so that the requirement of blocking the container for the requested content cannot be more refined.

Further, step S220 includes:

extracting information of a specified field from the Docker command;

In the embodiment of the invention, specific Docker command content is analyzed according to an HTTP request header and a request body, so that a container can be detected and blocked in a refined manner aiming at the request content, and in order to realize subsequent detection operation, the Docker command content needs to be converted into detectable intermediate language, namely, a file which is stored in a specified format and contains information of specified fields.

Optionally, in the process of analyzing specific Docker command content according to the HTTP request header and the request body, key Docker command information is extracted by using a regular matching method.

Optionally, the information specifying the field includes:

user name, Docker operation, mirror image label, mirror image identification.

The field information obtained under different scenes is different. For example, if the access right of the user needs to be controlled, the extracted fields include a user name (user), a Docker operation (action), a mirror tag (image _ name), and a mirror identifier (image _ id); if malicious process detection is required and the HTTP request body is empty, the extracted fields comprise an action, an image _ name and an image _ id; when the HTTP request body is not empty, the extracted fields include action, image _ name, image _ id, process name (proc _ name), and process parameters (proc _ args).

Optionally, the extracted field information is stored by using a json (lightweight data exchange) format, and the json format is easy to analyze and is convenient for detection processing of subsequent steps.

Subsequently, in step S230, detecting whether the second Docker operation request meets a preset blocking rule, and if so, returning a request rejection message to the Docker client; otherwise, forwarding the first Docker operation request to the Docker server.

Further, detecting whether the second Docker operation request meets a preset blocking rule includes:

The file with the specified format can be a json file; the blocking rule file may be a yaml file.

Further, determining whether the information of the specified field matches a preset blocking rule file includes:

For example, in the process of traversing the blocking rule file, the blocking rule file may be traversed from left to right, when a first keyword is read, the first keyword is used as a root node of the binary tree, content on the left side of the first keyword is used as a left sub-tree of the binary tree, content on the right side of the first keyword is used as a right sub-tree of the binary tree, if the first keyword is encountered again, a new root node is established at a next stage of the established root node, and left and right sub-trees of the new root node continue to be generated; the first key includes being and, or. When traversing to a second key, taking data associated with the second key as a node element, wherein the second key can be =, in, or =, in, and at least one of begin, end, find, and matches; the method comprises the steps of matching a string with a certain string as a starting condition, matching an end with a certain string as an ending condition, matching a find with a certain string as a finishing condition, and matching a match with a match result.

Optionally, the node contents of the binary tree include two types, the data structure of the first type node includes a type (type) and an operation (op), and the data structure of the second type node includes a type (type), a key (key) and a value (value); type includes rule (rule) and operation (operator), and op includes: and, or; the key comprises: action, image _ name, image _ id, proc _ name, proc _ args and user; value is the specific content corresponding to the key.

After a binary tree is established based on a blocking rule file, according to the progressive matching of the analysis result of the json file and the binary tree, equivalently performing one-time depth traversal on the binary tree; the matching mode realizes that the traversal process needs to be completely executed only when the Docker operation request completely conforms to the blocking rule file, and the matching can be interrupted in time when the Docker operation request does not conform to or partially conforms to the blocking rule file, so that the matching efficiency is improved.

Subsequently, in step S240, after the first Docker operation request is forwarded to the Docker server, response information of the Docker server to the first Docker operation request is received, and the response information is forwarded to the Docker client.

The technical content of the present invention will be exemplarily described below with reference to specific scenarios from an engineering perspective. In a specific embodiment of the present invention, a proxy-based Docker API detection and blocking system is provided, including an HTTP proxy module, a parsing module, and a container detection engine.

First, HTTP Proxy Module (Proxy Module).

The module works between a Docker Client and a Docker Daemon, and specifies a remote access address of the Docker Client by setting an environment variable Docker _ HOST, so that the Docker Client is connected to the agent module. After receiving the HTTP request, the proxy needs to perform local audit, and forwards the request to the Docker Daemon after the HTTP request passes the local audit. Otherwise, an error is directly returned to block the request.

And secondly, an analysis Module (matching Module).

After receiving the request of the Docker Client, the HTTP proxy forwards the request to the REST API analysis module. The module is mainly responsible for the function of "parsing and translating" of data, establishes a corresponding relationship with a specific Docker operation according to resource information of a request header, and parses a body part (if any) of the request, which may contain some operation information executed in a container, such as running a curl command in the container.

Such as when the parsing module receives a request:

GET /v1.24/images/user_test:1.0/json HTTP/1.1

by regular matching: "/images/(+)/json" will know that this is a request to query the mirror user _ test:1.0 information, corresponding to the command docker insert user _ test: 1.0. The key information that can be obtained from the command is that the operation is docker insert, and the operation object, namely the mirror name, is user _ test: 1.0. Since the command has only a request header and does not contain a request body, there are no proc _ name and proc _ args fields. Shown in json format, converted "intermediate" languages

{

"action": "image_inspect",

"image_name": "user_test:1.0",

}

The information acquired under different user scenarios is different, and supported keywords include action (specific docker operation), image _ name (mirror tag), image _ id (mirror id), proc _ name (process name), proc _ args (process parameters), and user, where proc _ name and proc _ args need to be acquired through a request body of an HTTP message. Based on the authority control of user access, mainly use user, action, image _ name, image _ id, etc., and the malicious process detection in the container mainly uses action, image _ name, image _ id, proc _ name, proc _ args, etc.

The parsed "intermediate language" is then forwarded to the container detection engine, where an audit is performed at the engine level to decide whether to pass or block the current request. For the auditing function of the Docker API, the auditing function is also in the module, and the analysis module records the request after analyzing the request and then forwards the request to the container detection engine.

And thirdly, a container Detection Engine (Detection Engine).

The container detection engine is the core of the system, and the engine carries out rule matching based on configuration files currently, and a rule file in a yaml format is designed currently. As follows

Rule-execution of the curl command when the boot image ubuntu _ test is not allowed

condition: action = create and image_name in {ubuntu_test} and proc_name= curl

The detection engine will generate different syntax trees according to the rules of the configured yaml file, and the process is to construct a binary tree. When the first keyword "and" or "is read, the first keyword is used as the root node of the binary tree, the content in front of the node is used as the left subtree of the binary tree, and the content behind the node is used as the right subtree. When processing the right subtree, if the keywords "and" or "are encountered again, a new" root "node is created, and the left and right subtrees are processed continuously. The process is equivalent to constructing a binary tree in a manner of preorder traversal, and a new root node is generated when the key word ' and ' or ' is encountered. Other keys, such as "=", "in", etc., are stored as node elements in the node together with the corresponding key. Such as the rules above, the "syntax tree" is generated as shown in fig. 3.

The parsing module will translate an HTTP request into an "intermediate language" that the engine can recognize. After receiving the data, the detection engine matches with each record configured in the rule, and the matching process is actually a depth traversal of a binary tree. As shown in FIG. 3, when traversing the root node A, according to type and op, it can be known that this is an operator and, at this time, the left subtree and the right subtree are required to return true at the same time, and the whole matching result is true. And after traversing the root node A, traversing the node B next step, knowing that the node B is a rule according to the type of the node B, comparing the key and the value of the node B with the data transmitted by the analysis module, and continuously traversing the right subtree node C of the root node A if the key and the value are compared. If the node B is not compared, the false is directly returned according to the and semantics without traversing the node C. In addition to supporting exact matching such as "in", "" = ", fuzzy matching such as" begin "(beginning with a certain string)," end "(ending with a certain string)," find "(containing a certain string)," matches "(regular matching) is also supported.

The data transmitted by the current analysis module is considered as a malicious operation when being matched with the rule, and then the result is notified to the HTTP proxy module to execute the blocking operation, namely the Client error is directly returned, so that the blocking purpose is achieved. The user access control and the container malicious process detection adopt the same yaml format file. The difference is that the user access control is based on the control of the user access authority, and the configuration is that the user and each Docker API interface associated with the user limit the Docker API which can be used by the user. And the malicious process detection in the container limits the processes which are not allowed to be started in the container according to the user requirements. When the system detects that the current request is to start the operation of the container, the system further detects that the used mirror image does not contain a known leak, so that the aim of blocking the malicious container is fulfilled.

FIG. 4 illustrates an interaction process of the broker-based Docker API detection and blocking system, including:

a. the method comprises the steps that a Docker Client sends an HTTP request to a Proxy Module, and the specific content is a Docker operation request;

b. parsing Module analyzes HTTP head and HTTP body to generate json format data describing request content;

c. detecting Engine acquires json format data and judges whether the json format data is a malicious process or illegal access; if the judgment result is yes, executing the step d, otherwise, executing the step e;

d. sending an HTTP reply message to the Docker Client, and rejecting the request; finishing;

e. forwarding the original HTTP request to a Docker Daemon;

f. receiving response information returned by the Docker Daemon;

g. forwarding the response information to the Docker Client; and (6) ending.

The system operation is described below with respect to disabling the launching of a user _ test mirrored container:

1. the Docker Client configures Docker _ HOST configuration variables including the address and port of the HTTP proxy module (proxymodule).

2. And (3) configuring detection rules in the detection engine:

rule not allowing mirror user _ test to start the container

condition: action = create and image_name in {user_test}。

3. The Docker Client executes the command to start the container: docker run-it user _ test: 1.0/bin/bash.

After receiving the request, the HTTP proxy module (proxy module) parses the parameters and contents of the request, parses the request into an intermediate description language, and then passes the intermediate description language to a container Detection Engine (Detection Engine), where the intermediate description language is as follows:

{

"action": "create",

"image_name": "user_test:1.0",

"proc_name" : "/bin/bash"

}。

4. and loading the configured rule file by a malicious container Detection Engine (Detection Engine), comparing the received intermediate language data with the content configured in the rule, and when the intermediate language data is matched with the content configured in the rule, indicating that the malicious content is detected, and directly returning an HTTP deny message to the Client terminal of the Docker, so that the current container creation operation can be blocked. If not, indicating that the request is not malicious, the HTTP proxy module (proxy module) is notified to forward the request to DockerDeemon for execution.

The technical scheme provided by the specific embodiment of the invention not only can detect the blocking of the specific mirror image starting container, but also can detect the binary file started in the blocking container. The capability of detecting the malicious container is expanded, and the method can be better suitable for the current production environment. In addition, the technical scheme of the specific embodiment of the invention adopts an independent module design, and can be conveniently integrated into the existing container safety product.

Referring to fig. 5, an apparatus for processing a container Docker operation request based on a proxy according to an embodiment of the present invention includes:

a request agent unit 510, configured to receive a first Docker operation request sent by a Docker client;

a request analyzing unit 520, configured to analyze a request header and a request body of the first Docker operation request, and generate a detectable second Docker operation request;

a request detecting unit 530, configured to detect whether the second Docker operation request meets a preset blocking rule, and if so, return a request rejecting message to the Docker client through the request proxy unit 510; otherwise, the first Docker operation request is forwarded to the Docker server through the request agent unit 510;

the request proxy unit 510 is further configured to forward the first Docker operation request to the Docker server, receive response information of the Docker server to the first Docker operation request, and forward the response information to the Docker client.

Optionally, the request parsing unit 520 is specifically configured to:

extracting information of a specified field from the Docker command;

Optionally, the request detecting unit 530 is specifically configured to:

Optionally, the request detecting unit 530 is configured to, when determining whether the information of the specified field matches a preset blocking rule file, specifically:

For specific limitations of the proxy-based Docker operation request processing apparatus, reference may be made to the above limitations of the proxy-based Docker operation request processing method, which is not described herein again.

According to the technical scheme provided by the invention, an HTTP proxy technology is adopted to intercept all Docker requests, coarse-grained access control can be realized based on header information of the Docker Client requests, and more refined detection can be performed based on request body contents of the Docker Client requests, so that the detection requirements of 'malicious' containers in various scenes can be detected, and the 'malicious' containers can be blocked on the basis. According to a security application scene, the system provides four functional modules of user access control, Docker API audit, malicious process detection in a container and malicious container blocking. Enabling user access control refers to limiting the Docker API rights that a user can use. Docker API auditing is the recording of all user Docker API requests for analysis of potentially "malicious" operations. The detection of the malicious process in the container refers to detecting the process starting behavior in the container, and is limited in the container, so that some 'dangerous' processes cannot be started, for example, binary files, curl external addresses and the like are installed in the container. Malicious container blocking refers to the detection of a leaky image that does not allow the container to be started or blocked if malicious behavior is detected.

It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, alternatively, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.

In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Wherein the memory is configured to store program code; the processor is configured to perform the various methods of the present invention according to instructions in the program code stored in the memory.

By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer-readable media includes both computer storage media and communication media. Computer storage media store information such as computer readable instructions, data structures, program modules or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of computer readable media.

It should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the invention and aiding in the understanding of one or more of the various inventive aspects. However, the method of the invention should not be construed to reflect the intent: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing inventive embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Those skilled in the art will appreciate that the modules or units or components of the apparatus in the examples invented herein may be arranged in an apparatus as described in this embodiment or alternatively may be located in one or more apparatuses different from the apparatus in this example. The modules in the foregoing examples may be combined into one module or may be further divided into multiple sub-modules.

Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features of the invention in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so invented, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature of the invention in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments may be used in any combination.

Furthermore, some of the described embodiments are described herein as a method or combination of method elements that can be performed by a processor of a computer system or by other means of performing the described functions. A processor having the necessary instructions for carrying out the method or method elements thus forms a means for carrying out the method or method elements. Further, the elements of the apparatus embodiments described herein are examples of the following apparatus: the apparatus is used to implement the functions performed by the elements for the purpose of carrying out the invention.

As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this description, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the appended claims. The present invention is to be considered as illustrative and not restrictive in character, with the scope of the invention being indicated by the appended claims.

Claims

1. A Docker operation request processing method based on proxy is characterized by comprising the following steps:

receiving a first Docker operation request sent by a container Docker client;

2. The method of claim 1, wherein parsing a request header and a request body of the first Docker operation request to generate a detectable second Docker operation request comprises:

extracting information of a specified field from the Docker command;

3. The method of claim 2, wherein the information specifying the fields comprises:

user name, Docker operation, mirror image label, mirror image identification.

4. The method of claim 2, wherein the specified format is a json format.

5. The method of claim 2, wherein detecting whether the second Docker operation request complies with a preset blocking rule comprises:

6. The method of claim 5, wherein determining whether the information of the specified field matches a preset blocking rule file comprises:

7. The method of claim 6,

the first keyword comprises: and or;

8. An agent-based container Docker operation request processing apparatus, comprising:

9. A readable storage medium having executable instructions thereon that, when executed, cause a computer to perform the method as included in any one of claims 1-7.

10. A computing device, comprising:

one or more processors;

a memory; and

one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors to perform the method as recited in any of claims 1-7.