Container information acquisition method and device, electronic equipment and storage medium

Abstract

The invention provides a container information obtaining method and device, electronic equipment and a storage medium, the container information obtaining method comprises the steps that a namespace of target equipment, a namespace of a target process running in the target equipment and feature information of a control group running the target process are obtained, and the feature information comprises a target container ID; determining the type of the target process based on the namespace of the target device and the namespace of the target process; and if the type of the target process is a container process, obtaining basic information of a target container to which the target container ID belongs based on the target container ID. By adopting the method provided by the invention, potential errors of network delay and API calling can be effectively avoided, and the real-time performance and accuracy of container information acquisition are improved.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a container information acquisition method, device, electronic device and storage medium. Background Art

[0002] In the related art, the method of obtaining the basic information of the container running in the device usually requires first knowing the Restful API (API, Application Programming Interface, Application Programming Interface, Restful API representational state transfer application program interface) provided by the target container platform or management tool, so as to send a request including necessary authentication information (such as API key or token) and request parameters (such as container ID or name) to the API. After receiving the request, the server to which the API belongs will return a corresponding response, which usually contains detailed information of the container, such as container status, configuration, resource usage, etc. The client needs to parse the response content and extract the required basic container information. However, using this method to obtain the basic information of the container running in the device will cause network delays and potential errors in API calls, which will lead to poor real-time performance and inaccuracy when obtaining the basic information of the container. Summary of the invention

[0003] In view of the above problems, the present application provides a container information acquisition method, device, electronic device and storage medium, which can effectively avoid network delays and potential errors in API calls, and improve the real-time and accuracy of container information acquisition.

[0004] The embodiment of the present application is implemented by adopting the following technical solutions:

[0005] In a first aspect, an embodiment of the present application provides a method for obtaining container information, the method comprising: obtaining a namespace of a target device, a namespace of a target process running in the target device, and characteristic information of a control group running the target process, the characteristic information comprising a target container ID; determining a type of the target process based on the namespace of the target device and the namespace of the target process; if the type of the target process is a container process, obtaining basic information of the target container to which the target container ID belongs based on the target container ID.

[0006] In a second aspect, an embodiment of the present application provides a container information acquisition device, the device comprising: a first information acquisition module, used to acquire the namespace of a target device, the namespace of a target process running in the target device, and characteristic information of a control group running the target process, the characteristic information comprising a target container ID; a process type determination module, used to determine the type of the target process based on the namespace of the target device and the namespace of the target process; and a container information acquisition module, used to obtain basic information of the target container to which the target container ID belongs based on the target container ID when the type of the target process is a container process.

[0007] In some embodiments, the process type determination module is further used to match the namespace of the target device with the namespace of the target process to obtain a matching result; determine the type of the target process according to the matching result, wherein, when the namespace of the target device matches the namespace of the target process, the type of the target process is a non-container process; when the namespace of the target device does not match the namespace of the target process, the type of the target process is a container process.

[0008] In some embodiments, there are multiple namespaces, each of which is of a different type; the process type determination module is further used to match the multiple namespaces of the target device with the namespaces of the same type in the multiple namespaces of the target process to obtain a matching result for each type of namespace; if there is at least one type of namespace whose matching result is a mismatch, the type of the target process is determined to be a container process.

[0009] In some implementations, the container information acquisition module is further used to search for configuration information corresponding to the target container ID from configuration information corresponding to a plurality of ID containers pre-stored in the target device.

[0010] In some implementations, the basic information of the target container to which the target container ID belongs includes the root directory of the container, the image ID of the container, and the container type.

[0011] In some embodiments, the device further includes a process copy module, a directory modification module, a second information acquisition module, a process adjustment module, and an asset information acquisition module. The process copy module is used to copy the container management process in the target device to obtain a child process of the container management process; the directory modification module is used to modify the root directory of the child process to the root directory of the target container to obtain a first child process; the second information acquisition module is used to obtain the environment variables and information acquisition files in the target container by the first child process; the process adjustment module is used to adjust the environment variables of the first child process to the environment variables in the target container to obtain the target child process; the asset information acquisition module is used to obtain the basic asset information of the target container by the target child process based on the information acquisition file.

[0012] Furthermore, the information acquisition file includes a command execution file and a soft link, and an asset information acquisition module, which is used for the target child process to execute the command execution file to obtain a command execution result, and the target child process to parse the soft link to obtain a parsing result; and obtain the basic asset information of the target container from the command execution result and the file pointed to by the parsing result.

[0013] In some implementations, the process replication submodule is used to call the container management process in the target device through a system call function to create a child process of the container management process.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, the electronic device comprising: one or more processors; a memory; 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, and the one or more programs are configured to execute the above-mentioned container information acquisition method.

[0015] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a program code, and the program code can be called by a processor to execute the above-mentioned container information acquisition method.

[0016] The container information acquisition method, device, electronic device and storage medium provided in the embodiments of the present application; obtain the namespace of the target device, the namespace of the target process running in the target device, and the characteristic information of the control group running the target process, wherein the characteristic information includes the target container ID; determine the type of the target process based on the namespace of the target device and the namespace of the target process; if the type of the target process is a container process, obtain the basic information of the target container to which the target container ID belongs based on the target container ID. By adopting the method provided by the present application, the container information acquisition process is executed only on the target device, without calling the API through a request, thus effectively avoiding network delays and potential errors in API calls, and improving the real-time and accuracy of container information acquisition.

[0017] These and other aspects of the present application will become more clearly understood in the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0019] Figure 1 It is a flowchart of a method for obtaining container information provided in an embodiment of the present application.

[0020] Figure 2 It is a schematic diagram of basic information of a target container provided in an embodiment of the present application.

[0021] Figure 3 This is another flowchart of a method for obtaining container information provided in an embodiment of the present application.

[0022] Figure 4 This is another flowchart of a method for obtaining container information provided in an embodiment of the present application.

[0023] Figure 5 This is another flowchart of a method for obtaining container information provided in an embodiment of the present application.

[0024] Figure 6 This is another flowchart of a method for obtaining container information provided in an embodiment of the present application.

[0025] Figure 7 It is a schematic diagram of Web site asset information of a target container provided in an embodiment of the present application.

[0026] Figure 8It is a schematic diagram of a container information acquisition device provided in an embodiment of the present application.

[0027] Fig. 9 It is a schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be understood as limiting the present application.

[0029] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application.

[0030] Before describing the embodiments of the present application, the terms mentioned in the present application are explained as follows:

[0031] Container: In computing, a container is a lightweight virtualization technology that allows developers to package an application and its dependencies into a portable unit that can run in any environment that supports containers without having to worry about the underlying operating system or hardware details. This allows applications to run in different environments without having to worry about the differences between the environments.

[0032] Namespace is a mechanism provided by the Linux kernel to achieve isolation between processes. By using different namespaces, a group of processes can only see the resources belonging to their own namespace and cannot access resources in other namespaces. This isolation mechanism provides the basis for containerization, virtualization and system security.

[0033] The control group of running processes is a physical resource isolation mechanism provided by the Linux kernel. It is mainly used to limit, record, and isolate the physical resources (such as CPU, memory, input and output interfaces, etc.) used by a group of processes or threads. It achieves the purpose of controlling the available resources of a group of processes by placing a group of processes into a control group and allocating specific available resources to the control group. A control group is a group of processes divided according to certain standards. A process can be added to a control group or migrated from one control group to another. The resources allocated to processes in a control group are also subject to restrictions set for the control group. In addition, the control group can also perform operations such as suspending and resuming on the process group to control the process.

[0034] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0035] like Figure 1 , Figure 1 A flowchart of a method for obtaining container information provided in an embodiment of the present application, the method comprising:

[0036] Step S110: Acquire the namespace of the target device, the namespace of the target process running in the target device, and characteristic information of the control group running the target process, wherein the characteristic information includes the target container ID.

[0037] The target device is any device that needs to collect container information, and the target process is at least one process among multiple processes currently running in the target device that needs to be determined whether it is a container process.

[0038] The namespace of the target device usually refers to the system-level namespace, which is a key part of system resource isolation. The namespace of the target device includes multiple types, such as process ID namespace, network namespace, mount namespace, unified host name and domain name namespace, inter-process communication namespace, and user and user group ID namespace.

[0039] The namespace of the process running in the target device is a mechanism used to isolate process resources in the Linux system. In Linux, each process runs in its own namespace, which allows the process to only see other processes and resources in the same namespace, but not resources in other namespaces. This isolation ensures that resources between different processes do not interfere with each other, improving the stability and security of the system. The process namespace running in the target device includes many types, such as process ID namespace, network namespace, mount namespace, unified host name and domain name namespace, inter-process communication namespace, and user and user group ID namespace.

[0040] Obtaining the namespace of the target device and obtaining the namespace of the process on the device usually involves kernel-level operations of the operating system, so the specific implementation method may vary depending on the operating system.

[0041] In one possible implementation, in Linux, the device file of the target device is usually located in the / dev directory. To obtain the namespace of the target device, you can enter the stat command in the command interface of the target device to view the inode information of the device file. For example, to obtain the namespace of the / dev / sda device, you can enter the command "stat / dev / sda" in the command interface of the target device to obtain the inode number of the device file. The inode number of the device file can be used to uniquely identify the namespace of the device.

[0042] In another possible implementation, the lsns command may be input into the command interface of the target device to obtain all types of namespaces, wherein lsns is a Linux command that can list all types of namespaces in the system of the target device.

[0043] In yet another possible implementation, considering that different types of namespaces may be obtained in different ways, illustratively, a command "ip netns" may be input into a command interface of the target device to obtain the network namespace of the target device.

[0044] There may be multiple ways to obtain the namespace of the target process running in the target device.

[0045] In one embodiment, after obtaining the process ID of the target process running on the target device, you can use nsenter --target in a command line tool (such as nsenter tool) <pid>--net command to enter the network namespace of the specified process (replace --net with other namespace types to enter other types of namespaces).

[0046] In another possible implementation, after obtaining the process ID of the target process running on the target device, the file under " / proc" can also be read to obtain the namespace of the target process running in the target device. For example, to obtain the namespace of the process with PID 1234, the command "cat / proc / 1234 / ns / pid_for_children" can be executed to obtain the namespace of the process with PID 1234. To obtain other namespaces of the process (such as user namespace, network namespace, etc.), a similar method can be used, and only "pid_for_children" needs to be replaced with the corresponding namespace type.

[0047] The aforementioned methods of obtaining the namespace of the target device and the namespace of the target process running on the target device are merely illustrative, and there may be more obtaining methods, which will not be described one by one in this embodiment.

[0048] Each target process running in the target device corresponds to a process ID. When obtaining the characteristic information of the control group of the target process, the target process usually belongs to one or more control groups. When obtaining the control group to which the target process belongs, the characteristic information of the control group to which the target process belongs can be obtained from the file corresponding to the control group. The characteristic information of the control group may include the target container ID, CPU quota and limit, memory limit, network statistics, etc. used by the control group.

[0049] For example, the control group to which the process belongs can be found by reading the " / proc / [PID] / cgroup" file when the process ID (i.e., PID) of the target process is known. This file lists all the control groups to which the process belongs, as well as the paths of each control group in the file system. Afterwards, these paths are parsed to find the characteristic information of the corresponding control group.

[0050] Step S120: Determine the type of the target process based on the namespace of the target device and the namespace of the target process.

[0051] In one possible implementation, considering that there are multiple types of namespaces in Linux, such as PID namespace, network namespace, mount namespace, etc., container processes usually use a specific namespace combination to isolate their operating environment. By analyzing whether the namespace type used by the target process constitutes a specific namespace combination, if it constitutes a specific namespace combination, and the specific namespace combination does not belong to the namespace combination constituted by the namespace type of the target device, it can be inferred that the target process is a container process.

[0052] In another possible implementation, the namespace of the target device can be matched with the namespace of the target process to obtain a matching result; the type of the target process is determined based on the matching result, wherein when the namespace of the target device matches the namespace of the target process, the type of the target process is a non-container process; when the namespace of the target device does not match the namespace of the target process, the type of the target process is a container process.

[0053] Under this implementation, for the process ID namespace: if the process ID namespace of the target process is different from the process ID namespace of the target device, it means that the target process is running in an independent process space, that is, the target process may be a container process. For the network namespace: if the network namespace of the target process is different from the network namespace of the target device, it means that the target process is running in a network-isolated environment, that is, the target process may be a container process. Similarly, the same comparison method can be used for the mount namespace, unified host name and domain name namespace, inter-process communication namespace, and user and user group ID namespace to ultimately determine the type of the target process.

[0054] Accordingly, in one possible implementation, the above step S120 may be to match the multiple namespaces of the target device with the namespaces of the same type in the multiple namespaces of the target process to obtain a matching result for each type of namespace; if the matching result of at least one type of namespace is not matched, the type of the target process is determined to be a container process. If all types of namespaces match, the target process can be determined to be a device process.

[0055] Among them, the container process refers to the process running in the container, which is isolated by the namespace and control group. The perception and use of resources (such as CPU, memory, network, file system, process ID, etc.) by each container process are limited and independent, and are isolated from each other.

[0056] A device process refers to a process that runs directly on the target device. It is not restricted by the above namespaces and control groups and shares the global resources of the target device with other processes on the target device.

[0057] Step S130: If the type of the target process is a container process, basic information of the target container to which the target container ID belongs is obtained based on the target container ID.

[0058] When it is confirmed that the target process is a container process, it can be determined that the container ID obtained in step S110 is valid and reliable.

[0059] When obtaining basic information of the container to which the target container ID belongs based on the container ID of the target container, the specific acquisition process can be: obtaining detailed information of the target container to which the target container ID belongs through the Docker CLI tool (Docker Command Line Interface, container command line interface), and extracting the basic information of the target container to which the target container ID belongs from the obtained detailed information.

[0060] Exemplarily, the Docker CLI tool can be used to use the docker inspect command to obtain detailed information of the container (the docker inspect command is a command for obtaining detailed information of a container), which returns an object in JSON format, which includes basic information of the container, such as container ID, image ID, creation time, running status, environment variables, network configuration, mount point, resource restrictions (reflected by control groups), etc., and the basic information of the target container to which the required target container ID belongs is extracted from the returned JSON object, such as the container root path, image ID, container startup command, network configuration, port mapping information, etc.

[0061] When obtaining basic information of the container to which the container ID belongs based on the container ID of the target container, the specific acquisition process may also be: by sending an information acquisition request including the target container ID to the container management process, the container management process generates an information feedback response in response to the information acquisition request, and the information feedback response includes all detailed information of the target container to which the target container ID belongs. By parsing this information feedback response, the basic information of the target container to which the target container ID belongs can be obtained. Figure 2 As shown, a schematic diagram showing the basic information of the target container including the container name, container ID, startup type and image ID is shown in the interface of the container management system (Kubernetes system).

[0062] It should be understood that the above method of obtaining the basic information of the target container to which the target container ID belongs is only illustrative, and there may be more obtaining methods, which will not be described one by one here.

[0063] By adopting the container information acquisition method of the present application, the namespace of the target device, the namespace of the target process running in the target device, and the characteristic information of the control group running the target process are obtained, and the characteristic information includes the target container ID; based on the namespace of the target device and the namespace of the target process, the type of the target process is determined; if the type of the target process is a container process, the basic information of the target container to which the target container ID belongs is obtained based on the target container ID. By adopting the method provided by the present application, the container information acquisition process is executed only on the target device, which simplifies the operation process and reduces the dependence on external services. In addition, since there is no need to call the API through a request, network delays and potential errors in API calls can be effectively avoided, which improves the real-time and accuracy of container information acquisition and reduces network overhead.

[0064] In addition, in a large-scale cluster scenario, that is, a cluster containing a large number of server nodes in a cloud computing environment or data center, such as a cluster running a Docker container or a Kubernetes (K8s) workload. In such an environment, there may be hundreds or even thousands of containers distributed on multiple physical or virtual nodes. If the information of each container is to be obtained through an API request, network transmission will become a bottleneck. By adopting the solution of the present application, it is possible to obtain information directly from the local system level, thereby avoiding frequent network interactions and significantly reducing network latency and bandwidth consumption. At the same time, API services can focus on other core functions, such as cluster management and scheduling, thereby improving the stability and reliability of the system.

[0065] like Figure 3 As shown, the process of obtaining container information is given as follows: first, the cgroup and namespace information of all running processes in the / proc directory of the target device are parsed, and the container ID is obtained by parsing the characteristic information in the cgroup. The namespace information of the process is used to verify whether the process is a container process. If it is a container process, it can be determined that the container ID obtained above is reliable. After that, the configuration file of the corresponding container is obtained based on the container ID to obtain the basic information of the container (container root path, container image ID, container type, etc.).

[0066] like Figure 4 As shown, for the target container, after completing the collection of container basic information, basic asset information collection can be performed based on the collected container basic information, software asset information collection can be performed based on the collected basic asset information, Web site asset information can be collected based on the collected software asset information, and Web framework asset information can be collected based on the collected Web site asset information.

[0067] See also Figure 5 , the process of collecting basic asset information for the target container is specifically step S310: copying the container management to obtain a child process, modifying the root directory of the child process to the root directory of the target container and adjusting the environment variables of the child process to the environment variables in the target container to obtain the target child process, and using the target child process to extract the basic asset information of the target container based on the information acquisition file. The process of collecting software asset information for the target container is step S320: collecting software asset information based on the collected container basic asset information and the software rule database. The process of collecting Web site asset information for the target container is step S330: parsing the configuration file of the web software to obtain the Web site asset information. The process of collecting Web framework asset information for the target container is step S340: reading the feature file based on the rule database, and collecting the web framework asset information used by the web software mounted in the web service.

[0068] The following describes in detail the process of collecting basic asset information, software asset information, Web site asset information, and Web framework asset information:

[0069] See also Figure 6 In one possible implementation, the basic information of the container to which the target container ID belongs includes the root directory of the container. After executing step S130, the method further includes:

[0070] Step S140: copy the container management process in the target device to obtain a child process of the container management process.

[0071] The method of copying the container management process in the target device may be to call the container management process in the target device by a system call function to create a child process of the container management process. The system call function may be a fork() function or a clone() function.

[0072] When the fork() function is called to create a child process of the container management process, the kernel will create a new process that is the same as the container management process, called a child process. The child process inherits most of the resources of the parent process, including but not limited to: memory space, open file descriptors, signal processing settings, process priority, etc.

[0073] Among them, the clone() function provides a more flexible way to create a child process. The clone() function allows the caller to accurately specify which resources need to be shared or independent between the new process and the parent process. In the container scenario, the clone() function is often used with specific flags to create container processes with different namespaces, thereby achieving more refined resource isolation.

[0074] Another way to copy the container management process in the target device is to use a container orchestration tool to start a new container instance. The new container instance will run the same process as the previous container management process and use the process as a child process of the container management process.

[0075] Step S150: modify the root directory of the child process to the root directory of the target container to obtain the first child process.

[0076] By changing the root directory of the child process to the root directory of the target container, it can be ensured that the first child process will access the file system of the target container instead of the file system of the target device when accessing the file system. In this way, the first child process can access the files and directories in the target container.

[0077] Step S160: The first subprocess obtains the environment variables and information acquisition files in the target container.

[0078] Specifically, you can read the environment variable file of the container (such as the / proc / <target container PID> / environ file) to obtain the environment variables, or directly obtain the environment variables set when the container is started through the Docker API.

[0079] Access the file system of the target container, find and read the information acquisition file, which may include a command execution script or a configuration file.

[0080] Step S170: Adjust the environment variables of the first child process to the environment variables in the target container to obtain the target child process.

[0081] Environment variables are a set of key-value pairs used by a process at runtime, and environment variables can affect the behavior of the first child process. By adjusting the environment variables of the first child process to the environment variables in the target container to obtain the target child process, it can be ensured that the target child process uses the same environment settings as the target container at runtime, so that the target child process runs in the environment of the target container without being affected by the environment of the target device. In this way, the target child process can correctly parse the configuration files, paths and other information in the target container, thereby obtaining the asset information of the target container.

[0082] Specifically, the environment variables of the read target container can be set one by one to the corresponding first child process through a programming interface (such as setenv(), putenv() programming interface of C language or os.environ programming interface of Python, etc.), so as to adjust the environment variables of the first child process to the environment variables in the target container.

[0083] Step S180: The target child process obtains basic asset information of the target container based on the information acquisition file.

[0084] It should be understood that since the target subprocess has adjusted the root directory and environment variables based on the subprocess obtained by copying the container management process, but its program part has not changed. Therefore, the target subprocess has the same commands and operations as the container management process, which are formulated by the tool developer based on the understanding of the internal environment of the container and the demand analysis, and the purpose is to effectively and accurately obtain the internal state and configuration information of the container. Therefore, the target subprocess can obtain the basic asset information of the target container based on the information acquisition file.

[0085] If the information acquisition file includes a command execution file, the target child process executes the command execution file to obtain a command execution result, which includes basic asset information. Therefore, the basic asset information of the target container can be extracted from the command execution result.

[0086] If the information acquisition file includes soft links or other types of configuration files, the target child process reads and parses the file content, and finds the corresponding asset information through the parsing results. For example, the actual configuration path and content are obtained by parsing the soft links, and these files are further read to obtain the asset information of the target container.

[0087] In this embodiment, the basic asset information of the target container may include, but is not limited to, process information, configuration file content, network information, and software information of software installed in the target container.

[0088] Exemplarily, when obtaining process information, the docker exec command (used to instruct the execution of a new command inside a running Docker container) can be executed, followed by the docker ps command (used to instruct the command to list the currently running container information) and the docker top command (used to instruct the command to display the dynamic information of each process in the system in real time (such as CPU and memory usage)), etc., to obtain the process information in the container (such as process ID, command line parameters, parent process ID, etc.). When obtaining the content of the configuration file, the host information is obtained by reading the / etc / hosts file or executing the hostname command or the actual configuration file is opened and its content is read to obtain the configuration file content, such as the database connection string, service port, etc. When obtaining the software information of the software installed in the target container, the corresponding command can be executed according to the package manager used in the container to obtain the software installation package information, thereby obtaining the software information of the software installed in the target container. When obtaining network information, the network asset information such as the network interface, IP address, port mapping, etc. of the container can be obtained by reading the network configuration file or executing network-related commands.

[0089] It should be noted that the above steps S140-S180 are completed under the premise of simulating the target container operating environment, so that the basic asset information of the target container can be obtained safely and accurately without affecting the normal operation of the container.

[0090] By adopting the above method, by obtaining the child process of the container management process, and modifying the root directory of the child process to the root directory of the target container to obtain the first child process, and setting the environment variable of the first child process to the environment variable of the target container to which the target container ID belongs to obtain the target child process, it can be ensured that the target child process will access the file system of the target container when accessing the file system, rather than the file system of the target container. In this way, the target child process can access the files and directories in the target container, thereby obtaining the asset information of the target container. In addition, the environment variable is a set of key-value pairs used by the process at runtime, and the environment variable can affect the behavior of the process. By adjusting the environment variables of the child process to the environment variables in the target container, it can be ensured that the target child process uses the same environment settings as the target container at runtime. In this way, the target child process can correctly parse the configuration file, path and other information in the target container, thereby accurately obtaining the asset information of the target container.

[0091] In an implementation manner, after obtaining the basic asset information of the target container, the software asset information of the target container may be further obtained. Specifically, the method further includes:

[0092] Obtain process information of a first process running in a target container and software information of software installed in the target container; associate the first process to which the process information belongs with the software installed in the target container based on the process information and software information, and obtain target software associated with the first process; obtain software asset information of the target software associated with the first process as software asset information of the target container.

[0093] The method of obtaining the software information of the software installed in the target container can be specifically: for a Debian / Ubuntu-based container (a Debian / Ubuntu-based container refers to a software container built based on a Debian or Ubuntu operating system), the dpkg-l command (a command for quickly viewing which software packages are currently installed in the system) can be executed to obtain all installed software packages and their version information, thereby obtaining the software information of the software installed in the target container based on the installed software packages and their version information. For a Red Hat / CentOS-based container (a Red Hat / CentOS-based container refers to a software container built based on a Red Hat or CentOS operating system), the rpm-qa command (a command for querying and listing all installed RPM packages in the system) can be executed to obtain an installed RPM (Red Hat Package Manager) package list, thereby obtaining the software information of the software installed in the target container based on the RPM (Android Package) package list. For Alpine Linux-based containers, you can use the apk info command (a command used to list all installed software packages and their version information in the system) to list all installed APK packages, thereby obtaining software information of the software installed in the target container based on the installed APK packages.

[0094] Alternatively, a file system snapshot of the container may be obtained through a Docker API or SDK (Software Development Kit), and then the package manager database file in the container may be analyzed to obtain software information of the software installed in the target container.

[0095] The software rule database may include information about different software, which is used to help identify and associate processes with the software packages they correspond to. Specifically, the software rule database may include but is not limited to the following types of information: Package identification: the name, version, release, and other unique identifiers of the software package, such as the package name + version number combination of Debian, or the full name of the software package of Red Hat. Installation path: the default directory structure and location of key files after the software is installed, such as executable files, library files, etc. Startup command: the executable file name provided by the software package and common command line startup parameters, which is critical for identifying the software to which the process belongs by process name or command line parameters. File hash value or signature: used to verify file integrity and source, to ensure that the file executed by the process does belong to a specific software package. Dependencies: record the dependencies between the software package and other software packages, indirectly helping to determine other components that the process may be associated with.

[0096] When associating the process to which the process information belongs with the software based on the software rule database, the command line parameters, execution file path and other information in the process information are analyzed and matched with the known software package information in the software rule database. Since the rule database stores information such as standard startup commands and execution file paths of various software packages, the software package used by the process can be identified through these features. For example, if the command line path of the process points to an executable file of a software package recorded in the database, it can be considered that the process is started by this software package. In this way, the association relationship between the process and the software package is established, and the software package and its version to which each process belongs are obtained.

[0097] When obtaining the software asset information of the target software associated with the first process, according to the record of the software package of the target software in the software rule database, the detailed information such as the version, configuration file, installation path, etc. of the software to which the software package belongs can be obtained, thereby obtaining the software asset information of the target container.

[0098] After obtaining the software asset information of the target container, the method further includes:

[0099] The Web software is obtained from the software associated with the first process; based on the configuration file and environment variables corresponding to the process associated with the Web software, the Web site asset information of the target container is obtained.

[0100] Specifically, the method of obtaining the Web software from the software associated with the first process may be to identify the processes related to the Web service, such as Apache HTTP Server, Nginx, Tomcat, IIS and other Web service-related processes, and determine the software associated with the processes related to the Web service as the Web software. Usually, the Web software has a fixed configuration file path. By locating and reading the configuration file of the Web software and parsing the configuration file, the asset information related to the Web site can be extracted. After that, the environment variable configuration related to the Web service is obtained by reading the environment variables of the process. After that, the detailed asset information of the Web site is summarized by combining the information obtained from the configuration file and the environment variables.

[0101] For example, when locating and reading the configuration files of the Web software, the configuration files of Nginx are / etc / nginx / nginx.conf and / etc / nginx / conf.d / *.conf. The configuration files of Apache are / etc / httpd / conf / httpd.conf and / etc / httpd / conf.d / *.conf. The configuration files of Tomcat are located at / usr / local / tomcat / conf / server.xml.

[0102] The asset information related to the Web site extracted by reading and parsing the configuration file content may include: the Web site domain name, listening port, SSL certificate configuration (Secure Sockets Layer), virtual host settings, and application context path.

[0103] By reading the environment variables of the process, you can obtain the environment variable configuration related to the Web service, such as: database connection information, application root directory, session storage, log path, temporary directory and other configurations.

[0104] Combined with the information obtained from the configuration files and environment variables, the site asset information of each Web service in the target container is summarized as the Web site asset information of the target container. The Web site asset information includes: the site domain name, port number, SSL status, application deployment path, context path, static resource path, database connection information, log configuration, and session management configuration of the Web software.

[0105] When the Web site asset information includes the context path of the Web software, after obtaining the Web site asset information of the target container based on the configuration file and environment variables corresponding to the process associated with the Web software, the method also includes: obtaining the deployment directory of the Web software based on the context path of the Web software; obtaining the software information of the Web software from the deployment directory of the Web software; and obtaining the Web site asset information of the target container based on the software rule database and the software information of the Web software.

[0106] The context path of the Web software is usually stored in the configuration file of the Web software to indicate the root directory of the Web software. After the context path of the Web software is obtained, the deployment directory of the Web software is calculated according to the context path.

[0107] Among them, in Web software, the context path is a part of the URL access path of the Web software, which is used to distinguish multiple Web software deployed on the same target device. The deployment directory is the actual installation location of the Web software on the target device file system. In this embodiment, the software rule database can store the context paths and corresponding deployment directories of different Web software. The deployment directory of the Web software can be obtained from the software rule database according to the context path of the Web software. For example, the context path of a Web application is " / myapp", and the corresponding deployment directory is " / var / www / myapp".

[0108] When obtaining software information of Web software from the deployment directory of Web software, the actual files and directory structure of Web application can be directly accessed through the deployment directory to obtain software information, for example: access the main files of Web application (such as .war or .jar files of Java application, .py or .egg files of Python application), configuration files (such as .properties, .yml, .xml, etc.), version control information (such as .git directory of Git, or manifest file containing version number) and third-party dependent libraries (such as node_modules directory, vendor directory or .pipfile.lock and other files to obtain software information of Web software, software information of Web software may include software name, software version, deployment path (actual deployment location of Web software inside target container), file path (a description of the exact location of each file and directory inside Web software in computer file system), configuration information, dependent library information (all third-party libraries and their versions that Web software depends on, including but not limited to JavaScript library, CSS framework (Cascading Style Sheets Framework), dependent packages of back-end language, etc.), framework and library versions, startup and runtime parameters, SSL certificate information and network configuration, etc.

[0109] When obtaining the Web site asset information of the target container based on the software information in the software rule database and the Web software, the software rule database contains information such as the standard deployment structure, version information, common configuration items, dependent libraries and their versions of various Web software. By comparing the software information (such as name, version number) obtained from the Web software deployment directory with the software rule database, it can be verified whether the configuration of the Web software is correct, whether the version is an officially recognized safe version, whether the dependency relationship is reasonable, etc., thereby improving the accuracy and reliability of asset information.

[0110] Accordingly, based on the software information of the Web software in the software rule database and the software information of the Web software, the software information of the Web software can be compared with the preset software information corresponding to the Web software in the software rule database to obtain a first comparison result; if the first comparison result indicates that the software information of the Web software is consistent with the preset software information corresponding to the software, the software information of the Web software is used as the Web site asset information of the target container. In this case, the Web site asset information of the target container obtained above may include software name, software version, deployment path, file path, configuration information, dependent library information, framework and library version, startup and runtime parameters, SSL certificate information, and network configuration.

[0111] If the first comparison result indicates that the software information of the Web software is inconsistent with the preset software information corresponding to the software, the Web site asset information of the target container can be obtained based on the first comparison result and the obtained software information of the Web software. Exemplarily, when the comparison result indicates that the configuration of the Web software is different from the preset configuration of the Web software in the software rule database, the Web site asset information of the target container may also include asset information that the configuration of the Web software is incorrect. When the comparison result indicates that the version of the Web software is different from the preset version of the Web software in the software rule database, the Web site asset information of the target container may also include asset information that the version of the Web software is not an officially recognized safe version.

[0112] like Figure 7 As shown, a schematic diagram showing the Web site asset information of the target container including the Web software name, version, startup user, binary user, and configuration file is shown in the interface of the container management system (Kubernetes system).

[0113] In one possible implementation, the asset information of the Web software includes a file path of the Web software. After obtaining the Web site asset information of the target container based on the software rule database and the software information of the Web software, the method further includes:

[0114] The framework information of the Web framework used by the Web application is obtained from the management file under the file path of the Web software; the Web framework asset information of the target container is obtained based on the software rule database and the framework information of the Web framework.

[0115] Among them, under the file path of the Web software, there are usually some specific files that can reflect the use of the Web framework. For example, for Java Spring Boot software, you can view management files such as pom.xml or build.gradle, which contain the dependency information of the project. By parsing the above management files and analyzing these dependencies, you can determine the used Web framework (such as Spring MVC, Spring Boot, etc.) and its version. For Python Django software, you can view management files such as requirements.txt or setup.py files, which list the libraries that the project depends on. By parsing the management files, you can know whether the Django framework and its version are used. The software rule database stores standard information of many Web frameworks, such as framework name, version, official website, security vulnerability record, best practices, compatibility information, etc. The Web framework information obtained from the management file is compared and matched with the information in the software rule database to confirm the exact version and features of the Web framework. According to the successfully matched Web framework information, the accurate relevant asset information of the framework is extracted from the rule database, such as the security status of the framework (whether there are known vulnerabilities and whether it needs to be upgraded to a secure version). Framework compatibility information (whether it is compatible with the current operating system, JDK version (Java Development Kit), Python version, etc.). Framework best practices (recommended configuration options, security configuration, performance optimization suggestions, etc.). Through the software rule database, known security vulnerabilities in the web framework can be discovered and fixed in a timely manner to ensure that web applications run in a safe and stable environment.

[0116] Accordingly, the step of obtaining the Web framework asset information of the target container based on the software rule database and the framework information of the Web framework may include: comparing the framework information of the Web framework with the preset framework information corresponding to the Web framework in the software rule database to obtain a second comparison result; if the second comparison result indicates that the framework information of the Web framework is consistent with the preset frame information of the Web framework, the framework information of the Web framework is used as the Web framework asset information of the target container. If the second comparison result indicates that the framework information of the Web framework is inconsistent with the preset frame information of the Web framework, the Web framework asset information of the target container may be obtained based on the second comparison result and the framework information of the Web framework. Exemplarily, if the second comparison result indicates that the version of the Web framework is inconsistent with the preset version of the Web framework in the software rule database, the Web framework asset information of the target container includes asset information that the Web framework needs to be upgraded to a secure version.

[0117] like Figure 8 , Figure 8 A container information acquisition device 400 is provided in an embodiment of the present application, and the device 400 includes: a first information acquisition module 410, used to obtain the namespace of the target device, the namespace of the target process running in the target device, and the characteristic information of the control group running the target process, the characteristic information including the target container ID; a process type determination module 420, used to determine the type of the target process based on the namespace of the target device and the namespace of the target process; a container information acquisition module 430, used to obtain the basic information of the target container to which the target container ID belongs based on the target container ID when the type of the target process is a container process.

[0118] In some embodiments, the process type determination module 420 is further used to match the namespace of the target device with the namespace of the target process to obtain a matching result; determine the type of the target process based on the matching result, wherein, when the namespace of the target device matches the namespace of the target process, the type of the target process is a non-container process; when the namespace of the target device does not match the namespace of the target process, the type of the target process is a container process.

[0119] In some embodiments, there are multiple namespaces, each of which is of a different type; the process type determination module 420 is further used to match the multiple namespaces of the target device with the namespaces of the same type in the multiple namespaces of the target process to obtain matching results for each type of namespace; if there is at least one type of namespace whose matching result is a mismatch, the type of the target process is determined to be a container process.

[0120] In some implementations, the container information acquisition module 430 is further configured to search for configuration information corresponding to the target container ID from configuration information corresponding to a plurality of ID containers pre-stored in the target device.

[0121] In some implementations, the basic information of the target container to which the target container ID belongs includes the root directory of the container, the image ID of the container, and the container type.

[0122] In some embodiments, the apparatus 400 further includes a process copy module, a directory modification module, a second information acquisition module, a process adjustment module, and an asset information acquisition module. The process copy module is used to copy the container management process in the target device to obtain a child process of the container management process; the directory modification module is used to modify the root directory of the child process to the root directory of the target container to obtain a first child process; the second information acquisition module is used to obtain the environment variables and information acquisition files in the target container by the first child process; the process adjustment module is used to adjust the environment variables of the first child process to the environment variables in the target container to obtain the target child process; the asset information acquisition module is used to obtain the basic asset information of the target container by the target child process based on the information acquisition file.

[0123] Furthermore, the information acquisition file includes a command execution file and a soft link, and an asset information acquisition module is used to execute the command execution file by the target child process to obtain the command execution result, and the target child process parses the soft link to obtain the parsing result; obtain the basic asset information of the target container from the command execution result and the file pointed to by the parsing result.

[0124] In some implementations, the process replication submodule is used to call the container management process in the target device through a system call function to create a child process of the container management process.

[0125] Correspondingly, such as Fig. 9 The embodiment of the present application further provides an electronic device 510, which may be an electronic device capable of running applications, such as a smart phone, a tablet computer, or a server. The electronic device 510 may include one or more processors 520, a memory 530, and one or more applications, wherein the one or more applications are stored in the memory 530 and configured to be executed by the one or more processors 520, and the one or more applications are configured to execute the above-mentioned container information acquisition method.

[0126] It can be understood that the processor 520 and the memory 530 are connected via a communication bus to complete mutual communication, and the processor 520 can call the logic instructions in the memory 530 to execute the speech template generation method in any of the aforementioned embodiments. Exemplarily, the processor 520 can be implemented in the form of a general-purpose CPU, a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit.ASIC), or one or more integrated circuits, etc., for executing related programs to implement the technical solution provided in this application. The memory can include ROM (Read 0nly Memory, read-only memory), RAM (Random Access Memory, random access memory) static storage devices, dynamic storage devices, etc.

[0127] Correspondingly, an embodiment of the present application further provides a computer-readable storage medium, in which a program code is stored. The program code can be called by a processor to execute the above-mentioned container information acquisition method.

[0128] It can be understood that the logic instructions in the above-mentioned memory 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.

[0129] Part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for enabling 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 of various embodiments of the present invention. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0130] The above are only preferred embodiments of the present application, and are not intended to limit the present application in any form. Although the present application has been disclosed as above with preferred embodiments, it is not intended to limit the present application. Any technical personnel in the field can make some changes or modify the technical contents disclosed above into equivalent embodiments without departing from the scope of the technical solution of the present application. However, any brief modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present application without departing from the content of the technical solution of the present application are still within the scope of the technical solution of the present application.< / pid>

Claims

1. A method for obtaining container information, characterized in that: The method comprises: Acquire a namespace of a target device, a namespace of a target process running in the target device, and characteristic information of a control group running the target process, wherein the characteristic information includes a target container ID; Determining a type of the target process based on a namespace of the target device and a namespace of the target process; If the type of the target process is a container process, basic information of the target container to which the target container ID belongs is obtained based on the target container ID.

2. The method according to claim 1, characterized in that The determining the type of the target process based on the namespace of the target device and the namespace of the target process includes: Matching the namespace of the target device with the namespace of the target process to obtain a matching result; The type of the target process is determined according to the matching result, wherein when the namespace of the target device matches the namespace of the target process, the type of the target process is a non-container process; when the namespace of the target device does not match the namespace of the target process, the type of the target process is a container process.

3. The method according to claim 2, characterized in that There are multiple namespaces, each of which has a different type; The matching of the namespace of the target device with the namespace of the target process to obtain a matching result includes: Matching the multiple namespaces of the target device with the namespaces of the target process that are of the same type, to obtain a matching result for each type of namespace; If the matching result of at least one type of namespace is not a match, it is determined that the type of the target process is a container process.

4. The method according to claim 1, characterized in that: The obtaining basic information of the target container to which the target container ID belongs based on the target container ID includes: The configuration information corresponding to the target container ID is searched from the configuration information respectively corresponding to a plurality of ID containers pre-stored in the target device.

5. The method according to claim 1, characterized in that The basic information of the target container to which the target container ID belongs includes the root directory of the container, the image ID of the container, and the container type.

6. The method according to any one of claims 1 to 5, characterized in that: The basic information of the target container to which the target container ID belongs includes the root directory of the container. After obtaining the basic information of the target container to which the target container ID belongs based on the target container ID, the method further includes: Copying the container management process in the target device to obtain a child process of the container management process; Modify the root directory of the child process to the root directory of the target container to obtain a first child process; The first subprocess obtains the environment variables and information acquisition files in the target container; Adjusting the environment variables of the first subprocess to the environment variables in the target container to obtain the target subprocess; The target subprocess obtains basic asset information of the target container based on the information acquisition file.

7. The method according to claim 6, characterized in that: The information acquisition file includes a command execution file and a soft link, and the target subprocess obtains the basic asset information of the target container based on the information acquisition file, including: The target subprocess executes the command execution file to obtain a command execution result, and the target subprocess parses the soft link to obtain a parsing result; The basic asset information of the target container is obtained from the command execution result and the file pointed to by the parsing result.

8. The method according to claim 6, characterized in that The copying of the container management process in the target device to obtain a child process of the container management process includes: The container management process in the target device is called by a system call function to create a child process of the container management process.

9. A container information acquisition device, characterized in that: The device comprises: A first information acquisition module is used to acquire a namespace of a target device, a namespace of a target process running in the target device, and characteristic information of a control group running the target process, wherein the characteristic information includes a target container ID; A process type determination module, configured to determine the type of the target process based on the namespace of the target device and the namespace of the target process; The container information acquisition module is used to obtain basic information of the target container to which the target container ID belongs based on the target container ID when the type of the target process is a container process.

10. An electronic device, characterized in that: include: one or more processors; Memory; 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, and the one or more programs are configured to execute the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program codes, and the program codes can be called by a processor to execute the method according to any one of claims 1 to 8.

Images