Container safety management system, method and device, storage medium and equipment
By injecting eBPF programs into containers independent of the host kernel, the fine-grained problem of container security management in cloud-native environments is solved, and effective control of container runtime behavior is achieved to prevent escape and policy misapplication.
Patent Information
- Application Number
- CN202510885879.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-27
- Publication Date
- 2025-10-17
Smart Images
Figure CN120803603A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present specification relates to the technical field of computer, and particularly relates to a security management system, method and device of a container, a storage medium and an electronic device. BACKGROUND
[0002] In a cloud-native environment, different businesses are usually run in different containers, the containers are run on host computers, and multiple host computers constitute a cluster.
[0003] Generally, the containers need to be controlled and managed by a cloud workload protection platform (CWPP).
[0004] However, since a cluster includes multiple host computers, multiple different containers are usually run on a host computer, the businesses or applications run on different containers are completely different, and the control strategies required by different businesses are also different, which is a great test for the CWPP. How to achieve fine-grained security management of the containers is a problem to be solved. SUMMARY
[0005] Embodiments of the present specification provide a security management system, method and device of a container, a storage medium and an electronic device to partially solve the problems in the prior art.
[0006] Embodiments of the present specification adopt the following technical solutions:
[0007] The present specification provides a security management system of a container, the system comprising: a management server and a plurality of host computers; the host computers are deployed with a host computer Agent client and a plurality of containers; the operating system kernel of each container is independent of the operating system kernel of the host computer;
[0008] The management server is configured to store a security aspect program corresponding to each container;
[0009] The host computer Agent client is configured to obtain the security aspect program corresponding to each container deployed on the host computer from the management server, and inject the security aspect program into the operating system kernel of the container;
[0010] Any of the containers is configured to run the injected security aspect program through the operating system kernel of the container, and control the runtime behavior of the container through the security aspect program.
[0011] The method for security management of a container provided in the specification, a host computer is deployed with a host computer Agent client and a plurality of containers, and the operating system kernel of each container is independent of the operating system kernel of the host computer; the method comprises:
[0012] For each container deployed on the host computer, the security aspect program corresponding to the container is obtained from the management service end;
[0013] The security aspect program is injected into the operating system kernel of the container, so that the operating system kernel of the container runs the injected security aspect program, and the runtime behavior of the container is controlled through the security aspect program.
[0014] The method for security management of a container provided in the specification, a host computer is deployed with a host computer Agent client and a plurality of containers, and the operating system kernel of each container is independent of the operating system kernel of the host computer; the method comprises:
[0015] The security aspect program is injected into the operating system kernel of the container, so that the operating system kernel of the container runs the injected security aspect program, and the runtime behavior of the container is controlled through the security aspect program.
[0016] The runtime behavior of the container is controlled through the security aspect program.
[0017] The security management device of a container provided in the specification, a host computer is deployed with the device and a plurality of containers, and the operating system kernel of each container is independent of the operating system kernel of the host computer; the device comprises:
[0018] The acquisition module is used for obtaining the security aspect program corresponding to each container deployed on the host computer from the management service end;
[0019] The injection module is used for injecting the security aspect program into the operating system kernel of the container, so that the operating system kernel of the container runs the injected security aspect program, and the runtime behavior of the container is controlled through the security aspect program.
[0020] The security management device of a container provided in the specification, a host computer is deployed with a host computer Agent client and a plurality of devices, and the operating system kernel of each device is independent of the operating system kernel of the host computer; the device comprises:
[0021] The running module is used for running the injected security aspect program through the operating system kernel of the device; the security aspect program is obtained from the management service end by the host computer Agent client and injected into the operating system kernel of the device;
[0022] A control module is configured to control the runtime behavior of the device through the security aspect program.
[0023] The present specification provides a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the security management method of the container.
[0024] The present specification provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor implements the security management method of the container when executing the program.
[0025] The above at least one technical solution adopted by the embodiments of the present specification can achieve the following beneficial effects:
[0026] The embodiments of the present specification disclose a security management system of a container. A host computer is deployed with a host computer Agent client and a plurality of containers. The operating system kernel of each container is independent of the operating system kernel of the host computer. The host computer Agent client obtains, for each container deployed on the host computer where the host computer Agent client is located, a security aspect program corresponding to the container from a management server, and injects the security aspect program into the operating system kernel of the container, so that the container runs the injected security aspect program through its operating system kernel, and controls the runtime behavior of the container itself through the security aspect program. Since the operating system kernel of the container is independent of the host computer and does not share or depend on each other, the security management strategy of the container can be directly injected into the operating system kernel of the container in the form of a security aspect program to control the container through the security aspect program, thereby realizing security management at the container granularity. BRIEF DESCRIPTION OF DRAWINGS
[0027] The accompanying drawings, which are included to provide a further understanding of the present specification, constitute a part of the present specification, and the illustrative embodiments of the present specification and their description serve to explain the present specification, and do not constitute an improper limitation on the present specification. In the drawings:
[0028] Figure 1 A security management system of a container provided by the embodiments of the present specification;
[0029] Figure 2 A security management method of a container provided by the embodiments of the present specification;
[0030] Figure 3 Another security management method of a container provided by the embodiments of the present specification;
[0031] Figure 4A schematic diagram of a security management device of a container provided by an embodiment of the present specification is shown in the following figure.
[0032] Figure 5 A schematic diagram of another security management device of a container provided by an embodiment of the present specification is shown in the following figure.
[0033] Figure 6 A schematic diagram of the structure of an electronic device provided by an embodiment of the present specification is shown in the following figure. DETAILED DESCRIPTION
[0034] For the purpose, technical solutions and advantages of the present specification to be clearer, the technical solutions of the present specification will be described clearly and completely in the following with reference to the embodiments of the present specification and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present specification, but not all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present specification.
[0035] The technical solutions provided by the embodiments of the present specification will be described in detail below with reference to the drawings.
[0036] Figure 1 A schematic diagram of a security management system of a container provided by an embodiment of the present specification is shown in the following figure. The system comprises a management service end and a plurality of host computers. A host computer Agent client and a plurality of containers are deployed on each host computer. Wherein:
[0037] The management service end is used for managing the cluster composed of all the above-mentioned host computers, storing and issuing the security aspect program corresponding to each container.
[0038] Specifically, the management service end comprises an asset management module, a policy management module, a policy deployment module and a system function setting module.
[0039] The asset management module is used for collecting and storing the state information of all the containers in the cluster, including the type of the container, the cluster where the container is located, the application running on the container, the kernel version of the operating system, etc.
[0040] The policy management module is used for providing the functions of adding, deleting, modifying and inquiring the security management policy of each container for the user. The user can set and store the security aspect program corresponding to the security management policy of each container through the module.
[0041] The policy deployment module is used for issuing the security aspect program corresponding to the container to the container.
[0042] The system function setting is used for managing the global configuration of the management service end.
[0043] The management server can be implemented by Kubernetes (K8s for short), that is, the management server implements the arrangement and security management of all containers in the cluster. The management server can be implemented by a separate server or electronic device, or can be deployed on any host in the cluster.
[0044] The management server further includes a policy operation and maintenance module configured to package a security aspect program set by a user into a custom resource (CR), the CR defining a container and files, processes, networks, etc. to which the policy corresponding to the security aspect program needs to be applied, and delivering the CR containing the security aspect program to a host via a K8s interface service (Kubernetes API server).
[0045] A host, also referred to as a node, is a physical device in the cluster, which runs a host operating system, typically a Linux system. On the host operating system, a host agent client and a plurality of containers are further run, each of which also runs its own operating system, typically a Linux system. On the operating system of the container, a specific business or application is run.
[0046] Generally, for containers such as runc, the operating system kernel of the container and the operating system kernel of the host are shared, that is, the operating system kernel of the container is actually the operating system kernel of the host, which makes it difficult to implement different security management policies for different containers. Even if different security management policies can be implemented for different containers, the operating system kernel of the host needs to identify which container a security management policy needs to be applied to. Once the identification is wrong, the wrong security management policy will be used to manage the container, which seriously affects the operation of the business on the container. Moreover, if the security management policy triggers some bugs of the operating system kernel, it will directly affect all containers on the host. On the other hand, the shared operating system kernel of the host is also prone to container escape.
[0047] Therefore, the container used in the embodiments of the present specification is a container whose operating system kernel is completely independent of the operating system kernel of the host. The container can be a Kata container, of course, it can also be other containers. Those skilled in the art should understand that the container used in the embodiments of the present specification is not limited to the Kata container, as long as the operating system kernel of the container is independent of the operating system kernel of the host, and the two are not shared, dependent or independent of each other, which is within the protection scope of the present application. For convenience of description, the Kata container is taken as an example for description below.
[0048] The Kata container described in the specification is essentially a lightweight virtual machine running on the Linux system of the host machine. Each Kata container has its own independent operating system kernel, and the operating system of the Kata container can also be Linux. The version of the Linux system kernel of the Kata container can be different from the version of the Linux system kernel of the host machine, and the version of the Linux system kernel of the Kata container can even be higher than the version of the Linux system kernel of the host machine, and there is no dependency between the two. Of course, the operating system of the Kata container can also be other operating systems. The following still takes the operating system of the Kata container as a Linux system as an example for description.
[0049] The host machine also runs a host machine Agent client, which is used to obtain the security aspect program corresponding to each container deployed on the host machine where the host machine Agent client is located from the management service end, and inject the security aspect program into the operating system kernel of the container.
[0050] Specifically, after the policy operation module of the management service end submits the CR containing the security aspect program to the K8sAPI server, the K8sAPI server will notify the host machine Agent client. The host machine Agent client detects whether there is an updated security aspect program corresponding to each container deployed on the host machine where the host machine Agent client is located on the management service end, including a newly created security aspect program or a modified security aspect program. That is, the host machine Agent client listens in real time whether to receive the notification of the K8sAPI server. If the notification is received, the security aspect program contained in the newly created CR notified by the K8sAPI server is determined as the updated security aspect program, the identification of the container contained in the newly created CR is determined as the identification of the container to which the policy corresponding to the security aspect program needs to be applied, and the updated security aspect program contained in the CR is obtained from the management service end and injected into the operating system kernel of the container corresponding to the identification of the container.
[0051] Correspondingly, for any Kata container, the injected security aspect program can be run through the Linux system kernel of the container, and the behavior of the runtime of the container can be controlled through the security aspect program.
[0052] When the operating system of the Kata container is a Linux system, the security facet program in the embodiments of the present specification can be an eBPF program, which can be defined and written by the user according to the security policy for controlling the behavior of the runtime of the container. Since the attack behavior of the container is generally related to at least one of the process behavior, network access behavior, file access behavior and system call behavior of the runtime of the container, the eBPF program in the embodiments of the present specification can also control at least one of the process behavior, network access behavior, file access behavior and system call behavior of the runtime of the container.
[0053] Since the operating system kernel of the container in the above system is independent of the host machine and does not share or depend on each other, the security management policy of the container can be directly injected into the operating system kernel of the container in the form of a security facet program to control the container through the security facet program, thereby realizing security management at the container granularity. While providing security management capability at the container granularity, the system does not need to use the operating system kernel of the host machine to identify which container a security management policy needs to be applied to, and even if the security management policy triggers a bug of the operating system kernel, the impact will be limited within one container and will not affect other containers on the host machine. Moreover, since the operating system kernels of the containers are completely independent, the container escape is directly cut off at the root.
[0054] Next, the implementation method of the host machine Agent client on the host machine will be described in detail in combination with the system as shown in Figure 1 . Figure 2
[0055] Figure 2 A security management method flowchart of a container provided by the embodiments of the present specification is shown in the figure. The method is applied to a host machine Agent client on a host machine and specifically includes the following steps:
[0056] S200: For each container deployed on the host machine, obtain the security facet program corresponding to the container from the management service end.
[0057] As mentioned above, the host machine Agent client can listen to and detect in real time whether the notification of the K8s API server is received. If the notification is received, it is determined that the updated security facet program contained in the newly created CR notified by the K8s API server and the identifier of the container, and then the updated security facet program contained in the CR is obtained from the management service end.
[0058] Specifically, the host machine Agent client can also obtain state information of each container deployed on the host machine where the host machine Agent client is located, and report the state information of the container to the management server. The state information of each container is saved in the asset management module of the management server.
[0059] Before providing the security facet program corresponding to a container to the host machine Agent client, the management server can also determine whether the security facet program corresponding to the container meets a preset delivery condition according to the state of the container and the security facet program corresponding to the container. If yes, the management server provides the security facet program to the host machine Agent client, otherwise, the management server refuses to provide the security facet program to the host machine Agent client.
[0060] Since the eBPF program customized by the user can have certain requirements for the type of the container and the kernel version of the Linux system of the container, the above-mentioned preset delivery condition can include the type of the container that can run the eBPF program (such as requiring to be a Kata container) and / or the version of the operating system kernel that can run the eBPF program.
[0061] S202: Injecting the security facet program into the operating system kernel of the container, so that the operating system kernel of the container runs the injected security facet program, and controlling the runtime behavior of the container through the security facet program.
[0062] After obtaining the eBPF program, the host machine Agent client can inject the eBPF program into the kernel of the Linux system of the Kata container. The communication channel between the host machine Agent client and the Kata container is veBPF, so the host machine Agent client can inject the eBPF program into the kernel of the Linux system of the Kata container through the veBPF channel.
[0063] Through the veBPF channel, the host machine Agent client can also collect logs generated when the security facet program is executed by the runtime behavior of the container, and report the logs to the management server. How the security facet program is triggered and how the logs are generated will be described later.
[0064] The host machine Agent client can also determine whether there is an abnormal security facet program in each container deployed on the host machine, and if yes, report the abnormal security facet program to the management server. The abnormal security facet program includes but is not limited to a security facet program that cannot be normally injected, a security facet program that cannot be normally run, and the like.
[0065] In order not to affect the stability of the business running on the container, the host machine Agent client can also unload the security aspect program injected on one or several containers. Specifically, the host machine Agent client can monitor whether the load of each container on the host machine where the host machine Agent client is located is higher than a preset threshold in real time, and if so, the security aspect program injected in the operating system kernel of the container can be unloaded. When unloading the security aspect program, part or all of the injected security aspect program can be unloaded according to a preset rule, such as only unloading the security aspect program other than the default security aspect program.
[0066] In the embodiments of the present specification, the default security aspect program refers to a security aspect program that needs to be injected into the operating system kernel of the container regardless of the business or application running on the container, and the other security aspect program refers to a security aspect program that is customized for the container by the user for the business or application running on the container.
[0067] Next, the implementation method of the container for controlling the runtime behavior of the container on the host machine will be described in detail with reference to the system as shown in Figure 1 . Figure 3 .
[0068] Figure 3 Another security management method of a container provided in the embodiments of the present specification is provided, and the method is applied to any container on a host machine, and specifically includes the following steps:
[0069] S300: Running the injected security aspect program through the operating system kernel of the container.
[0070] The security aspect program is obtained from the management server by the host machine Agent client and injected into the operating system kernel of the container.
[0071] S302: Controlling the runtime behavior of the container through the security aspect program.
[0072] In the embodiments of the present specification, the security aspect program is injected into the pointcut of the operating system kernel, and once the operating system kernel executes the code to the aspect, the security aspect program is triggered. Then, the operating system kernel executes step S300 to run the security aspect program when the security aspect program is triggered, and controls the runtime behavior of the container through step S302 by running the security aspect program. For the Linux system, the eBPF program is the point insertion of the kernel of the Linux system.
[0073] As mentioned above, since the attack behavior on the container is generally related to at least one of the process behavior, the network access behavior, the file access behavior, and the system call behavior of the runtime of the container, the eBPF program in the embodiments of the present specification can also control at least one of the process behavior, the network access behavior, the file access behavior, and the system call behavior of the runtime of the container.
[0074] Since the Kata container has a Linux security module (LSM) in the Linux system, the LSM itself does not provide security capabilities, but is a general lightweight security access control framework defined in the Linux system kernel, which can inject different security policies into the kernel by providing a series of interfaces. These interfaces are a series of static tracing points reserved on the kernel critical path, so in the embodiments of the present specification, these static tracing points reserved by the LSM can be directly used as the above-mentioned cut points, and the eBPF security aspect program is inserted at these cut points to implement the security management policy corresponding to the eBPF program on the specified Linux system kernel path.
[0075] Specifically, when controlling the process behavior of the runtime of the container, the host machine Agent client can inject an eBPF program at a tracing point (referred to as a first tracing point herein) in a system call for executing a new process in the Linux system of the container. Wherein, the system call for executing a new process includes execve. That is to say, when an attacker creates and runs a new process in the Kata container, the Linux system kernel of the container must execute the system call execve to create and run a new process, so the eBPF program can be injected at the first tracing point in the system call execve.
[0076] Since the LSM itself has reserved a static tracing point in the system call execve, the static tracing point reserved by the LSM in the system call execve can be directly used as the first tracing point to inject the eBPF program, so that the eBPF program is triggered as soon as the Linux system kernel of the container executes the system call execve, thereby running the eBPF program, and further controlling the behavior of the Linux system kernel executing the system call execve through the eBPF program.
[0077] The control of the behavior of the Linux system kernel executing the system call execve described in the present specification at least includes generating a log of the container executing the system call execve. It can also include intercepting the behavior of the Linux system kernel executing the system call execve.
[0078] In the process of controlling the network access behavior of the container runtime, the host Agent client can inject an eBPF program into a trace point (hereinafter referred to as a second trace point) in the process control program of the Linux system of the container. Since the user-defined eBPF program for controlling network access needs to obtain as much service semantics in the network packet as possible on the one hand, and may need to intercept the behavior of the network access on the other hand, the second trace point described in the specification can include: a static trace point reserved by the LSM of the Linux system of the container in the process control program for network control, and / or a trace point in the process control program in the Traffic Control (TC) layer of the Linux system of the container for network control.
[0079] Since the process control program for network control in the LSM layer or the process control program for network control in the TC layer will be triggered to run as soon as the Linux system needs to perform network access, the eBPF program can be injected into these process control programs, so that the eBPF program will be triggered along with the triggering of these process control programs.
[0080] The control of the Linux system kernel for network access described in the specification at least includes generating a log of the network access of the container. It can also include intercepting the network access of the container.
[0081] In the process of controlling the file access behavior of the container runtime, the host Agent client can inject an eBPF program into a trace point (hereinafter referred to as a third trace point) in the file control program of the Linux system of the container. Since the LSM of the Linux system also reserves a static trace point in the file control program, the static trace point reserved by the LSM in the file control program can be directly used as the third trace point to inject the eBPF program in the embodiments of the specification.
[0082] Once the Linux system kernel accesses a file, the file control program will be triggered, and the injected eBPF program will also be triggered.
[0083] The control of the Linux system kernel for file access described in the specification at least includes generating a log of the file access of the container. It can also include intercepting the file access behavior of the container.
[0084] When the system call behavior of the runtime of the container is controlled, the host agent client can inject the eBPF program into the trace point in each system call of the Linux system of the container. Since the LSM has reserved static trace points in some system calls of Linux, and some system calls LSM does not reserve static trace points. Therefore, for a system call, if the LSM reserves a static trace point for the system call, the fourth trace point can include: the static trace point reserved by the LSM of the Linux system of the container in the system call. If the LSM does not reserve a static trace point for the system call, the fourth trace point can include: a trace point in the program of the syscall layer of the Linux system of the container for monitoring the system call, or setting a trace point directly in the system call.
[0085] The above log can record information related to the security policy and metadata information related to the event.
[0086] The information related to the security policy is related to the specific security logic of the eBPF program. For example, when the process behavior of the runtime of the container is controlled, the information related to the security policy can be whether the eBPF intercepts the behavior of executing the system call execve. When the network access behavior of the runtime of the container is controlled, the information related to the security policy can be whether the eBPF intercepts the network access behavior, and the identification of the network to be accessed by the runtime of the container (such as a network address). When the file access behavior of the runtime of the container is controlled, the information related to the security policy can be whether the eBPF intercepts the file access behavior, and the identification of the network to be accessed (such as the fd (file descriptor) representing the file and / or the inode representing the path of the file). When the system call behavior of the runtime of the container is controlled, the information related to the security policy can be whether the eBPF intercepts the executed system call, and the function corresponding to the system call.
[0087] The event metadata information includes the triggering time of the event triggering the eBPF, the process name, the process completion path, the parent process, the user ID of the process, and other basic information, and can also include the virtual machine ID of the Kata container to which the event occurs, and the container-related metadata such as the image ID.
[0088] Those skilled in the art should understand that the information required to be recorded in the above logs can be set as needed, as long as the logs record the basic information capable of identifying the event that triggers the eBPF program, the basic information of the process that triggers the eBPF program, and the basic information of the container into which the eBPF program is injected. Moreover, the logs generated by the default security facet program in this specification and the logs generated by other security facet programs can be saved in different log files.
[0089] In addition, by the system shown in the above Figure 1 and the method shown in the above Figures 2-3 The security management system provided in this specification can provide a security management capability of container granularity and covering four behaviors of process behavior, network access behavior, file access behavior, and system call behavior of the container runtime. This capability is not limited to generating logs, but also can intercept these behaviors. As for the security management policy corresponding to the eBPF program (i.e., the security facet program in this specification), this specification does not limit what policy (e.g., what behavior needs to be controlled by the eBPF program under what conditions) the eBPF program corresponds to. This needs to be determined according to the business running in the container. The following only illustrates an exemplary embodiment of the security management policy that the eBPF program can implement.
[0090] For example, when using Kata container as the computer of the AI agent, the logs generated by the above method can be used to audit the process creation (process behavior), network connection request and dns request (network access behavior), mount call (system call behavior), and file creation and modification (file access behavior) of the container runtime. Non-image programs can also be intercepted. For example, for a process, if the program to which the process belongs is a non-image program, the eBPF program directly intercepts the execution of the process. Specifically, since the AI agent usually only executes business programs and related operation and maintenance scripts, these executable files are located in the lower layer of the image of the container. This means that the executable file is originally included in the image. If an executable file is located in the upper layer of the image of the container, it means that the executable file is newly added or modified from the original executable file. Therefore, the eBPF program can determine whether the executable file of the program is located in the upper layer of the image. If so, the eBPF program directly intercepts the process corresponding to the executable file. Alternatively, the eBPF program can also directly maintain a whitelist to allow only the programs or processes in the whitelist to execute.
[0091] Those skilled in the art should understand that all the security management policies implemented by the eBPF programs in the above example are exemplary, and in fact the security management policies implemented by the eBPF programs can be defined according to the services running on the container and actual needs, and the embodiments of the present specification do not limit this.
[0092] The above is a container security management system and method provided by the embodiments of the present specification. Based on the same idea, the present specification also provides a corresponding device, a storage medium and an electronic device.
[0093] Figure 4 A container security management device provided by the embodiments of the present specification is shown in the schematic diagram. The host computer is deployed with a device and a plurality of containers. The operating system kernel of each container is independent of the operating system kernel of the host computer. The device comprises:
[0094] The acquisition module 401 is configured to acquire, for each container deployed on the host computer, the security aspect program corresponding to the container from the management service end.
[0095] The injection module 402 is configured to inject the security aspect program into the operating system kernel of the container, so that the operating system kernel of the container runs the injected security aspect program, and controls the runtime behavior of the container through the security aspect program.
[0096] Optionally, the acquisition module 401 is specifically configured to detect whether there is an updated security aspect program corresponding to the container on the management service end; if so, acquire the updated security aspect program from the management service end.
[0097] Optionally, the acquisition module 401 is further configured to acquire, for each container deployed on the host computer, state information of the container; and report the state information of the container to the management service end.
[0098] The acquisition module 401 is specifically configured to acquire, from the management service end, the security aspect program corresponding to the container when the management service end determines that the security aspect program corresponding to the container meets the preset delivery condition according to the state of the container and the security aspect program corresponding to the container.
[0099] Optionally, the acquisition module 401 is further configured to judge, for each container deployed on the host computer, whether there is an abnormal security aspect program in the container; if so, report the abnormal security aspect program to the management service end.
[0100] Optionally, the acquisition module 401 is further configured to collect logs generated when the security aspect program is triggered by the runtime behavior of the container; and report the logs to the management service end.
[0101] Figure 5 Another schematic diagram of a security management device of a container is provided in the embodiments of the present specification, a host computer is deployed with a host computer Agent client and a plurality of the devices, and the operating system kernel of each of the devices is independent of the operating system kernel of the host computer; the device comprises:
[0102] a running module 501, configured to run the injected security facet program through the operating system kernel of the device; the security facet program is obtained by the host computer Agent client from a management server and injected into the operating system kernel of the device;
[0103] a control module 502, configured to control the runtime behavior of the device through the security facet program.
[0104] Optionally, the control module 502 is specifically configured to control at least one of the process behavior, the network access behavior, the file access behavior, and the system call behavior of the runtime of the container.
[0105] Optionally, the operating system of the container is Linux.
[0106] The security facet program is injected into the Linux system of the container to execute a first trace point in a system call for starting a new process; the first trace point is a static trace point reserved by a Linux security module LSM of the Linux system in the system call;
[0107] The control module 502 is specifically configured to, when the container executes the system call, generate a log of the container executing the system call through the security facet program injected in the first trace point, and / or intercept the execution of the system call.
[0108] Optionally, the operating system of the container is Linux.
[0109] The security facet program is injected into a second trace point in a process control program of the Linux system of the container; the second trace point is a static trace point reserved by a Linux security module LSM of the Linux system in the process control program for network control, and / or a trace point in the process control program for network control in a traffic control TC layer of the Linux system;
[0110] The control module 502 is specifically configured to, when the container performs network access, generate a log of the container performing network access through the security facet program injected in the second trace point, and / or intercept the network access performed by the container.
[0111] Optionally, the operating system of the container is Linux.
[0112] The security facet program injects a third trace point in a file control program of the Linux system of the container; the third trace point is a static trace point reserved by a Linux security module (LSM) of the Linux system in the file control program;
[0113] The management module 502 is specifically configured to, when the container accesses a file, generate a log of the container accessing the file and / or intercept the behavior of the container accessing the file through the security facet program injected in the third trace point.
[0114] Optionally, the operating system of the container is Linux.
[0115] The security facet program injects a fourth trace point in each system call of the Linux system of the container; the fourth trace point is a static trace point reserved by a Linux security module (LSM) of the Linux system in the system call and / or a trace point in a program of a syscall layer of the Linux system for monitoring each system call;
[0116] The management module 502 is specifically configured to, when the container executes any system call, generate a log of the container executing the system call and / or intercept the container executing the system call through the security facet program injected in the fourth trace point.
[0117] The present specification also provides a computer readable storage medium, which stores a computer program, and the computer program is executable by a processor to execute the above-provided TFHE-based data processing method.
[0118] Based on Figure 1 The security management system of the container shown in the specification and Figures 2-3 The security management method of the container shown in the specification, the present specification also provides Figure 6 The structural diagram of the electronic device shown in the specification. As Figure 6 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory and a non-volatile memory, and of course, it can also include other hardware required by the business. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs to implement the above-mentioned security management method of the container.
[0119] The above merely provides the example of the present application, but does not serve to limit the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application should be included in the scope of claims of the present application.
Claims
1. A container security management system, the system comprising: Management server and several host machines; the host machine is deployed with a host agent client and several containers; the operating system kernel of each container is independent of the operating system kernel of the host machine; The management server is used to store the security aspect program corresponding to each container; The host agent client is used to obtain the security aspect program corresponding to each container deployed on the host machine where the host agent client is located from the management server, and inject the security aspect program into the operating system kernel of the container; Any of the containers is used to run the injected security aspect program through the operating system kernel of the container, and to manage and control the runtime behavior of the container through the security aspect program.
2. The system according to claim 1, wherein the operating system of the host machine is Linux; The container is a Kata container; The security aspect program is an eBPF program.
3. In the system as described in claim 1, the host agent client is specifically used to detect whether there is an updated security aspect program corresponding to each container deployed on the host where the host is located on the management server; if so, obtain the updated security aspect program from the management server.
4. The system according to claim 1, wherein the host agent client is further configured to obtain status information of each container deployed on the host machine where the host agent client is located, and report the status information of the container to the management server; The management server is further configured to determine, based on the state of the container and the security aspect program corresponding to the container, whether the security aspect program corresponding to the container meets a preset delivery condition before providing the security aspect program corresponding to the container to the host agent client.
5. The system as claimed in claim 1, wherein the host agent client is further used to determine whether there is an abnormal security aspect program in the container, and if so, report the abnormal security aspect program to the management server.
6. The system of claim 1, wherein the container is configured to generate a log through the injected security aspect program when runtime behavior of the container triggers the injected security aspect program; The host agent client is further configured to collect logs generated when the security aspect program is triggered by the runtime behavior of the container, and report the logs to the management server.
7. A container security management method, wherein a host agent client and several containers are deployed on a host machine, and the operating system kernel of each container is independent of the operating system kernel of the host machine; the method comprises: For each container deployed on the host, obtain the security aspect program corresponding to the container from the management server; The security aspect program is injected into the operating system kernel of the container, so that the operating system kernel of the container runs the injected security aspect program, and the runtime behavior of the container is controlled through the security aspect program.
8. The method according to claim 7, wherein obtaining the security aspect program corresponding to the container from the management server comprises: Detecting whether an updated security aspect program corresponding to the container exists on the management server; If so, obtain the updated security aspect program from the management server.
9. The method of claim 7, further comprising: For each container deployed on the host machine, obtain the status information of the container; Reporting the status information of the container to the management server; Obtaining the security aspect program corresponding to the container from the management server, specifically including: When the management server determines, based on the state of the container and the security aspect program corresponding to the container, that the security aspect program corresponding to the container meets the preset delivery conditions, the security aspect program corresponding to the container is obtained from the management server.
10. The method of claim 7, further comprising: For each container deployed on the host machine, determine whether there is an abnormal security aspect program in the container; If so, the abnormal security aspect program is reported to the management server.
11. The method of claim 7, further comprising: Collect logs generated when the security aspect program is triggered by the runtime behavior of the container; Report the log to the management server.
12. A container security management method, wherein a host agent client and several containers are deployed on a host machine, and the operating system kernel of each container is independent of the operating system kernel of the host machine; the method comprises: Run the injected security aspect program through the operating system kernel of the container; The security aspect program is obtained by the host agent client from the management server and injected into the operating system kernel of the container; The runtime behavior of the container is controlled through the security aspect program.
13. The method according to claim 12, wherein managing and controlling the runtime behavior of the container comprises: At least one of process behavior, network access behavior, file access behavior, and system call behavior during runtime of the container is managed and controlled.
14. The method according to claim 13, wherein the operating system of the container is Linux; The security aspect program is injected into a first tracing point in a system call for executing a new process in the Linux system of the container; the first tracing point is a static tracing point reserved by the Linux Security Module LSM of the Linux system in the system call; Control the runtime behavior of the container, including: When the container executes the system call, a log of the container executing the system call is generated through the security aspect program injected into the first tracking point, and / or the execution of the system call is intercepted.
15. The method according to claim 13, wherein the operating system of the container is Linux; The security aspect program injects a second tracking point into the process control program of the Linux system of the container; the second tracking point is a static tracking point reserved by the Linux Security Module (LSM) of the Linux system in the process control program for network control, and / or a tracking point in the process control program for network control in the traffic control (TC) layer of the Linux system; Control the runtime network access behavior of the container, including: When the container performs network access, a log of the network access performed by the container is generated through the security aspect program injected into the second tracking point, and / or the network access performed by the container is intercepted.
16. The method according to claim 13, wherein the operating system of the container is Linux; The security aspect program injects a third tracking point into the file control program of the Linux system of the container; the third tracking point is a static tracking point reserved by the Linux Security Module LSM of the Linux system in the file control program; Manage and control file access behavior during runtime of the container, specifically including: When the container accesses a file, a log of the container accessing the file is generated and / or the behavior of the container accessing the file is intercepted through the security aspect program injected into the third tracking point.
17. The method according to claim 13, wherein the operating system of the container is Linux; The security aspect program injects a fourth tracing point into each system call of the Linux system of the container; the fourth tracing point is a static tracing point reserved by the Linux Security Module (LSM) of the Linux system in the system call, and / or a tracing point in a program for monitoring each system call in the syscall layer of the Linux system; Control the runtime system call behavior of the container, including: When the container executes any system call, a log of the system call executed by the container is generated and / or the system call executed by the container is intercepted through the security aspect program injected into the fourth tracking point.
18. A container security management device, comprising: a device and a plurality of containers deployed on a host machine; an operating system kernel of each container is independent of the operating system kernel of the host machine; the device comprising: The acquisition module is used to obtain the security aspect program corresponding to each container deployed on the host from the management server; An injection module is used to inject the security aspect program into the operating system kernel of the container, so that the operating system kernel of the container runs the injected security aspect program, and through the security aspect program, the runtime behavior of the container is controlled.
19. A container security management device, comprising a host agent client and a plurality of the devices deployed on a host machine, wherein the operating system kernel of each device is independent of the operating system kernel of the host machine; the device comprising: An operating module, configured to execute the injected security aspect program through the operating system kernel of the device; The security aspect program is obtained by the host agent client from the management server and injected into the operating system kernel of the device; The control module is used to control the runtime behavior of the device through the security aspect program.
20. A computer-readable storage medium storing a computer program, wherein the computer program implements the method according to any one of claims 7 to 17 when executed by a processor.
21. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 7 to 17 when executing the program.