A method, terminal device and medium for monitoring files of other containers within a container

Abstract

The application relates to a method for monitoring other container files in a container, a terminal device and a medium, and the method comprises the following steps: starting a security monitoring type container A in a privileged mode, mounting a / var / lib / containers directory of a host computer to a / host / var / lib / containers directory of the container A, and mounting a container engine listening path of the host computer to a / host directory of the container A; using an inotifywait command to monitor whether a new container B is generated in the container A in real time; when the new container B is generated, different ways are adopted to find overlayfs2 mounting parameters of the container B from the container A according to different container engine types of the container B; and based on the found mounting parameters, the mounting of the overlayfs2 is re-executed once in the container A. The application can solve the problem that a mounting directory generated subsequently by a host computer cannot be seen after a container is started.

Description

Technical Field

[0001] This invention relates to the field of container technology, and in particular to a method, terminal device, and medium for monitoring other container files within a container. Background Technology

[0002] With the surging wave of cloud computing, the concept of cloud-native has emerged. Under cloud-native, many software and functions are containerized. Installing software and functions directly on the host machine presents problems such as maintenance difficulties. After containerization, some software and functions may encounter problems such as being unable to access the mount directories created on the host machine after containerization when trying to manage the host machine.

[0003] Antivirus software and system vulnerability scanning software need to utilize the mounting function of Linux containers to run inside Linux containers and perform detection on other containers.

[0004] To monitor the contents of files in mounted directories on the host machine or other container root directories, Linux containers typically use a mapping method, such as the command-line parameter `-v host_directory:container_directory`, in container engines like podman. For example, if the host machine's ` / a` directory is mapped to the container's ` / b` directory, then creating a file `hello.txt` in the host machine's ` / a` path will also allow access to this file in the container's ` / b / hello.txt` path. Furthermore, if the host machine subsequently updates `hello.txt`, accessing `hello.txt` within the container will also show the updated content.

[0005] However, if the antivirus software container is run first and the command `-v / a: / b` is executed, and then a mount point is created under ` / a`, such as by executing `mkdir / a / mynfs&&mount -t nfs 192.168.88.243: / data / yuxing / a / mynfs`, then the ` / b / mynfs` directory within the container will not show any content from the NFS server (assuming the NFS server contains a large number of files). Similarly, in a container storage driver environment like OverlayFS2, each container mounts its own root directory to a directory on the host after it runs. In this case, the antivirus software container will also not be able to see the files in the root directories of containers started after it.

[0006] The current mainstream approach in the industry to handle this situation is container-mounted volume propagation. Linux container-mounted volume propagation requires modifying the system service startup parameters of the container engine, setting the service unit's MountFlags to shared, and then restarting the Docker engine to enable the contents of the NFS server to be visible in the / b / mynfs path within the container.

[0007] However, verification has shown that existing Linux container volume propagation methods are ineffective. It remains impossible to execute NFS mounting on the host machine after the container starts, and then view the remote NFS server data within the container. Therefore, if you want to run vulnerability and virus detection software on a Linux environment as a container, it cannot scan for subsequently created host-mounted volumes and containers.

[0008] Each time a container is started, its file system is mounted to a directory on the host machine. In this scenario, once the antivirus software container is running, subsequent startups of other containers will not detect the startup of these other containers, nor will they detect any changes to the files within those containers. Summary of the Invention

[0009] To address the aforementioned problems, this invention proposes a method, terminal device, and medium for monitoring other container files within a container.

[0010] The specific plan is as follows:

[0011] A method for monitoring other container files within a container includes the following steps:

[0012] Start the security monitoring container A in privileged mode, and at startup, mount the / var / lib / containers directory of the host machine to the / host / var / lib / containers directory of container A, and mount the container engine listening path of the host machine to the / host directory of container A;

[0013] Inside container A, the inotifywait command is used to monitor in real time whether a new container is created. When a new container B is created, depending on the container engine type of container B, different methods are used to find the overlayfs2 mount parameters of container B from container A, and based on the found mount parameters, the overlayfs2 mount is re-executed inside container A.

[0014] Furthermore, when the container engine type is CRI-O, the method for finding the overlayfs2 mount parameters of container B from container A is as follows:

[0015] Based on the container ID, execute the command `crictl -r unix: / / / host / run / crio / crio.sockinspect${container ID}` inside container A, and then use the jq command to query the data node `.info.pid` in the JSON to obtain the PID process ID of the sandbox in container B;

[0016] Based on the process ID (PID), execute the command `cat / proc / ${pid} / mounts` to obtain the mount information of container B, and then search for the overlayfs2 mount parameters from the mount information.

[0017] Furthermore, when the container engine type is podman, the method to find the overlayfs2 mount parameters of container B from container A is as follows: based on the container ID, execute the command curl -s --unix / host / run / podman / podman.sock http: / / d / v3.0.0 / libpod / containers / ${container ID} / json in container A, and then obtain the overlayfs2 mount parameters from the command returned by curl using the jq command.

[0018] Furthermore, security monitoring container A can be an antivirus software container or a vulnerability scanning container.

[0019] Furthermore, the host machine's container engine listens on the following paths: / run / crio / crio.sock and / or / run / podman / podman.sock.

[0020] A terminal device for monitoring other container files within a container includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described above in the embodiments of the present invention.

[0021] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described above in the embodiments of the present invention.

[0022] The present invention adopts the above technical solution, which can solve the problem that the mount directories generated by the host machine cannot be seen after the container starts. This enables cri-o and podman to automatically synchronize the mount directories of the container on the host machine to the antivirus container under systems such as Red Hat, CentOS, Ubuntu, and CoreOS, so that the scanning software and antivirus software in the container can run smoothly. Attached Figure Description

[0023] Figure 1 The diagram shown is a flowchart of Embodiment 1 of the present invention. Detailed Implementation

[0024] To further illustrate the various embodiments, the present invention provides accompanying drawings. These drawings are part of the disclosure of the present invention, primarily used to illustrate the embodiments, and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these drawings, those skilled in the art should be able to understand other possible implementations and the advantages of the present invention.

[0025] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0026] Example 1:

[0027] This invention provides a method for monitoring other container files within a container, such as... Figure 1 As shown, the method includes the following steps:

[0028] S1: Start the security monitoring container A in privileged mode, and at startup, mount the / var / lib / containers directory of the host machine to the / host / var / lib / containers directory of container A, and mount the container engine listening path of the host machine to the / host directory of container A.

[0029] Security monitoring container A can be an antivirus software container or a vulnerability scanning container, etc.

[0030] The security monitoring container A must have privileged permissions, therefore it needs to be started and run in privileged mode.

[0031] In this embodiment, the container engines include cri-o and podman. The default storage path for both container engines is / var / lib / containers because they use the same repository, namely github.com / containers / storage.

[0032] When starting container A, you need to set mount parameters for container A. The command is: pod man run –v / var / lib / containers: / host / var / lib / containers, to mount the / var / lib / containers directory on the host machine to the / host / var / lib / containers directory on container A.

[0033] When starting container A, the host machine's container engine listening path also needs to be mounted to the container A / host directory. The specific address of the container engine listening path is determined by the type of container engine. When the container engine type is cri-o, the host machine's / run / crio / crio.sock directory is mounted to the container A's / host / run / crio / crio.sock directory; when the container engine type is podman, the host machine's / run / podman / podman.sock directory is mounted to the container A's / host / run / podman / podman.sock directory; if a full mount is required, the host machine's root path can be mounted to the / host directory inside the container.

[0034] S2: Use the inotifywait command in container A to listen for new containers in real time. When a new container B is created, proceed to S3.

[0035] The inotifywait command is used to monitor for changes in the file ` / host / var / lib / containers / storage / overlay-containers / containers.json`. Any new container creation, deletion, or other container status changes will be reflected in this file. This embodiment only considers container creation and deletion events; therefore, the inotifywait command is used to monitor the creation and deletion events of all first-level folders under the ` / host / var / lib / containers / storage / overlay-containers` directory (non-recursive monitoring).

[0036] The creation of a folder event signifies the creation of a new container. Based on the listener, the name of the newly created folder can be determined, and this name is also the container's ID. This folder name is used to check if it exists in / host / var / lib / containers / storage / overlay-containers / containers.json. If it exists, it proves that the folder name is a valid container ID.

[0037] S3: Use different methods to find the overlayfs2 mount parameters of container B in container A, and re-execute the overlayfs2 mount in container A based on the found mount parameters.

[0038] When the container engine type is CRI-O, the method for finding the overlayfs2 mount parameters of container B from container A is as follows:

[0039] S301: Based on the container ID, execute the command crictl-runix: / / / host / run / crio / crio.sock inspect${container ID} inside container A, and then use the jq command to query the data node .info.pid in the JSON to obtain the PID process number of the sandbox of container B;

[0040] S302: Based on the PID process ID, execute the command cat / proc / ${pid} / mounts to obtain the mount information of container B, and search for the overlayfs2 mount parameters from the mount information.

[0041] When the container engine type is podman, the method to find the overlayfs2 mount parameters of container B from container A is as follows: Based on the container ID, execute the command curl -s --unix / host / run / podman / podman.sock http: / / d / v3.0.0 / libpod / containers / ${container ID} / json in container A, and then obtain the overlayfs2 mount parameters from the command returned by curl using the jq command.

[0042] In this embodiment, the overlayfs2 mount parameters include upperdir, workdir, lowerdir, and mergeddir. The command to mount overlayfs2 based on the mount parameters is: mount -t overlay overlay-lowerdir=${lowerdir},upperdir=${upperdir},workdir=${workdir}${mergeddir}.

[0043] By following the steps above, the mount information of the merged directory on the host machine can be synchronized to container A. Since container A and the host machine have different mount spaces, container A will not cause any substantial damage to the host machine. Furthermore, after other containers (like container B) write new files to the merged directory, these files are automatically synchronized to the mount point directory of container A. This embodiment uses read-write mount as the default mount method; if read-only mount is required, the corresponding mount parameters can be adjusted.

[0044] In addition to folder creation events, there are also deletion events to handle. However, the deletion event has been verified to not require handling at present. When other containers are deleted, the mount paths in the antivirus software container or vulnerability scanning container will also be automatically cleaned up by the Linux system.

[0045] All of the above steps take place within container A and no code is executed on the host machine.

[0046] The method described in this embodiment can solve the following technical problem: Taking a Red Hat OpenShift + CoreOS environment as an example, it is necessary to perform vulnerability scanning and virus infection analysis on all Linux containers and images on the host machine. When antivirus software and vulnerability scanning software are run as containers, the root path " / " on the host machine is mounted to " / host" inside the container. In the OpenShift environment, the container engine is CRI-O. When the scanning software is running inside the container to scan other containers, since the merged directories of other containers under the overlayfs2 file system are submounts of " / " on the host machine, if a container is started after the antivirus software container or vulnerability scanning container, it will not see the merged directory of the container started after it by default, and thus vulnerability scanning and virus removal cannot be completed.

[0047] Example 2:

[0048] The present invention also provides a terminal device for monitoring other container files within a container, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the method embodiment described above in Embodiment 1 of the present invention.

[0049] Furthermore, as an executable solution, the terminal device monitoring other container files within the container can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. The terminal device monitoring other container files within the container may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above-described structure of the terminal device monitoring other container files within the container is merely an example and does not constitute a limitation on the terminal device. It may include more or fewer components than described above, or combine certain components, or different components. For example, the terminal device monitoring other container files within the container may also include input / output devices, network access devices, buses, etc., and this embodiment of the invention does not limit this.

[0050] Furthermore, as an executable solution, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. This processor serves as the control center for the terminal devices monitoring other container files within the container, connecting various parts of the terminal devices monitoring other container files throughout the container via various interfaces and lines.

[0051] The memory can be used to store the computer programs and / or modules. The processor, by running or executing the computer programs and / or modules stored in the memory and calling the data stored in the memory, realizes various functions of the terminal device monitoring other container files within the container. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application required for a function; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD cards), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0052] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described in the embodiments of the present invention.

[0053] If the module / unit integrated by the terminal device monitoring other container files within the container is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc.

[0054] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. A method for monitoring files in other containers within a container, characterized in that, Includes the following steps: Start the security monitoring container A in privileged mode, and at startup, mount the / var / lib / containers directory of the host machine to the / host / var / lib / containers directory of container A, and mount the container engine listening path of the host machine to the / host directory of container A; The inotifywait command is used in container A to monitor in real time whether a new container is created. When a new container B is created, depending on the container engine type of container B, different methods are used to find the overlayfs2 mount parameters of container B from container A, and based on the found mount parameters, the overlayfs2 mount is re-executed in container A. When the container engine type is CRI-O, the method for finding the overlayfs2 mount parameters of container B from container A is as follows: Based on the container ID, execute the command `crictl -r unix: / / / host / run / crio / crio.sockinspect ${container ID}` inside container A, and then use the jq command to query the data node `.info.pid` in the JSON to obtain the PID process ID of the sandbox in container B; Based on the process ID (PID), execute the command `cat / proc / ${pid} / mounts` to obtain the mount information of container B, and then search for the overlayfs2 mount parameters from the mount information. When the container engine type is podman, the method to find the overlayfs2 mount parameters of container B from container A is as follows: Based on the container ID, execute the command curl -s --unix / host / run / podman / podman.sockhttp: / / d / v3.0.0 / libpod / containers / ${container ID} / json in container A, and then use the jq command to obtain the overlayfs2 mount parameters from the command returned by curl.

2. The method for monitoring other container files within a container according to claim 1, characterized in that: Security monitoring container A is either an antivirus software container or a vulnerability scanning container.

3. The method for monitoring other container files within a container according to claim 1, characterized in that: The host machine's container engine listens on the following paths: / run / crio / crio.sock and / or / run / podman / podman.sock.

4. A terminal device for monitoring files in other containers within a container, characterized in that: It includes a processor, a memory, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any one of claims 1 to 3.

5. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 3.

Images