Container application tamper-proof early warning method and device, equipment, storage medium and computer program product

Abstract

The invention discloses a container application tamper-proof early warning method, device and equipment, a storage medium and a computer program product, and relates to the technical field of container security, the method comprises the steps that a container mirror image corresponding to a basic mirror image is constructed, and a monitoring dependency program is embedded in the container mirror image; creating and starting a target container based on the container mirror image, running a container application in the target container by monitoring a dependent program, and monitoring the container application; when it is monitored that a change event occurs in the container application, performing validity authentication on the change event; and if it is determined that the container application is tampered according to the validity authentication result, sending an early warning notification. According to the method, the change event occurring in the container application is monitored while the dependent program runs the container application in the target container, so that whether the container application is tampered or not can be accurately judged according to the validity authentication result corresponding to the change event; and when it is determined that the container application is tampered, an early warning notice is sent to prevent safety accidents.

Description

Technical Field

[0001] This application relates to the field of container security technology, and in particular to a container application anti-tampering early warning method, device, equipment, storage medium and computer program product. Background Technology

[0002] In the field of computer software, containers are widely used due to their lightweight and highly portable characteristics. However, due to the dynamic runtime environment and open architecture of containers, applications running in containers may experience malicious file tampering, leading to security incidents (such as data breaches and system intrusions). Therefore, it is crucial to implement anti-tampering warnings for applications running in containers. Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, device, storage medium, and computer program product for preventing tampering and providing early warning for container applications, aiming to solve the technical problem of how to provide early warning for preventing tampering of applications running in containers.

[0004] To achieve the above objectives, this application provides a method for preventing tampering and providing early warning for container applications, the method comprising the following steps:

[0005] Build a container image corresponding to the base image, wherein the container image contains a listener for dependency programs;

[0006] A target container is created and started based on the container image. The container application in the target container is run through the listening dependency program, and the container application is monitored.

[0007] When a change event is detected in the container application, the change event is validated.

[0008] If the container application is determined to have been tampered with based on the validity authentication result, an early warning notification will be sent.

[0009] In one embodiment, the step of building the container image corresponding to the base image includes:

[0010] Switch to the first user identity, download and install the monitoring dependency program in the base image to obtain the first layer image;

[0011] Copy the compilation result of the monitoring dependent program in the first layer image, merge the base image with the compilation result to obtain the second layer image;

[0012] Switch to the second user identity and build the container image corresponding to the base image based on the second layer image.

[0013] In one embodiment, the step of running the container application in the target container through the listening dependency program and listening to the container application includes:

[0014] The listening program invokes a process management tool and a listening script through the listening dependency program. The listening script is executed by the process management tool while the container application in the target container is running, thereby starting the listening program.

[0015] Obtain the directory file tree corresponding to the container application, and traverse the directory file tree to obtain several monitoring targets;

[0016] The listener registers an inotify instance, assigns a descriptor to the listener target using the inotify instance, and listens to the container application based on the descriptor.

[0017] In one embodiment, the step of validating the change event when a change event is detected in the container application includes:

[0018] When a change event is detected in the container application, it is determined whether there is a matching event in the historical events.

[0019] If it exists, the validity of the change event is verified based on the occurrence time of the change event and the same event, respectively.

[0020] If it does not exist, the change event is determined to have passed the validity authentication, and the change event is recorded.

[0021] In one embodiment, the step of validating the change event based on the occurrence times of the change event and the same event includes:

[0022] If the difference between the occurrence times of the changed event and the same event is greater than a preset time, the changed event is determined to have passed the validity authentication, and the changed event is recorded.

[0023] If the difference between the occurrence times of the changed event and the same event is less than or equal to a preset time, the changed event is determined to have failed validity authentication, and the changed event is merged with the same event.

[0024] In one embodiment, after the step of sending an alert notification if it is determined from the validity authentication result that the container application has been tampered with, the method further includes:

[0025] Determine whether the cumulative number of valid events at the current moment has reached the threshold for triggering event circuit breaking. The valid events are change events in the container application that have passed validity authentication.

[0026] If yes, then exit the listening process for the container application; otherwise, output the valid event to a named pipe.

[0027] Furthermore, to achieve the above objectives, this application also proposes a container application anti-tampering early warning device, which includes:

[0028] The image building module is used to build container images corresponding to the base image, and the container images contain embedded dependency monitoring programs;

[0029] The application monitoring module is used to create and start a target container based on the container image, run the container application in the target container through the monitoring dependency program, and monitor the container application.

[0030] The validity authentication module is used to perform validity authentication on the change event when a change event is detected in the container application.

[0031] The early warning notification module is used to send an early warning notification if it is determined from the validity authentication result that the container application has been tampered with.

[0032] In addition, to achieve the above objectives, this application also proposes a container application anti-tampering warning device, the device comprising: a memory, a processor, and a container application anti-tampering warning program stored on the memory and executable on the processor, the container application anti-tampering warning program being configured to implement the steps of the container application anti-tampering warning method as described above.

[0033] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, storing a container application anti-tampering warning program, wherein when the container application anti-tampering warning program is executed by a processor, it implements the steps of the container application anti-tampering warning method described above.

[0034] In addition, to achieve the above objectives, the present invention also provides a computer program product, the computer program product including a container application anti-tampering warning program, which, when executed by a processor, implements the steps of the container application anti-tampering warning method as described above.

[0035] This application constructs a container image corresponding to a base image, wherein the container image embeds a monitoring dependency program; a target container is created and started based on the container image; the container application in the target container is run through the monitoring dependency program, and the container application is monitored; when a change event is detected in the container application, the change event is validated; if the validation result determines that the container application has been tampered with, an early warning notification is sent. The above method of this application creates and starts a target container based on a container image with an embedded monitoring dependency program, thereby monitoring change events in the container application while running the container application in the target container without requiring root privileges. This allows for accurate determination of whether the container application has been tampered with based on the validation result of the change event, and sends an early warning notification when the container application is confirmed to have been tampered with to prevent security incidents. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a flowchart illustrating the first embodiment of the container application anti-tampering early warning method of this application;

[0039] Figure 2 This is a schematic diagram of the embedded monitoring architecture of the container in the container application anti-tampering early warning method of this application;

[0040] Figure 3 This is a schematic diagram of data access in the container application anti-tampering early warning method of this application;

[0041] Figure 4 This is a flowchart illustrating the second embodiment of the container application anti-tampering early warning method of this application;

[0042] Figure 5 This is a schematic diagram illustrating the container image construction process of the container application anti-tampering early warning method of this application;

[0043] Figure 6 This is a schematic diagram illustrating the traversal of the directory file tree in the container application anti-tampering early warning method of this application;

[0044] Figure 7This is a flowchart illustrating the workflow of the monitoring program in the container application anti-tampering early warning method of this application;

[0045] Figure 8 This is a flowchart illustrating the third embodiment of the container application anti-tampering early warning method of this application;

[0046] Figure 9 This is a structural block diagram of the first embodiment of the anti-tampering early warning device for container applications in this application;

[0047] Figure 10 This is a schematic diagram of the structure of a container application anti-tampering early warning device for the hardware operating environment involved in the embodiments of this application.

[0048] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0050] It should be noted that the executing entity of the embodiments of this application can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as the aforementioned container application anti-tampering early warning device. The following embodiments will be described using the container application anti-tampering early warning device as an example.

[0051] This application provides a container application anti-tampering early warning method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the container application anti-tampering early warning method of this application.

[0052] In this embodiment, the container application anti-tampering early warning method includes the following steps:

[0053] Step S10: Build a container image corresponding to the base image, wherein the container image contains a listening dependency program.

[0054] Understandably, the base image described above is a minimal operating system environment or language runtime, typically containing a core file system, system tools, or pre-built language environments to provide runtime dependencies for subsequent builds. The container image described above is a core component of container technology. It can be understood as a lightweight, portable software packaging format that encapsulates the application and all its dependencies (such as code, runtime, system tools, libraries, configuration files, etc.) in a single file, ensuring consistent and reliable operation in any environment.

[0055] It should be understood that the aforementioned monitoring dependency program may include process management toolkits, monitoring programs, monitoring scripts, etc., and this embodiment does not impose any restrictions on this.

[0056] In practice, the base image mentioned above can be pulled using a Dockerfile, and then the listening dependency program can be combined into the base image to build the container image corresponding to the base image. The Dockerfile is a text file used to automate the building of Docker images (static files used to build Docker containers, containing all the files, dependencies, and configuration information required for the application to run). It contains the complete set of instructions from a base image to the final customized image.

[0057] Step S20: Create and start the target container based on the container image, run the container application in the target container through the listening dependency program, and listen to the container application.

[0058] It should be noted that the target container (hereinafter referred to as the container) mentioned above refers to the container instance that will eventually run, which is created based on a container image. The image provides a blueprint, and the container is the process built and run according to this blueprint. Containers are lightweight and portable, containing the isolated environment required to run applications. Containerized applications refer to the actual applications running inside the target container, such as web pages, backend services, databases, etc.

[0059] It should be understood that because the aforementioned listening dependency is embedded within the container image, root privileges are not required to listen to the container application while it is running in the target container. This avoids security incidents caused by malicious exploitation of root privileges. Specifically, after embedding the aforementioned listening dependency in the container image, the listening embedded module and listening dependency can be injected into the container through the container image to adapt to the dynamic container environment. Please refer to [link / reference] for details. Figure 2 , Figure 2 This diagram illustrates the embedded monitoring architecture of containers in the container application anti-tampering early warning method of this application. Here, Infrastructure represents the host hardware, which is the computer hardware running the container; Host OS represents the host operating system, which is the operating system directly installed on the host hardware Infrastructure; and the Docker engine is the software installed on the Host OS.

[0060] Step S30: When a change event is detected in the container application, the change event is validated.

[0061] It should be noted that the aforementioned change events can include types such as modification events, attribute change events, move events, creation events, and deletion events. Specifically, a modification event indicates that the file content of the container application is modified or written, and its corresponding event mask can be IN_MODIFY (0x00000002); an attribute change event indicates that the metadata (such as permissions, timestamps, extended attributes, etc.) of a file or directory in the container application changes, and its corresponding event mask can be IN_ATTRIB (0x00000004); a move event indicates that a monitored file in the container application is moved out of its original directory, a monitored file is moved to a monitored directory, or the monitored directory itself is moved, and the event masks corresponding to these three different move events can be IN_MOVED_FROM (0x00000002, 0x00000002, 0x00000002, 0x00000004 ...04, 0x000000004, 0x000000004, 0x000000004, 0x000000004, The event masks for IN_CREATE (0x00000040), IN_MOVED_TO (0x00000080), and IN_HOVE_SELF (0x00000800) are: IN_CREATE (0x00000100) and IN_DELETE (0x00000200) and IN_DELETE_SELF (0x00000400). The event mask for IN_MOVED_TO (0x000000800) and IN_HOVE_SELF (0x00000400) are: IN_MOVED_TO (0x000000800) and IN_HOVE_SELF (0x00000800). The event mask for IN_MOVED_TO (0x000000800) indicates that a file or subdirectory in a directory under a container application is created. The event mask for IN_MOVED_TO (0x000000800) is: IN_HOVE_SELF (0x00000400).

[0062] It should be understood that the target container described above can run on a host Linux system. In a Linux system, data access within the container application can rely on three blocks: the superblock, the inode, and the data block. Therefore, monitoring these three blocks can be used to listen for data access within the container application and determine if any changes have occurred. For example, refer to... Figure 3 , Figure 3 This diagram illustrates the data access process in the container application anti-tampering early warning method of this application. Figure 3 In the diagram, the gray area inode 4 records the actual location of the file data in the four data blocks in the blue area, namely 2, 7, 13, and 15. The operating system can monitor the changes of the file data blocks associated with the inode, so it only needs to monitor the changes of the inode, without having to repeatedly scan all the large data blocks.

[0063] In practical implementation, the validity of a change event can be verified by determining whether it is an invalid event. Invalid events can include, but are not limited to, recurring events, events whose event mask does not match the event type, and events whose content contains unidentifiable information. If the change event is not invalid, it can be determined that the change event has passed the validity verification; if the change event is invalid, it can be determined that the change event has failed the validity verification.

[0064] Step S40: If it is determined from the validity authentication result that the container application has been tampered with, a warning notification is sent.

[0065] In its implementation, Linux's VFS (Virtual File System) provides a general interface abstraction. When a change event occurs (i.e., the monitored inode changes), VFS can form an event queue by calling callback functions registered with inotify (a file system monitoring mechanism provided by the Linux kernel) through a notification chain. Inotify, as a consumer of the notification chain, reads the event queue and sends event notifications to the upper layer. Based on the efficient event monitoring characteristics of inotify and the fact that it does not require root privileges, this embodiment proposes a container-embedded monitoring architecture: that is, by embedding monitoring dependencies in the container image, the monitoring embedded module and monitoring dependencies are implanted within the container, adapting to the dynamic container environment. Once a change event is detected and the change event passes validity authentication, it can be determined that the container application has been tampered with. At this time, the system can immediately and automatically send a notification to the relevant personnel, and the container application can be rerun by rebuilding and restoring the container instance.

[0066] Specifically, it should be noted that this embodiment can be configured with an anti-tampering notification service to send early warning notifications. Specifically, the anti-tampering notification service is deployed independently, responsible for providing configuration queries for container applications and sending notifications after change events are triggered. It does not consume resources from embedded applications, thus improving service availability and flexibility. Container applications provide a visual access configuration interface during access, based on the publishing unit. For scenarios that do not require monitoring, such as automatically updated files or directories, regular POSIX (Portable Operating System Interface of Unix) expressions can be automatically generated based on the configuration and excluded during the monitoring registration process.

[0067] This embodiment constructs a container image corresponding to a base image, which embeds a monitoring dependency program. A target container is created and started based on this container image. The monitoring dependency program runs the container application within the target container and monitors the container application. When a change event is detected in the container application, the change event is validated. If the validation result indicates that the container application has been tampered with, a warning notification is sent. This embodiment's method creates and starts a target container based on a container image with an embedded monitoring dependency program. Therefore, without requiring root privileges, the monitoring dependency program monitors change events occurring in the container application while running it. This allows for accurate determination of whether the container application has been tampered with based on the validation result of the change event, and a warning notification is sent when tampering is confirmed to prevent security incidents.

[0068] refer to Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the container application anti-tampering early warning method of this application.

[0069] In one feasible implementation, step S10 may include:

[0070] Step S101: Switch to the first user identity, download and install the monitoring dependency program in the base image to obtain the first layer image.

[0071] It should be noted that the first user identity mentioned above can be a user with root privileges. Root privileges represent the highest administrative privileges in a Linux system. Users with root privileges can perform any operation on the system, including modifying kernel configurations, accessing all files, installing / uninstalling software, and managing user accounts.

[0072] Step S102: Copy the compilation result of the monitoring dependent program in the first layer image, and merge the base image with the compilation result to obtain the second layer image.

[0073] Step S103: Switch to the second user identity and build the container image corresponding to the base image based on the second layer image.

[0074] It should be noted that the aforementioned second user identity can be a regular user identity. By switching the user's identity from the first user identity to the second user identity, security incidents caused by the malicious exploitation of root privileges can be avoided.

[0075] Please refer to Figure 5 , Figure 5This is a schematic diagram of the container image construction process of the container application anti-tampering early warning method of this application. Compared with the original process, the current process proposed in this embodiment can be described as follows: First, pull the base image in the Dockerfile, switch to the first user identity, and execute the installation script to install the compilation toolchain (CMake, Make, etc.); Second, install the Tini process management tool tar package, the self-developed file system monitoring C language program tar package, and the monitoring script monitor.sh and other monitoring dependent programs through the compilation tools to form the first layer image; Third, in order to remove a large number of redundant dependent packages, only copy the compilation results of the dependent programs in the first layer image, pull the base image again, and merge them to form the second layer image; Fourth, switch back from root to ordinary user, download and apply the compilation results of the second layer image to set the container startup command (including starting the application and the monitoring script), and finally build the above container image, and the final container image only increases the occupied space by 200KB.

[0076] In one feasible implementation, step S20 may include:

[0077] Step S201: The process management tool and the listening script are invoked through the listening dependency program. The listening script is executed by the process management tool while the container application in the target container is running, so as to start the listening program.

[0078] It should be understood that the aforementioned monitoring script first identifies its own service unit number and environment based on the container environment variables. Then, it calls the corresponding environment's anti-tampering notification service interface to obtain the container application access configuration and starts a child process (i.e., the aforementioned monitoring program). It sets parameters such as the monitoring directory list, the directory to be checked, and the upper limit of monitored events. The monitoring program's output is written to a named pipe, and events are then read from the named pipe in a loop to avoid introducing new child processes. Named pipes are an inter-process communication mechanism that allows different processes to transmit data through named channels, and the data transmission follows the FIFO (First Input First Output) principle.

[0079] Furthermore, the monitoring script incorporates fallback mechanisms for scenarios involving abnormalities in the early warning system itself or triggering circuit breakers to exit the monitoring process, preventing the monitoring service from impacting the application itself. Specifically: for the anti-tampering notification service, the monitoring script interacts via an HTTP interface call using the CURL command, identifying the abnormality based on the status code returned by CURL; for the file system listener, the monitoring script first uses $! to obtain the child process PID (Process Identifier), uses the wait command to wait for the exit code of the file system listener PID, and identifies the specific abnormality based on the exit code (e.g., 3 represents circuit breaker exit, 1 represents other abnormalities); it uses the trap command to bind an exit signal, and upon receiving an external signal, executes predefined actions to close the file system listener and clean up named pipes; when an abnormality in the early warning system itself is detected, a loop of sleep is used to block the script from exiting, thus keeping the container running.

[0080] In this implementation, to overcome the limitation of traditional technologies that can only run a single application, this embodiment uses the Tini process tree management tool, which is the process management tool for monitoring dependent program calls. Based on this tool, it is possible to simultaneously run container applications and monitor container applications. The Tini process tree is a process management structure in a container environment with Tini (lightweight initialization process) as the root node. The aforementioned monitoring script is additionally executed by the Tini process tree management tool after the container starts, responsible for scheduling file system monitoring programs and anti-tampering notification services.

[0081] Step S202: Obtain the directory file tree corresponding to the container application, and traverse the directory file tree to obtain several monitoring targets.

[0082] It should be noted that the directory file tree mentioned above is a hierarchical data structure used in the operating system to organize and manage files. It represents the nested relationship between directories and files in the file system in a tree-like form.

[0083] In practice, a depth-first search algorithm can be used to recursively traverse the directory file tree to register monitoring targets. See reference [link / reference]. Figure 6 , Figure 6 This is a schematic diagram illustrating the traversal of the directory file tree in the container application anti-tampering early warning method of this application. Combined with... Figure 6The recursive function logic is as follows: It starts monitoring the root directory, distinguishing between files and directories. If it's a file, it directly monitors that file and returns. If it's a directory, it iterates through the directory entries: after traversing all subdirectories, it monitors the current directory itself. Traversing directory entries can include: using `readdir` to read each entry in the directory, skipping the current directory and its parent directories; an exclusion check to check if the current directory is in the exclusion list, and if so, skipping monitoring; and recursive monitoring, where if not excluded, it recursively calls itself to monitor that subdirectory. After all application files are registered as monitoring targets, they can enter a loop to wait, calling `read()` to read and consume events one by one.

[0084] Step S203: Register an inotify instance through the listener, assign a descriptor to the listener target through the inotify instance, and listen to the container application based on the descriptor.

[0085] In its specific implementation, this embodiment uses a monitoring program developed in C language for efficient interaction with the kernel layer to register inotify instances. By managing the lifecycle of the inotify instances, descriptors are allocated to the monitored targets. Based on these descriptors, continuous monitoring is performed on the application directories that need to be monitored, thereby achieving the monitoring of container applications. For example, refer to... Figure 7 , Figure 7 This is a flowchart illustrating the workflow of the monitoring program in the container application anti-tampering early warning method of this application. From... Figure 7 As can be seen, the listener in user space can execute the following: call inotify_init() to the kernel (which returns an inotify file descriptor) to create an inotify instance; call inotify_add_watch() to the kernel (which returns a watch descriptor) to allocate a watch descriptor for the target being listened to; call read() to the kernel to read the file descriptor (which returns event data) to continuously listen for directory and file change events, and add the change events to the event queue when they occur; call inotify_rm_watch() to the kernel to remove the listener process to stop listening; and call close() to the kernel to close the file descriptor to release resources and end listening.

[0086] In this embodiment, the user switches to the first user identity, downloads and installs the monitoring dependency program from the base image to obtain the first layer image; copies the compilation result of the monitoring dependency program in the first layer image, merges the base image with the compilation result to obtain the second layer image; switches to the second user identity, constructs the container image corresponding to the base image based on the second layer image; calls the process management tool and the monitoring script through the monitoring dependency program, and executes the monitoring script while running the container application in the target container based on the process management tool to start the monitoring program; obtains the directory file tree corresponding to the container application, and traverses the directory file tree to obtain several monitoring targets; registers an inotify instance through the monitoring program, allocates descriptors for the monitoring targets through the inotify instance, and monitors the container application based on the descriptors. In this embodiment, the above method constructs the first-layer image and the second-layer image in layers by switching user identities, thereby separating the installation and compilation process of the monitoring dependency program and effectively reducing the size of the container image. In addition, this embodiment also uses the monitoring dependency program to call the process management tool to run the container application in the target container, and executes the monitoring script to start the monitoring program at the same time, thereby realizing the monitoring of the container application without affecting the operation of the container application.

[0087] refer to Figure 8 , Figure 8 This is a flowchart illustrating the third embodiment of the container application anti-tampering early warning method of this application.

[0088] In one feasible implementation, step S30 may include:

[0089] Step S301: When a change event is detected in the container application, determine whether there is a similar event in the historical events that is consistent with the change event.

[0090] It should be noted that the above historical events refer to all change events that occurred in the container application at that historical point in time.

[0091] It should be understood that whenever a change event is detected in the container application at any time, the hash value corresponding to that change event needs to be stored in a hash table. Based on this, a query in the hash table can be used to determine if a matching historical event exists: if a target historical event with the same hash value as the change event exists in the hash table, then the target historical event is considered the same event; if no event with the same hash value as the change event exists in the hash table, then no matching historical event exists.

[0092] Step S302: If it exists, then the validity of the change event is verified according to the occurrence time of the change event and the same event respectively.

[0093] Understandably, even if there is an identical event in the historical records that is the same as the changed event, it is still not possible to determine whether the changed event has failed the validity authentication. It is still necessary to determine whether the changed event is a recent event based on the occurrence time of the events corresponding to the changed event and the identical event respectively: if the changed event is a recent event compared to the identical event, it can be determined that the changed event has failed the validity authentication; if the changed event is not a recent event compared to the identical event, it can be determined that the changed event has passed the validity authentication.

[0094] Step S303: If it does not exist, then determine that the change event has passed the validity authentication and record the change event.

[0095] In practical implementation, if no identical event to the changed event exists in the historical events, it indicates that the changed event is a newly added event compared to the historical events, and therefore the changed event can be determined to have passed the validity authentication. At this point, the changed event needs to be recorded. The recorded content may include the event type corresponding to the changed event, its hash value, and the cumulative number of changed events that have passed validity authentication at the current moment, etc. This embodiment does not impose any restrictions on this.

[0096] In one feasible implementation, step S302 may include:

[0097] Step S3021: If the difference between the occurrence time of the change event and the occurrence time of the same event is greater than a preset time, then the change event is determined to have passed the validity authentication and the change event is recorded.

[0098] It should be noted that the preset time mentioned above represents the critical time value for determining whether a change event is a recent occurrence. The specific value of the preset time can be customized, for example, it can be set to 30 seconds.

[0099] It should be understood that if the difference between the occurrence time of the change event and the occurrence time of the same event is greater than the preset time, it indicates that the change event is not a recent event. Therefore, the change event can be determined to have passed the validity authentication and the change event can be recorded.

[0100] Step S3022: If the difference between the occurrence times of the changed event and the same event is less than or equal to a preset time, then the changed event is determined to have failed the validity authentication, and the changed event is merged with the same event.

[0101] It should be understood that if the difference between the occurrence time of the change event and the same event is less than or equal to the preset time, it indicates that the change event is a recent event. Therefore, it can be determined that the change event has not passed the validity authentication. Thus, the change event and the same event can be merged into one event, thereby reducing the space resources occupied by storing the change event.

[0102] In one possible implementation, after step S40, the following may also be included:

[0103] Step S50: Determine whether the cumulative number of valid events at the current moment has reached the threshold for triggering event circuit breaking. The valid events are change events in the container application that have passed validity authentication.

[0104] It should be noted that the above quantity threshold can be customized, for example, it can be set to 5000.

[0105] It should be understood that, due to factors such as fine-grained event splitting at the kernel layer, this embodiment found during debugging that periodically updating a static file in a Java program can trigger 8 to 14 change events in different container instances, and changes to the entire file directory can lead to even larger-scale event storms. A simulation was conducted where approximately 28,000 change events were generated within 5 minutes, with event consumption lasting up to two hours, during which high CPU usage occurred. To address this issue, this embodiment developed its own event fusion engine: while maintaining high-sensitivity monitoring, it improves monitoring accuracy by constructing a HashMap (a key-value pair storage structure based on hash functions) to merge events; when an event storm occurs, a circuit breaker mechanism is introduced to ensure overall protection of container resources. In HashMap event merging, because it is necessary to handle the event storm thrown by the kernel layer in a very short time, the storage structure can use a HashMap with high query efficiency. The initial HashMap size is 100, and HashMap memory space is allocated using malloc; the storage index is generated by the DJB2 algorithm. To resolve hash collisions, this embodiment introduces chaining. Each bucket of the HashMap adds a linked list, and colliding elements (with the same hash index) are directly appended to this linked list. A load factor of 0.75 (load factor = number of elements in the HashMap / number of buckets in the HashMap) is introduced. When there are too many events, dynamic resizing is triggered: the HashMap is doubled, the index is recalculated, and the linked list is copied and added to the new table. The hash element key is formed by concatenating the wd (monitor descriptor), name (file name), and mask (event mask) from the inotify_event structure, and the element value is the change time of the change event. A 30-second time window can be set. If the same event occurs within this window, it is ignored and the event is merged; otherwise, the change time of the change event is updated. Experiments show that when updating static files in a Java program, the number of change events that originally needed to be processed was 8 to 14 times the total number of container instances. By introducing the above-mentioned HashMap event merging mechanism, only change events equal to the total number of container instances need to be processed, significantly reducing the number of change events processed.

[0106] Step S60: If yes, exit the listening process for the container application; otherwise, output the valid event to the named pipe.

[0107] It should be understood that event circuit breaking specifically manifests in the following ways: during an event storm, the instantaneous overhead of multiple dynamic expansions is huge (high data migration costs trigger performance jitter), and the probability of hash collisions increases, i.e. all elements hash to the same bucket, degenerating into a singly linked list, thus increasing the query time complexity from O(1) to O(N). At this time, in order to avoid overflow of the inotify event queue, the host machine sets global parameters such as max_queued_events for user instance queues, max_user_instances for global queues, and max_user_watches for the total number of global events by default. However, these parameters have little effect in the container user space, and there is a risk that multiple containers may break through global limits and eventually exceed the host machine's load when an event storm occurs simultaneously. In view of the above discussion, this embodiment actively adds an event circuit breaking trigger detection mechanism for deduplicated events, i.e., it listens to whether the cumulative number of valid events at the current moment reaches the threshold for triggering event circuit breaking. Once the threshold is reached, it actively exits the file system listening program, releases the Hashmap memory space, closes the inotify instance, and actively destroys the inotify event queue. For example, the circuit breaker threshold is set to 5000, and then a performance test is performed by injecting a change event: without adding the event circuit breaker trigger detection mechanism, the CPU remains above 90%; after adding the event circuit breaker trigger detection mechanism and triggering the event circuit breaker, the CPU gradually drops to below 30%.

[0108] In this embodiment, when a change event is detected in the container application, it is determined whether there is an identical event in the historical events. If so, if the difference between the occurrence times of the change event and the identical event is greater than a preset time, the change event is deemed to have passed validity authentication and is recorded. If the difference between the occurrence times of the change event and the identical event is less than or equal to the preset time, the change event is deemed to have failed validity authentication and is merged with the identical event. If not, the change event is deemed to have passed validity authentication and is recorded. It is then determined whether the cumulative number of valid events at the current moment has reached the threshold for triggering event circuit breaking, where the valid events are the change events in the container application that have passed validity authentication. If so, the monitoring process for the container application is exited; otherwise, the valid events are output to a named pipe. The method described in this embodiment verifies the validity of a change event by determining whether there is an identical event in the historical events that is consistent with the change event, thereby providing a data foundation for the subsequent merging of change events. In addition, this embodiment has developed a self-developed HashMap event merging and event circuit breaker mechanism, which can effectively deal with the performance risks brought about by event storms and ensure the high availability of container applications.

[0109] Reference Figure 9 , Figure 9 This is a structural block diagram of the first embodiment of the anti-tampering early warning device for container applications in this application.

[0110] like Figure 9 As shown, the container application anti-tampering early warning device proposed in this application includes:

[0111] Image building module 901 is used to build a container image corresponding to a base image, wherein the container image contains a dependency monitoring program.

[0112] Application monitoring module 902 is used to create and start a target container based on the container image, run the container application in the target container through the monitoring dependency program, and monitor the container application.

[0113] The validity authentication module 903 is used to perform validity authentication on the change event when a change event is detected in the container application.

[0114] The early warning notification module 904 is used to send an early warning notification if it is determined from the validity authentication result that the container application has been tampered with.

[0115] This embodiment constructs a container image corresponding to a base image, which embeds a monitoring dependency program. A target container is created and started based on this container image. The monitoring dependency program runs the container application within the target container and monitors the container application. When a change event is detected in the container application, the change event is validated. If the validation result indicates that the container application has been tampered with, a warning notification is sent. This embodiment's method creates and starts a target container based on a container image with an embedded monitoring dependency program. Therefore, without requiring root privileges, the monitoring dependency program monitors change events occurring in the container application while running it. This allows for accurate determination of whether the container application has been tampered with based on the validation result of the change event, and a warning notification is sent when tampering is confirmed to prevent security incidents.

[0116] Based on the first embodiment of the container application anti-tampering early warning device described in this application, a second embodiment of the container application anti-tampering early warning device of this application is proposed.

[0117] In this embodiment, the image building module 901 is further configured to switch to the first user identity, download and install the monitoring dependency program in the base image to obtain the first layer image; copy the compilation result of the monitoring dependency program in the first layer image, merge the base image and the compilation result to obtain the second layer image; switch to the second user identity, and build the container image corresponding to the base image based on the second layer image.

[0118] Furthermore, the application monitoring module 902 is also used to call a process management tool and a monitoring script through the monitoring dependency program, and execute the monitoring script while the process management tool is running the container application in the target container to start the monitoring program; obtain the directory file tree corresponding to the container application, and traverse the directory file tree to obtain several monitoring targets; register an inotify instance through the monitoring program, allocate descriptors for the monitoring targets through the inotify instance, and monitor the container application based on the descriptors.

[0119] Furthermore, the validity authentication module 903 is also used to determine whether there is an identical event in the historical events when a change event is detected in the container application; if there is, the validity authentication of the change event is performed according to the occurrence time of the event corresponding to the change event and the identical event respectively; if there is no, the validity authentication of the change event is determined to be passed and the change event is recorded.

[0120] Furthermore, the validity authentication module 903 is also used to determine that the change event has passed the validity authentication and to record the change event if the difference between the occurrence times of the change event and the same event is greater than a preset time; if the difference between the occurrence times of the change event and the same event is less than or equal to the preset time, the change event has failed the validity authentication and the change event and the same event are merged.

[0121] Furthermore, the warning notification module 904 is also used to determine whether the cumulative number of valid events at the current moment has reached the threshold for triggering event circuit breaking. The valid events are change events in the container application that have passed validity authentication. If so, the monitoring process of the container application is exited; otherwise, the valid events are output to the named pipe.

[0122] Other embodiments or specific implementations of the container application anti-tampering early warning device of this application can be referred to the above-described method embodiments, and will not be repeated here.

[0123] This application provides a container application anti-tampering early warning device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the container application anti-tampering early warning method in the above embodiment 1.

[0124] The following is for reference. Figure 10This document illustrates a structural schematic diagram of a container application anti-tampering warning device suitable for implementing embodiments of this application. The container application anti-tampering warning device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The container application anti-tampering early warning device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0125] like Figure 10 As shown, the container application anti-tampering warning device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the container application anti-tampering warning device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the container application tamper warning device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows container application tamper warning devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0126] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0127] The container application anti-tampering early warning device provided in this application, employing the container application anti-tampering early warning method in the above embodiments, can solve the technical problem of how to perform anti-tampering early warning for applications running in containers. Compared with the prior art, the beneficial effects of the container application anti-tampering early warning device provided in this application are the same as the beneficial effects of the container application anti-tampering early warning method provided in the above embodiments, and other technical features in this container application anti-tampering early warning device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0128] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0129] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0130] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the container application anti-tampering warning method in the above embodiments.

[0131] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0132] The aforementioned computer-readable storage medium may be included in the container application anti-tampering warning device; or it may exist independently and not be assembled into the container application anti-tampering warning device.

[0133] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a container application anti-tampering warning device, enable the device to write computer program code for performing the operations of this application in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++; and also conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (e.g., via the Internet using an Internet service provider).

[0134] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0135] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0136] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described container application anti-tampering warning method, thereby solving the technical problem of how to provide anti-tampering warnings for applications running in containers. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the container application anti-tampering warning method provided in the above embodiments, and will not be repeated here.

[0137] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the container application anti-tampering warning method described above.

[0138] The computer program product provided in this application can solve the technical problem of anti-tampering warning for container applications. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the anti-tampering warning method for container applications provided in the above embodiments, and will not be repeated here.

[0139] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A method for preventing tampering and providing early warning for container applications, characterized in that, The method includes the following steps: Build a container image corresponding to the base image, wherein the container image contains a listener for dependency programs; A target container is created and started based on the container image. The container application in the target container is run through the listening dependency program, and the container application is monitored. When a change event is detected in the container application, the change event is validated. If the container application is determined to have been tampered with based on the validity authentication result, an early warning notification will be sent.

2. The container application anti-tampering early warning method as described in claim 1, characterized in that, The steps for building the container image corresponding to the base image include: Switch to the first user identity, download and install the monitoring dependency program in the base image to obtain the first layer image; Copy the compilation result of the monitoring dependent program in the first layer image, merge the base image with the compilation result to obtain the second layer image; Switch to the second user identity and build the container image corresponding to the base image based on the second layer image.

3. The container application anti-tampering early warning method as described in claim 1, characterized in that, The step of running the container application in the target container through the listening dependency program and listening to the container application includes: The listening program invokes a process management tool and a listening script through the listening dependency program. The listening script is executed by the process management tool while the container application in the target container is running, thereby starting the listening program. Obtain the directory file tree corresponding to the container application, and traverse the directory file tree to obtain several monitoring targets; The listener registers an inotify instance, assigns a descriptor to the listener target using the inotify instance, and listens to the container application based on the descriptor.

4. The container application anti-tampering early warning method as described in claim 1, characterized in that, The step of validating the change event when a change event is detected in the container application includes: When a change event is detected in the container application, it is determined whether there is a matching event in the historical events. If it exists, the validity of the change event is verified based on the occurrence time of the change event and the same event, respectively. If it does not exist, the change event is determined to have passed the validity authentication, and the change event is recorded.

5. The container application anti-tampering early warning method as described in claim 4, characterized in that, The step of validating the change event based on the occurrence time of the change event and the same event includes: If the difference between the occurrence times of the changed event and the same event is greater than a preset time, the changed event is determined to have passed the validity authentication, and the changed event is recorded. If the difference between the occurrence times of the changed event and the same event is less than or equal to a preset time, the changed event is determined to have failed validity authentication, and the changed event is merged with the same event.

6. The container application anti-tampering early warning method as described in claim 1, characterized in that, Following the step of sending an alert notification if the container application is determined to have been tampered with based on the validity authentication result, the method further includes: Determine whether the cumulative number of valid events at the current moment has reached the threshold for triggering event circuit breaking. The valid events are change events in the container application that have passed validity authentication. If yes, then exit the listening process for the container application; otherwise, output the valid event to a named pipe.

7. A container application anti-tampering early warning device, characterized in that, The container application anti-tampering early warning device includes: The image building module is used to build container images corresponding to the base image, and the container images contain embedded dependency monitoring programs; The application monitoring module is used to create and start a target container based on the container image, run the container application in the target container through the monitoring dependency program, and monitor the container application. The validity authentication module is used to perform validity authentication on the change event when a change event is detected in the container application. The early warning notification module is used to send an early warning notification if it is determined from the validity authentication result that the container application has been tampered with.

8. A container application anti-tampering early warning device, characterized in that, The device includes: a memory, a processor, and a container application anti-tampering warning program stored on the memory and executable on the processor, the container application anti-tampering warning program being configured to implement the steps of the container application anti-tampering warning method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and the storage medium stores a container application anti-tampering warning program. When the container application anti-tampering warning program is executed by the processor, it implements the steps of the container application anti-tampering warning method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a container application anti-tampering warning program, which, when executed by a processor, implements the steps of the container application anti-tampering warning method as described in any one of claims 1 to 6.

Images