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

Abstract

The invention provides a container asset information obtaining method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining the basic information of a target container running on target equipment, and the basic information comprises a root directory; copying a container management process in the target equipment to obtain a sub-process of the container management process; modifying a root directory of the sub-process into a root directory of the target container to obtain a first sub-process; acquiring an environment variable and an information acquisition file in the target container by the first sub-process; adjusting the environment variable of the first sub-process into the environment variable in the target container to obtain a target sub-process; and obtaining the basic asset information of the target container by the target sub-process based on the information obtaining file. By adopting the method, the target sub-process can truly simulate the internal environment of the container, so that the asset information acquired by utilizing the target sub-process is more accurate and comprehensive and is not influenced by a host machine environment.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and specifically to a method, device, electronic device and storage medium for obtaining container asset information. Background Art

[0002] In the related art, the method of obtaining container asset information is usually to obtain the metadata and running status of the container through tools such as Docker API and kubectl on the host machine, or to read the configuration file and environment variables by entering the container and executing commands. However, the method of obtaining container asset information in the related art may be affected by the environment variables of the host machine, resulting in inaccurate asset information. Summary of the invention

[0003] In view of the above problems, the present application provides a method, device, electronic device and storage medium for obtaining container asset information, which can effectively avoid network delays and potential errors in API calls, and improve the real-time and accuracy of container asset 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 asset information, the method comprising: obtaining basic information of a target container running on a target device, the basic information including a root directory; copying a container management process in the target device to obtain a child process of the container management process; modifying the root directory of the child process to the root directory of the target container to obtain a first child process; obtaining environment variables and an information acquisition file in the target container by the first child process; adjusting the environment variables of the first child process to the environment variables in the target container to obtain a target child process; obtaining the basic asset information of the target container by the target child process based on the information acquisition file.

[0006] In a second aspect, an embodiment of the present application provides a container asset information acquisition device, the device comprising: a first acquisition module, used to acquire basic information of a target container running on a target device, the basic information including a root directory; a process acquisition module, used to copy a container management process in the target device to obtain a child process of the container management process; a directory modification module, used to modify the root directory of the child process to the root directory of the target container to obtain a first child process; a second acquisition module, used to use the first child process to acquire environment variables and information acquisition files within the target container; a variable adjustment module, used to adjust the environment variables of the first child process to the environment variables within the target container to obtain a target child process; an asset acquisition module, used to use the target child process to obtain the basic asset information of the target container based on the information acquisition file.

[0007] In some embodiments, the asset acquisition module is further used to execute the command execution file by the target child process to obtain a command execution result, and parse the soft link by the target child process 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.

[0008] In some implementations, the process acquisition module is further configured to call the container management process in the target device using a system call function to create a child process of the container management process.

[0009] In some embodiments, the asset information acquisition module is also used to obtain process information of a first process running in a target container and software information of software installed in the target container; based on a software rule database, the process information and software information are used to associate the first process to which the process information belongs with the software installed in the target container to obtain target software associated with the first process; and software asset information of the target software associated with the first process is obtained as software asset information of the target container.

[0010] In some implementations, the asset information acquisition module is further used to acquire Web software from the software associated with the first process; and obtain 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.

[0011] In some implementations, the Web site asset information includes the context path of the Web software, and the asset information acquisition module is further used to obtain the deployment directory of the Web software based on the context path of the Web software; obtain the software information of the Web software from the deployment directory of the Web software; and obtain the Web software asset information of the target container based on the software rule database and the software information of the Web software.

[0012] In some embodiments, the asset information acquisition module is further used to compare the software information of the Web software 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 software asset information of the target container.

[0013] In some embodiments, the asset information of the Web software includes the file path of the Web software, and the asset information acquisition module is also used to obtain the framework information of the Web framework used by the Web application from the management file under the file path of the Web software; and obtain the Web framework asset information of the target container based on the software rule database and the framework information of the Web framework.

[0014] In some embodiments, the asset information acquisition module is also used to compare 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.

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

[0016] 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 asset information acquisition method.

[0017] The container asset information acquisition method, device, electronic device and storage medium provided in the embodiment of the present application; obtain the basic information of the target container running on the target device, the basic information including the root directory; copy the container management process in the target device to obtain the 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 the first child process; obtain the environment variables and information acquisition file in the target container by the first child process; adjust the environment variables of the first child process to the environment variables in the target container to obtain the target child process; obtain the basic asset information of the target container by the target child process based on the information acquisition file. The target child process is obtained by copying the container management process to obtain the child process and changing its root directory to the root directory of the target container. Since the target child process has the same environment variables as the target container, it is not affected by the target device environment when using the target child process to obtain asset information, thereby ensuring that the acquired asset information is more accurate and comprehensive.

[0018] 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

[0019] 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.

[0020] Figure 1 It is a flow chart of a method for obtaining container asset information provided in an embodiment of the present application.

[0021] Figure 2 Figure 1 Schematic diagram of the process of step S110.

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

[0023] Figure 4 This is another flow chart of a method for obtaining container asset information provided in an embodiment of the present application.

[0024] Figure 5 This is another flow chart of a method for obtaining container asset information provided in an embodiment of the present application.

[0025] Figure 6 This is another flow chart of a method for obtaining container asset information provided in an embodiment of the present application.

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

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

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

[0029] 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.

[0030] 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.

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

[0032] 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.

[0033] 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.

[0034] 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.

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

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

[0037] Step S110: Obtain basic information of the target container running on the target device.

[0038] Basic information includes the root directory.

[0039] There are multiple ways to obtain basic information of the target container running on the target device.

[0040] In one possible implementation, the basic information of the target container can be obtained through an API interface. For example, DockerEngine provides a RESTful API, through which the basic information of the target container can be obtained. Kubernetes APIServer also provides a set of APIs, which can obtain the basic information of the target container through HTTP requests.

[0041] In another possible implementation, a command line tool can be used to obtain basic information of the target container. For example, for a Docker-based container, the Docker command line tool can be used to obtain basic information of the target container. For a container in a Kubernetes cluster, the kubectl command line tool can be used to obtain basic information of the target container.

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

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

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

[0048] By modifying the root directory of the child process to the root directory of the target container to obtain the first child process, 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.

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

[0050] 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.

[0051] 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.

[0052] Step S150: adjusting the environment variables of the first child process to the environment variables in the target container to obtain the target child process.

[0053] 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.

[0054] 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.

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

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] It should be noted that the above steps S110-S160 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.

[0062] By adopting the above method, by obtaining the child process of the container management process, 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. 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.

[0063] See also Figure 2 In one possible implementation, the step of obtaining basic information of the target container running on the target device includes steps S112-S116.

[0064] S112: 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

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

[0073] 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).

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

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

[0079] 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.

[0080] 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.

[0081] 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.

[0082] Accordingly, in one possible implementation, the above step S120 may be to match the namespace of the target device with the namespace of the target process of the same type to obtain a matching result of each type of namespace; if there is a mismatch in the matching result of at least one type of namespace, 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.

[0083] 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.

[0084] 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.

[0085] Step S116: 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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 3 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).

[0090] 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.

[0091] By adopting the container basic information acquisition method of the above steps S112-S116, the container asset 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 asset information acquisition and reduces network overhead.

[0092] 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.

[0093] like Figure 4 As shown, the process of obtaining container asset information is given as an example: first parse the cgroup and namespace information of all running processes in the / proc directory of the target device, obtain the container ID by parsing the characteristic information in the cgroup, and verify whether the process is a container process through the namespace information of the process. If it is a container process, it can be determined that the above-obtained container ID is reliable. After that, obtain the configuration file of the corresponding container based on the container ID and then obtain the container basic information (container root path, container image ID, container type, etc.).

[0094] To obtain more asset information in the target container, such as Figure 5 As shown, for the target container, after completing the collection of container basic information and basic asset information, it is also possible to collect software asset information based on the collected basic asset information, collect Web site asset information based on the collected software asset information, and collect Web framework asset information based on the collected Web site asset information.

[0095] See also Figure 6 , the process of collecting basic asset information for the target container is specifically step S310: copying the container management process 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.

[0096] Specifically, in one possible implementation, 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:

[0097] 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.

[0098] 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.

[0099] 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.

[0100] Alternatively, the target child process may be used to execute a software package acquisition command to acquire software package information, so as to obtain software information of the software installed in the target container.

[0101] 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.

[0102] 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.

[0103] 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.

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

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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".

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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).

[0119] 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:

[0120] 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.

[0121] 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.

[0122] 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.

[0123] like Figure 8 , Figure 8 A container asset information acquisition device 400 provided in an embodiment of the present application includes: a first acquisition module 410, used to acquire basic information of a target container running on a target device, the basic information including a root directory; a process acquisition module 420, used to copy a container management process in a target device to obtain a child process of the container management process; a directory modification module 430, used to modify the root directory of a child process to the root directory of a target container to obtain a first child process; a second acquisition module 440, used to use the first child process to acquire environment variables and information acquisition files in a target container; a variable adjustment module 450, used to adjust the environment variables of the first child process to the environment variables in a target container to obtain a target child process; an asset acquisition module 460, used to use the target child process to obtain basic asset information of a target container based on an information acquisition file.

[0124] In some embodiments, the asset acquisition module 460 is also 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; and obtain the basic asset information of the target container from the command execution result and the file pointed to by the parsing result.

[0125] In some implementations, the process acquisition module 410 is further configured to call the container management process in the target device using a system call function to create a child process of the container management process.

[0126] In some embodiments, the asset information acquisition module 460 is also used to obtain process information of a first process running in a target container and software information of software installed in the target container; based on a software rule database, the process information and software information are used to associate the first process to which the process information belongs with the software installed in the target container to obtain target software associated with the first process; and software asset information of the target software associated with the first process is obtained as software asset information of the target container.

[0127] In some implementations, the asset information acquisition module 460 is further used to acquire the Web software from the software associated with the first process; and obtain 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.

[0128] In some implementations, the Web site asset information includes the context path of the Web software. The asset information acquisition module 460 is further used to obtain the deployment directory of the Web software based on the context path of the Web software; obtain the software information of the Web software from the deployment directory of the Web software; and obtain the Web software asset information of the target container based on the software rule database and the software information of the Web software.

[0129] In some embodiments, the asset information acquisition module 460 is also used to compare the software information of the Web software 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 software asset information of the target container.

[0130] In some embodiments, the asset information of the Web software includes the file path of the Web software. The asset information acquisition module 460 is also used to obtain the framework information of the Web framework used by the Web application from the management file under the file path of the Web software; and obtain the Web framework asset information of the target container based on the software rule database and the framework information of the Web framework.

[0131] In some embodiments, the asset information acquisition module 460 is also used to compare 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.

[0132] 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 asset information acquisition method.

[0133] 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.

[0134] 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 asset information acquisition method.

[0135] 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.

[0136] 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.

[0137] 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 asset information, characterized in that: The method comprises: Obtain basic information of a target container running on a target device, the basic information including a root directory; 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.

2. The method according to claim 1, 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.

3. The method according to claim 1, 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.

4. The method according to claim 1, characterized in that: After the target subprocess obtains the basic asset information of the target container based on the information acquisition file, the method further includes: Obtaining process information of a first process running in a target container and software information of software installed in the target container; Associating the first process to which the process information belongs with the software installed in the target container based on the process information and the software information in the software rule database to obtain the target software associated with the first process; Software asset information of target software associated with the first process is obtained as software asset information of the target container.

5. The method according to claim 4, characterized in that After obtaining the software asset information of the target software associated with the first process as the software asset information of the target container, the method further includes: Acquire the Web software 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.

6. The method according to claim 5, characterized in that 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 further includes: Obtaining a deployment directory of the Web software based on the context path of the Web software; Acquire software information of the Web software from the deployment directory of the Web software; Based on the software information in the software rule database and the Web software, the Web software asset information of the target container is obtained.

7. The method according to claim 6, characterized in that The obtaining the Web software asset information of the target container based on the software information in the software rule database and the Web software includes: Comparing the software information of the Web software 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 software asset information of the target container.

8. The method according to claim 6, characterized in that The asset information of the Web software includes a file path of the Web software. After obtaining the Web software asset information of the target container based on the software rule database and the software information of the Web software, the method further includes: Obtaining framework information of a web framework used by a web application from a management file under a 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.

9. The method according to claim 8, characterized in that The obtaining the Web framework asset information of the target container based on the software rule database and the framework information of the Web framework includes: 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 frame information of the Web frame is consistent with the preset frame information of the Web frame, the frame information of the Web frame is used as the Web frame asset information of the target container.

10. A container asset information acquisition device, characterized in that: The device comprises: A first acquisition module is used to acquire basic information of a target container running on a target device, wherein the basic information includes a root directory; A process acquisition module, used to copy the container management process in the target device and obtain a child process of the container management process; A directory modification module, used to modify the root directory of the subprocess to the root directory of the target container to obtain a first subprocess; A second acquisition module, configured to use the first subprocess to acquire environment variables and information acquisition files in the target container; A variable adjustment module, used to adjust the environment variables of the first sub-process to the environment variables in the target container to obtain a target sub-process; The asset acquisition module is used to obtain the basic asset information of the target container based on the information acquisition file by using the target subprocess.

11. 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 9.

12. 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 9.

13. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method described in any one of claims 1 to 9 are implemented.

Images