Lightweight access control method during container operation based on ebpf
By using ebpf technology during container runtime, monitoring system calls and controlling file access according to policy tables, the risk of sensitive files in the container environment being tampered with is solved, and the precise protection of the access to host resources in the container is achieved, which improves the security of the physical machine.
Patent Information
- Application Number
- CN202311547935.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-20
- Publication Date
- 2025-05-20
AI Technical Summary
In a container environment, containers are not as securely isolated as virtual machines, and there is a risk that sensitive files are tampered with. In particular, privileged containers can modify sensitive files of the host, affecting the security of the physical machine.
The container runtime lightweight access control method is adopted based on EBPF. The eBPF interface is registered by monitoring components and Fileaccess components, and the system calls are monitored. The process in the container has permission to access files based on the predefined policy table, so as to protect sensitive files.
It effectively prevents sensitive files in containers from being tampered with, reduces the impact on physical machine security, and improves the reusability of the system and supports secondary development and optimization capabilities under the Linux platform.
Smart Images

Figure CN120020781A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of information security technology, and particularly to a lightweight access control method for container runtimes based on eBPF. Background Art
[0002] RedHat pointed out in the "2022 Kubernetes Security Report": More than 300 DevOps, engineering, and security professionals were surveyed, and it was found that 93% of the respondents had experienced security incidents in Kubernetes and container environments in the past 12 months. There may be various factors behind this, including a lack of security knowledge about containers and Kubernetes, insufficient or inappropriate security tools. Containers are not as securely isolated as virtual machines. By default, they expose a large amount of information about the host operating system, which is sensitive and provides the possibility of "escaping" from the container. For example, the kernel file system under / sys and there are many sysctls under / proc / sys. For non-privileged containers, the content of these files is read-only; for privileged containers, they can be written to. Therefore, it is necessary to design a protection mechanism for the host to pass accessible files to the container during container runtime to prevent sensitive files in the container from being tampered with, and even privileged containers cannot modify the protected files.
[0003] In the prior art, SELinux can strengthen container isolation, ensure that containers can only access the resources they are allowed to, and allow administrators to define very detailed access control rules to ensure that containers can only perform the operations they are allowed to, thereby reducing the attack surface of containers. However, after enabling elinux, it will cause a performance loss of about 20% to the system performance; when configuring policies for the business, professional R & D engineers are usually required. Summary of the Invention
[0004] To solve the deficiencies of the existing technology, the present invention provides a lightweight access control method for container runtimes based on eBPF, including the following steps: Step S1: The monitoring component registers an eBPF interface to monitor the processes running in the container and detect whether there are new processes running in the container; Step S2: fileaccess registers an eBPF interface to monitor system calls and determine whether the processes in the container have permission to access files according to the policy.
[0005] Wherein, in the said step S2, fileaccess determines whether the processes in the container have permission to access files according to the policy through the following steps: Step S21: A new process is generated in the container, and the process information is obtained; Step S22: Update the container process information to the bpf map; Step S23: The process accesses a file; Step S24: fileaccess checks the bpf map to determine the type of the process. If it is a host process, it is directly allowed to pass. If it is a host process, step S25 is executed; Step S25: Query the policy table and decide whether the container process has the permission to access the file according to the policy table result.
[0006] Among them, in the said step S25, the following principle is adopted to decide whether the container process has the permission to access the file: Step S251: Check in turn whether the file is in the rejection list of the container policy table, the rejection list of the image policy table or the rejection list of the default policy table. If so, reject the container process from accessing; Step S252: Check in turn whether the file is in the allow list of the container policy table, the allow list of the image policy table or the allow list of the default policy table. If so, allow the container process to access; Step S253: If the file does not exist in any list of any policy table listed in step S251 and step S252, reject the container process from accessing.
[0007] The present invention provides a protection mechanism for the host to pass accessible files to the container during the container runtime based on ebpf, and conducts a detailed design and sorting of the control mechanism and the policy management mechanism. By setting policies, it accurately protects the access to host resources within the container and prevents sensitive files in the container from being tampered with and affecting the security of the physical machine. This solution has reusability and supports secondary development and optimization under the linux platform. Brief Description of the Drawings
[0008] Figure 1 It is a logical framework diagram of the lightweight file access control mechanism for the container runtime based on ebpf of the present invention.
[0009] Figure 2 It is an implementation flowchart of the lightweight file access control mechanism for the container runtime based on ebpf of the present invention.
[0010] Figure 3 It is an implementation flowchart of a specific embodiment of the present invention.
[0011] Figure 4 It is a schematic diagram of the policy update process of the present invention. Detailed Embodiment
[0012] In order to have a further understanding of the technical solution and beneficial effects of the present invention, the technical solution of the present invention and the beneficial effects produced thereby will be described in detail below with reference to the drawings.
[0013] The present invention provides a protection mechanism for host - transmitted accessible files in a container runtime based on eBPF, which accurately protects the host resources in the container by configuring policies and prevents sensitive files in the container from being tampered with, thus affecting the security of the host.
[0014] Figure 1 It is the logic framework diagram of the lightweight file access control mechanism for the container runtime based on eBPF of the present invention. As Figure 1 shown, the present invention provides a protection mechanism for host - transmitted accessible files in a container runtime based on eBPF. This mechanism provides a background service, a monitoring component, a Fileaccess component, and policies. The background service is the main body of this mechanism, responsible for providing a management entry and a monitoring mechanism; the monitoring component is the most core module and is part of the background service. By registering eBPF interfaces, it monitors the processes running in the container to detect whether there are new processes running in the container; the Fileaccess component is the specific protection mechanism. By registering eBPF interfaces, it monitors system calls and decides whether the processes in the container have the permission to access files according to the policies; the policies mainly define which host - transmitted files to the container need to be protected. There can be default policies that are effective for all images and containers, or they can be configured for a single image or container.
[0015] Figure 2 It is the implementation flowchart of the lightweight file access control mechanism for the container runtime based on eBPF of the present invention. As Figure 2 shown, when fileaccess is loaded, default configurations will be sent to eBPF, and at the same time, each container and image can define file access policies. When any process in the container accesses a file, fileaccess will perform the following policy matching process: 1. Check in turn whether the file is in the container file deny list (for the container policy table), the imagefile deny (for the image policy table) list, and the default file deny list. If so, the container process will be denied access.
[0016] 2. Check in turn whether the file is in the container file allow list (for the container policy table), the image file allow list (for the image policy table), and the default file allow list. If so, the container process will be allowed access.
[0017] 3. If no match is found in the above file list, access by the container process will be denied.
[0018] Figure 3 It is a flowchart for implementing a specific embodiment of the present invention, related to the file access control management process: 1. When a new process is generated in the container, the process information is obtained. 2. Update the container process information to the bpf map. 3. The process performs a write access to a file. 4. fileaccess checks the bpf map to confirm whether the process is a container process or a host process. If it is a host process, it is directly allowed to pass; if it is a container process, step 5 is executed. 5. Query the deny and access policy tables. 6. Return the query result. 7. fileaccess determines whether the container process can access the file according to the query result.
[0019] Figure 4 It is a schematic diagram of the policy update process of the present invention. Taking adding a policy as an example, as Figure 4 shown, it includes the following steps: 1. Start the command-line tool to add a certain file to be denied access in the container. 2. Check whether the file is already in the deny policy. 3. If it is, return that it already exists; if not, check whether it is added to the image or the container, and go to step 9. 4. Add a certain file to be allowed access in the container. 5. Check whether the file is already in the deny policy. 6. If it is, delete it from the deny polcy. 7. If not, continue to query the allow policy. 8. If it is, return success; if not, check whether it is added to the image or the container. 9. Update the policy table.
[0020] The present invention provides a protection mechanism for the host to transparently transmit accessible files to the container based on ebpf, and conducts a detailed design and sorting of the control mechanism and the policy management mechanism. By setting policies, it accurately protects the access to host resources in the container and prevents sensitive files in the container from being tampered with and affecting the security of the physical machine. This solution has reusability and supports secondary development and optimization under the linux platform.
[0021] Although the present invention has been described by using the above preferred embodiments, it is not intended to limit the protection scope of the present invention. Any person skilled in the art can make various changes and modifications to the above embodiments without departing from the spirit and scope of the present invention, and these still fall within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be defined by the claims.
Claims
1. A lightweight access control method for container runtime based on ebpf, characterized in that: The steps include: Step S1: The monitoring component registers the ebpf interface, monitors the processes running in the container, and detects whether there are new processes running in the container; Step S2: fileaccess registers the ebpf interface, monitors system calls, and determines whether the process in the container has permission to access the file based on the policy.
2. The container runtime lightweight access control method based on ebpf as claimed in claim 1 is characterized in that: In step S2, fileaccess determines whether the process in the container has permission to access the file according to the policy through the following steps: Step S21: a new process is generated in the container, and the process information is obtained; Step S22: Update container process information to bpf map; Step S23: the process accesses a file; Step S24: fileaccess checks the bpf map to determine the type of the process. If it is a host process, it is directly released. If it is a host process, step S25 is executed; Step S25: query the policy table, and determine whether the container process has permission to access the file based on the policy table result.
3. The container runtime lightweight access control method based on ebpf as claimed in claim 2 is characterized in that: In step S25, whether the container process has permission to access the file is determined according to the following principles: Step S251: Check in sequence whether the file is in the deny list for the container policy table, the deny list for the image policy table, or the deny list for the default policy table. If yes, deny access to the container process. Step S252: Check in sequence whether the file is in the allowed list for the container policy table, the allowed list for the image policy table, or the allowed list for the default policy table. If yes, allow the container process to access it. Step S253: If the file does not exist in any table of any policy table listed in step S251 and step S252, the container process is denied access.