Kernel-level resource creation management and control method and system based on eBPF

Abstract

The invention discloses a kernel-level resource creation management and control method and system based on an eBPF. The method comprises the steps that when a system kernel receives a creation request of a virtual machine and / or a container, an eBPF verification module reads an authorization strategy corresponding to the creation request from an eBPF Map; judging whether the creation request of the virtual machine and / or the container conforms to the authorization strategy or not; if the authorization strategy is met, the execution of the virtual machine and / or container creation request is allowed, and the creation of the virtual machine and / or container is completed; if the authorization policy is not met, stopping the execution of the virtual machine and / or container creation request; and the eBPF verification module runs in a system kernel and executes verification operation of the authorization strategy in real time. According to the method, the eBPF strategy engine is deployed in the Linux kernel, the creation requests of the container and the virtual machine are intercepted and verified in real time, and dynamic blocking and automatic destroying of unauthorized resources are achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing, and particularly to a kernel-level resource creation control method and system based on eBPF. Background Art

[0002] In modern cloud computing and virtualization environments, resource scheduling and management are crucial for ensuring system security and resource utilization efficiency. Existing technologies usually utilize resource scheduling systems (such as Kubernetes' Scheduler and OpenStack's Nova Scheduler), which typically allocate nodes and resources for the creation of containers or virtual machines based on policies and resource status. Containers: In a Kubernetes environment, Admission Controller and Webhook are used for admission control before resource creation to restrict users' resource usage behaviors. In a virtualization management system for virtual machines, predefined policies or static configurations are used to control resource allocation. When resource limits are exceeded or unauthorized creation occurs, the system usually rejects the allocation. Additionally, with the help of monitoring systems such as Prometheus and Grafana, administrators can monitor the resource usage of server nodes, including CPU, memory, and storage. In some scenarios, if abnormal or unauthorized resources are detected, resources may be reclaimed through scripts or batch cleaning tools.

[0003] Although existing technologies have achieved certain results in resource scheduling and control, there are obvious deficiencies in strong control and real-time performance, which are specifically manifested in the following aspects:

[0004] 1. Passivity of authorization verification

[0005] Existing admission control mechanisms (such as Kubernetes Admission Controller or OpenStack policy rules) are limited to the review before resource creation and rely on user-space logic for implementation. If resources are directly created through underlying interfaces (such as CRI, QEMU, or Docker CLI), the scheduling system may be bypassed, resulting in the existence of unauthorized resources.

[0006] 2. Insufficient real-time performance

[0007] Current monitoring and cleaning mechanisms are mostly periodic scans or manual triggers, and cannot block and destroy unauthorized resources in real time, which may lead to resource abuse or security risks.

[0008] 3. Lack of kernel-space policy execution ability

[0009] Current situation: The existing technologies do not enforce mandatory policies in the critical path of resource creation (such as system calls and cgroup operations). The scheduling system can only be responsible for the scheduling results and cannot directly restrict the underlying resource creation behavior.

[0010] 4. Scalability and flexibility limitations

[0011] Current situation: Admission control and policy enforcement mostly rely on static rules (such as hardcoded policy files), making it difficult to meet the resource management requirements in multi-tenant and highly dynamic environments.

[0012] 5. Low granularity

[0013] Current situation: Resource monitoring and management are mostly based on the overall state of nodes, lacking refined control over the life cycle of specific workloads (such as a certain container or virtual machine).

[0014] These drawbacks make the existing resource management technologies difficult to meet the strong control requirements in high-security, high-real-time, and multi-tenant environments. Summary of the Invention

[0015] To solve the problem that the existing resource scheduling and management in cloud computing are prone to bypass the scheduling system, the purpose of the present invention is to propose a kernel-level resource creation control method based on eBPF (Extended Berkeley Packet Filter) to achieve real-time and refined management of virtual machine and container resource creation.

[0016] The technical solution adopted by the present invention is as follows:

[0017] A kernel-level resource creation control method based on eBPF (Extended Berkeley Packet Filter) includes the following steps:

[0018] When the system kernel receives a virtual machine and / or container creation request sent by a request sender, the epbf verification module reads the authorization policy corresponding to the request sender from the epbf map, and determines whether the virtual machine and container creation request conforms to the authorization policy. If it conforms to the authorization policy, the virtual machine and / or container creation request is executed to complete the creation of the virtual machine and / or container. If not, the virtual machine and / or container creation request is blocked. The epbf verification module runs in the system kernel.

[0019] Further, the method further includes: after the business application layer receives a virtual machine and / or container creation request sent by a requestor, obtaining the authorization policy for the corresponding virtual machine and / or container creation request according to the request sender, and forwarding the virtual machine and / or container creation request to the operating system layer, and the authorization policy is sent to the epbf map;

[0020] After receiving a virtual machine and / or container creation request, the operating system layer sends the virtual machine and / or container creation request to the system kernel.

[0021] Further, the method further includes: after the KVM module of the operating system receives a virtual machine creation request forwarded by the service application layer, the KVM module sends the virtual machine creation request to the system kernel; and / or after the KVM module receives a low-level virtual machine creation request sent by a request sender, the KVM module sends the virtual machine creation request to the system kernel.

[0022] Further, the method further includes: after the docker module / containerd module of the operating system receives a container creation request forwarded by the service application layer, the docker module / containerd module sends the container creation request to the system kernel; and / or after the docker module / containerd module of the operating system receives a low-level container creation request sent by a request sender, the docker module / containerd module sends the container creation request to the system kernel.

[0023] Further, the method further includes: the epbf verification module obtains the identification information of the running virtual machine and / or container, and determines whether the identification information is consistent with the corresponding authorization policy in the epbf map. If it is consistent, the virtual machine and / or the container continues to run. If it is not consistent, the epbf verification module sends a destruction signal to the operating system to terminate the running virtual machine and / or container process.

[0024] Further, the container creation request at least includes: image ID, tenant ID, CUP core number information, memory size information. If any one of the image ID, tenant ID, CUP core number information, and memory size information in the container creation request is inconsistent with the corresponding image ID, tenant ID, CUP core number information, and memory size information in the authorization policy in the epbf map, it is determined that the container creation request does not conform to the authorization policy;

[0025] The virtual machine creation request at least includes: virtual machine ID, CUP core number information, memory size information. If any one of the virtual machine ID, CUP core number information, and memory size information in the container creation request is inconsistent with the virtual machine ID, CUP core number information, and memory size information in the authorization policy in the epbf map, it is determined that the virtual machine creation request does not conform to the authorization policy.

[0026] The present invention also provides a kernel-level resource creation control system based on epbf, and the system includes: an operating system layer, an epbf map;

[0027] The operating system layer includes a system kernel, and the system kernel includes an epbf verification module;

[0028] When the system kernel receives a virtual machine and / or container creation request sent by a request sender, the epbf verification module reads the authorization policy corresponding to the request sender from the epbf map, and determines whether the virtual machine and / or container creation request conforms to the authorization policy. If it conforms to the authorization policy, the virtual machine and / or container creation request is executed to complete the creation of the virtual machine and / or container. If it does not conform, the virtual machine and / or container creation request is blocked.

[0029] Furthermore, the system further includes: a business application layer, which is used to receive a virtual machine and / or container creation request sent by a requester, obtain the corresponding authorization policy for creating the virtual machine and / or container according to the request sender, and forward the virtual machine and / or container creation request to the operating system layer, and the authorization policy is issued to the epbf map;

[0030] After the operating system layer receives a virtual machine and / or container creation request, it sends the virtual machine and / or container creation request to the system kernel.

[0031] Furthermore, the operating system layer further includes a KVM module, which is used to receive a virtual machine creation request forwarded by the business application layer and / or a low-level virtual machine creation request sent by the request sender, and send a virtual machine creation request to the system kernel according to the virtual machine creation request or the low-level virtual machine creation request.

[0032] Furthermore, the operating system further includes a docker module / containerd module, which is used to receive a container creation request forwarded by the business application layer and / or a low-level container creation request sent by the request sender, and send a container creation request to the system kernel according to the container creation request or the low-level container creation request.

[0033] After being standardized by the Docker or Containerd module, it is triggered by the following system calls:

[0034] clone(): Create a process for the container.

[0035] unshare(): Isolate the namespace for the container.

[0036] Therefore, the eBPF program is attached to these system calls to intercept and extract request parameters (such as image ID, tenant ID, resource quota, etc.) in real time.

[0037] Furthermore, the eBPF verification module is also used to obtain the identification information of the running virtual machines and / or containers, and determine whether the identification information is consistent with the corresponding authorization policy in the epbf map. If they are consistent, the virtual machines and / or the containers are allowed to continue running. If they are not consistent, the epbf verification module sends a destruction signal to the operating system to terminate the processes of the running virtual machines and / or containers.

[0038] With the above technical solutions, the kernel-level resource creation control method and system based on eBPF of the present invention have the following advantages:

[0039] 1) Strong real-time performance: By intercepting the creation request in the kernel state through eBPF, the authorization verification and processing are both completed in milliseconds, avoiding scheduling delays;

[0040] 2) High security: The eBPF verification module runs in the kernel state to prevent resource creation behaviors in the user state from bypassing the scheduling system;

[0041] 3) Dynamic scalability: Supports real-time updating of authorization policies to adapt to multi-tenant and dynamic business scenarios.

[0042] 4) Abnormal resource management: Supports extracting identification information from running resources, detecting and destroying unauthorized abnormal resources to ensure that system resources are always under control. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 Shows the flow chart of the kernel-level resource creation control method based on eBPF;

[0044] Figure 2 Shows the main step flow chart of processing resource creation requests through the business application layer;

[0045] Figure 3 Shows the request processing method flow chart of the KVM module and the Docker / Containerd module;

[0046] Figure 4 Shows the main step flow chart of abnormal resource detection and destruction;

[0047] Figure 5 Shows the overall architecture of the kernel-level resource creation control system based on eBPF and the interaction relationship diagram between each module. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0048] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative work shall fall within the protection scope of the present invention.

[0049] In the description of the present invention, it should be noted that the terms "first", "second", and "third" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance. In addition, the technical features involved in different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0050] In cloud computing and virtualization environments, resource scheduling and management are the keys to ensuring system security and resource utilization efficiency. Currently, resource reconciliation and management are usually carried out at the business application layer, lacking supervision of the underlying creation requests that bypass the business application layer and are carried out at the operating system layer, reducing system security.

[0051] The present invention proposes a kernel-level resource creation method based on eBPF, which specifically includes the following steps:

[0052] When the system kernel receives a creation request for a virtual machine and / or container, the eBPF verification module in the kernel reads the authorization policy corresponding to the creation request from the eBPF Map.

[0053] The eBPF verification module determines whether the creation request conforms to the authorization policy:

[0054] If it conforms, the request is allowed to continue execution to complete the creation of the virtual machine and / or container.

[0055] If it does not conform, the execution of the creation request is blocked.

[0056] After the business application layer receives the creation request for a virtual machine and / or container from the request sender, it generates an authorization policy and distributes it to the eBPF Map, and at the same time forwards the creation request to the operating system layer.

[0057] After the operating system layer receives the request, it sends the request to the system kernel.

[0058] In addition, for virtual machine request processing: The KVM module is responsible for processing the virtual machine creation request forwarded from the business application layer, or directly receiving the underlying virtual machine creation request and sending it to the system kernel.

[0059] For container request processing: The Docker or Containerd module is responsible for processing the container creation request from the business application layer, or directly receiving the underlying container creation request and sending it to the system kernel.

[0060] After the Docker or Containerd module is standardized, it is triggered by the following system calls:

[0061] clone(): Creates the process of the container.

[0062] unshare(): Isolates the namespace for the container.

[0063] Therefore, the eBPF program is attached to these system calls to intercept and extract request parameters (such as image ID, tenant ID, resource quota, etc.) in real time.

[0064] Resource management during operation: The eBPF verification module extracts identification information from the running virtual machines and / or containers. If it is consistent with the authorization policy, it continues to run; if not, it sends a destruction signal to terminate the operation of the abnormal resources.

[0065] In addition, the present invention also provides a kernel-level resource creation control system based on epbf. The system includes: a business application layer; an operating system layer; and a system kernel, including an eBPF verification module and an eBPF Map.

[0066] Among them, the business application layer is used to receive the virtual machine and / or container creation request from the request sender, generate an authorization policy according to the request, send the authorization policy to the eBPF Map, and forward the creation request to the operating system layer at the same time.

[0067] The operating system layer includes a KVM module and a Docker module / Containerd module, and is used to receive the creation request and send the request to the system kernel.

[0068] The eBPF verification module in the system kernel is used to intercept the virtual machine and / or container creation request, read the authorization policy from the eBPF Map, and determine whether the request conforms to the authorization policy. If it conforms, the request is executed; if not, the request is blocked.

[0069] The system further includes: The KVM module is used to receive the virtual machine creation request forwarded by the business application layer or receive the directly sent virtual machine creation request, and forward the request to the system kernel.

[0070] The operating system layer further includes: The Docker module or the Containerd module is used to receive the container creation request forwarded by the business application layer or receive the directly sent container creation request, and forward the request to the system kernel.

[0071] The eBPF verification module is further configured to obtain the identification information of the running virtual machine and / or container, determine whether the identification information is consistent with the authorization policy in the eBPF Map. If they are consistent, the virtual machine and / or container is allowed to continue running. If they are inconsistent, a destruction signal is sent to the operating system to terminate the running virtual machine and / or container process.

[0072] For the kernel-level resource creation control method based on eBPF (Extended Berkeley Packet Filter) provided by the present invention, when the system kernel of the operating system receives a creation request for a virtual machine and / or container, the epbf verification module in the system kernel reads the authorization policy corresponding to the creation request from the epbf map, and determines whether the virtual machine and container creation request conforms to the authorization policy. If it conforms to the authorization policy, the virtual machine and / or container creation request is executed to complete the creation of the virtual machine and / or container. If it does not conform, the virtual machine and / or container creation request is blocked. Since all creation requests pass through the system kernel and the epbf verification module is located in the system kernel, when the creation request passes through the system kernel, it will trigger the epfb verification module to determine whether the creation request conforms to the authorization policy. Therefore, the problem that creation requests in the prior art are easily bypassed can be avoided.

[0073] The control method and system of the present invention can effectively avoid the problem that resource creation bypasses the scheduling system, and at the same time provide refined authorization verification and abnormal resource management capabilities, and are applicable to multi-tenant and high-security requirement scenarios in the cloud computing environment.

[0074] The present invention proposes a real-time strong control method and system for kernel-level resource creation based on eBPF (Extended Berkeley Packet Filter), aiming to solve the limitations such as bypass problems, insufficient real-time performance, and coarse granularity existing in the existing resource scheduling and management technologies. By deploying an eBPF policy engine in the Linux kernel, the present invention performs real-time interception and verification on the creation requests of containers and virtual machines, and realizes dynamic blocking and automatic destruction of unauthorized resources.

[0075] Example 1

[0076] This embodiment provides a kernel-level resource creation control method based on epbf, referring to Figure 1 , Figure 1 is a schematic flowchart of the first embodiment of the resource creation control method based on the epbf kernel level of the present application.

[0077] S10: Receive a creation request

[0078] The system kernel receives a creation request for a virtual machine and / or container.

[0079] Container creation request: Triggered by system calls such as clone() and unshare(), or by inserting eBPF Hooks at namespace and cgroup operation points.

[0080] Virtual machine creation request: Triggered by fork() and exec() system calls.

[0081] Example:

[0082] Container creation request: After being standardized by the Docker or Containerd module, it is triggered by the following system calls:

[0083] clone(): Creates the process of the container.

[0084] unshare(): Isolates the namespace for the container.

[0085] Therefore, the eBPF program is attached to these system calls to intercept and extract request parameters (such as image ID, tenant ID, resource quota, etc.) in real time.

[0086] Virtual machine creation request: The user submits a virtual machine startup request through a virtualization management tool (such as QEMU), and the following system calls are triggered during runtime:

[0087] fork(): Used to create a new child process;

[0088] exec(): Used to load the virtual machine startup program.

[0089] The eBPF Hook is attached to these system calls to intercept the virtual machine creation request.

[0090] S20: Extract identification and resource configuration

[0091] The eBPF program temporarily intercepts the virtual machine and / or container creation request, and extracts the creation identification information and resources

[0092] from the intercepted system calls or operation points. Implementation details:

[0093] Container creation identification and configuration: Extract the following information from the parameters of the clone() and unshare() system calls:

[0094] Image ID: Used to identify the base image used by the container;

[0095] Tenant ID: Used to identify the tenant of the creation request;

[0096] Resource quota: Includes information such as the number of CPU cores and memory size.

[0097] For example, the intercepted request parameters may be:

[0098] {

[0099] "Image ID":"abc123",

[0100] "Tenant ID":"tenant1",

[0101] "Resource quota":{

[0102] "CPU":"2",

[0103] "Memory":"4Gi"

[0104] }

[0105] }

[0106] / .Virtual machine creation identification and configuration:

[0107] The following information is extracted from the startup parameters of the fork() and exec() system calls:

[0108] Virtual machine ID: used to identify the virtual machine instance;

[0109] Resource quota: includes information such as the number of CPU cores and memory size.

[0110] For example, the intercepted request parameters may be:

[0111] {

[0112] "Virtual Machine ID":"vm001",

[0113] "Resource quota":{

[0114] "CPU":"4",

[0115] "Memory": "8Gi"

[0116] }

[0117] }

[0118] S30: Read the authorization policy

[0119] The eBPF program looks up the authorization policy corresponding to the extracted creation identification information from the eBPF Map. Authorization policy structure:

[0120] The authorization policy is generated by the business application layer and sent to the eBPF Map. Its structure includes the following fields:Container creation policy:

[0121] {

[0122] "Image ID": "abc123",

[0123] "Tenant ID": "tenant1",

[0124] "Resource Quota": {

[0125] "CPU": "2",

[0126] "Memory": "4Gi"

[0127] }

[0128] }

[0129] Virtual Machine Creation Policy:

[0130] {

[0131] "Virtual Machine ID": "vm001",

[0132] "Resource Quota": {

[0133] "CPU": "4",

[0134] "Memory": "8Gi"

[0135] }

[0136] }

[0137] S40: Verify Authorization Policy

[0138] The eBPF program determines whether the identification information and resource configuration of the creation request conform to the authorization policy:

[0139] Condition for passing verification: The creation identification information is exactly the same as the corresponding fields in the authorization policy.

[0140] Condition for failing verification: The creation identification information does not match any of the fields in the authorization policy.

[0141] Specific verification logic:

[0142] For container creation requests:

[0143] Verify whether the image ID, tenant ID, and resource quota (CPU, Memory) in the request are consistent with the authorization policy in the eBPF Map.

[0144] If they are consistent, allow the creation to be executed; if not, prevent the execution.

[0145] For virtual machine creation requests:

[0146] Verify whether the virtual machine ID and resource quota (CPU, Memory) in the request are consistent with the authorization policy in the eBPF Map.

[0147] If they are consistent, creation is allowed; if not, execution is blocked.

[0148] S50 - S60: Execute or block creation

[0149] S50: If the verification passes, execute the virtual machine and / or container creation request to complete resource creation.

[0150] S60: If the verification fails, block the virtual machine and / or container creation request, return an error code, and prompt the user that the creation request is not authorized.

[0151] Execution process: When the verification passes, the eBPF program releases the intercepted system call or operation point to continue execution to complete resource creation.

[0152] Blocking process: When the verification fails, the eBPF program terminates the system call or operation point, returns an error code (such as 403 Forbidden), and prompts the user that they have no permission

[0153] Create resources.

[0154] In summary, in this embodiment, through the eBPF program running in the system kernel, real - time interception of virtual machine and container creation requests, extraction of identification information, verification of authorization policies, and release or block of creation operations are achieved. The entire process is real - time and efficient, ensuring that all creation requests comply with the authorization policy, effectively solving the security hidden danger that resource creation requests in the prior art are prone to bypassing the scheduling system.

[0155] Example 2 : Request processing through the business application layer

[0156] On the basis of Embodiment 1, this embodiment further describes the process of processing virtual machine and container creation requests through the business application layer. The addition of the business application layer makes the management of resource creation requests more flexible and secure. By dynamically generating authorization policies and interacting with the system kernel, it is ensured that resource creation requests meet the authorization requirements of the system.

[0157] Refer to Figure 2 , this embodiment includes the following steps:

[0158] S201: Receive the creation request and generate an authorization policy

[0159] Step description: After the business application layer receives the virtual machine and / or container creation request sent by the request sender (user), it parses the request content and generates the corresponding authorization policy.

[0160] Implementation details: Reception and parsing of container creation requests:

[0161] Users submit container creation requests through Docker, Kubernetes, or other management platforms.

[0162] Container creation requests usually contain the following:

[0163] Image ID: Used to specify the base image of the container, such as nginx:latest.

[0164] Tenant ID: Used to identify the tenant to which the request sender belongs, such as tenant1.

[0165] Resource requirements: Include parameters such as the number of CPU cores and memory size, for example:

[0166] {

[0167] "CPU":"2",

[0168] "Memory":"4Gi"

[0169] }

[0170] Receiving and parsing virtual machine creation requests: Users submit virtual machine creation requests through virtualization management tools (such as OpenStack, QEMU).

[0171] Virtual machine creation requests usually contain the following:

[0172] Virtual machine ID: Used to identify the virtual machine instance, such as vm001.

[0173] Resource requirements: Include parameters such as the number of CPU cores and memory size, for example:

[0174] {

[0175] "CPU":"4",

[0176] "Memory":"8Gi"

[0177] }

[0178] Generate authorization policies:

[0179] Based on the user request content, generate an authorization policy corresponding to the request. The authorization policy is stored in the eBPF Map, and the structure example is as follows:

[0180] Container authorization policy:

[0181] {

[0182] "Image ID":"nginx:latest",

[0183] "Tenant ID":"tenant1",

[0184] "Resource Quota": {

[0185] "CPU": "2",

[0186] "Memory": "4Gi"

[0187] }

[0188] }

[0189] Virtual Machine Authorization Policy:

[0190] {

[0191] "Virtual Machine ID": "vm001",

[0192] "Resource Quota": {

[0193] "CPU": "4",

[0194] "Memory": "8Gi"

[0195] }

[0196] }

[0197] S202: Forward the creation request

[0198] Step description: The business application layer forwards the parsed creation request to the operating system layer and simultaneously distributes the generated authorization policy to the eBPF Map.

[0199] Implementation details: Forwarding of the creation request:

[0200] Package the parameters (image ID, tenant ID, resource quota, etc.) in the original creation request and send them to the operating system layer.

[0201] Example: For a container request: {

[0202] "Request Type": "container",

[0203] "Image ID": "nginx:latest",

[0204] "Tenant ID": "tenant1",

[0205] "Resource Quota": {

[0206] "CPU": "2",

[0207] "Memory": "4Gi"

[0208] }

[0209] }

[0210] For a virtual machine request:

[0211] {

[0212] "Request Type": "Virtual Machine",

[0213] "Virtual Machine ID": "vm001",

[0214] "Resource Quota": {

[0215] "CPU": "4",

[0216] "Memory": "8Gi"

[0217] }

[0218] }

[0219] Distribution of Authorization Policy: The authorization policy is distributed to the eBPF Map through the API interface of the business application layer for subsequent verification.

[0220] S203: Operating System Layer Processing

[0221] Step Description: The operating system layer receives the virtual machine and / or container creation request forwarded by the business application layer and sends it to the system kernel.

[0222] Implementation Details: Receiving the Creation Request:

[0223] Modules in the operating system layer (such as the KVM module, Docker module, or Containerd module) receive the request forwarded by the business application layer.

[0224] Forwarding the Request: Forward the received creation request to the system kernel, triggering corresponding system calls (such as clone(), fork(), etc.).

[0225] The content of the forwarded request is the same as the original request content, ensuring the integrity of the request parameters.

[0226] Difference from Embodiment 1: In Embodiment 1, the creation request can be directly initiated from the underlying tool without the participation of the business application layer.

[0227] In this embodiment, the business application layer generates and manages the authorization policy before forwarding the request, adding an additional security control link to the creation request.

[0228] Summary of Embodiment 2 Through the participation of the business application layer, this embodiment adds a preprocessing function for resource creation requests on the basis of Embodiment 1. The business application layer can not only parse user requests and generate authorization policies, but also centrally manage and forward creation requests, further enhancing the security and flexibility of resource control.

[0229] Relationship and common points between Example 2 and Example 1: The final processing steps of both examples (such as identification extraction, authorization policy verification, request execution, or blocking) are completed by the eBPF program in the system kernel.

[0230] The eBPF verification logic is consistent.

[0231] Differences: Example 1 directly receives requests from the operating system layer and is applicable to direct operation scenarios of underlying tools. Example 2 receives requests through the business application layer and generates authorization policies, which is applicable to cloud management platforms or multi-tenant environments.

[0232] Advantages of this example: Enhanced security: By generating and managing authorization policies through the business application layer, it ensures that each request undergoes unified security checks. Improved flexibility: Supports dynamic generation of authorization policies in multi-tenant environments to meet complex business requirements. Facilitated management: The business application layer provides a unified request management interface, facilitating monitoring and statistics of resource creation requests.

[0233] Example 3: Request processing of the KVM module and the Docker module

[0234] Based on Examples 1 - 2, this example details the processing logic of the KVM module and Docker module / Containerd module in the operating system layer for virtual machine and container creation requests. Through the modular design of the operating system layer, the present invention achieves precise interception and flexible forwarding of virtual machine and container creation requests, ensuring that all requests are uniformly verified by the eBPF verification module in the system kernel.

[0235] Refer to Figure 3 , this example includes the following steps:

[0236] S301: The KVM module processes the virtual machine creation request

[0237] Step description: The KVM module is used to receive the virtual machine creation request forwarded by the business application layer or directly receive the underlying virtual machine creation request sent by the request sender (user), and forward the request to the system kernel.

[0238] Implementation details: Receiving the virtual machine creation request forwarded by the business application layer:

[0239] Scenario: When the business application layer receives a virtual machine creation request, it encapsulates it into a standardized format and forwards it to the KVM module in the operating system layer.

[0240] Processing logic: Parse the request content forwarded by the business application layer, including the virtual machine ID and resource configuration (such as the number of CPU cores and memory size). Verify the integrity of the request format to ensure that request parameters are not missing.

[0241] Encapsulate the request into a system call format (such as fork() and exec()) and send it to the system kernel.

[0242] Example: {

[0243] "Request type": "virtual machine",

[0244] "Virtual machine ID": "vm001",

[0245] "Resource quota": {

[0246] "CPU": "4",

[0247] "Memory": "8Gi"

[0248] }

[0249] }

[0250] Receive a virtual machine creation request directly sent by the underlying layer:

[0251] Scenario: The user directly initiates a virtual machine creation request through the underlying tool (such as QEMU or libvirt), without the participation of the business application layer.

[0252] Processing logic: Extract the virtual machine ID and resource configuration from the startup parameters of the creation request.

[0253] Generate a standardized request format according to the request type and forward it to the system kernel.

[0254] Example: QEMU startup command:

[0255] qemu-system-x86_64 -name guest=vm001 -m 8G -smp 4...

[0256] Request generated after parsing by the KVM module:

[0257] {

[0258] "Request type": "virtual machine",

[0259] "Virtual machine ID": "vm001",

[0260] "Resource quota": {

[0261] "CPU": "4",

[0262] "Memory": "8Gi"

[0263] }

[0264] }

[0265] Forwarding logic: Regardless of whether the request comes from the business application layer or the underlying tool, the KVM module ultimately sends the standardized request to the system kernel, triggering the fork() and exec() system calls.

[0266] S302: The Docker / Containerd module processes the container creation request; Step description: The Docker / Containerd module is used to receive the container creation request forwarded by the business application layer, or directly receive the underlying container creation request sent by the request sender (user), and forward the request to the system kernel.

[0267] Implementation details: Receive container creation requests forwarded by the business application layer:

[0268] Scenario: When the business application layer receives a container creation request, it encapsulates it into a standardized format and forwards it to the Docker / Containerd module at the operating system layer.

[0269] Processing logic: Parse the request content forwarded by the business application layer, including image ID, tenant ID, and resource configuration (such as the number of CPU cores and memory size). Verify the integrity of the request format and ensure that the request parameters are not missing. Encapsulate the request into a system call format (such as clone() and unshare()) and send it to the system kernel.

[0270] Example:

[0271] {

[0272] "Request Type":"Container",

[0273] "Image ID":"nginx:latest",

[0274] "Tenant ID":"tenant1",

[0275] "Resource quota":{

[0276] "CPU":"2",

[0277] "Memory":"4Gi"

[0278] }

[0279] }

[0280] Receive container creation requests sent directly from the underlying layer:

[0281] Scenario: Users directly initiate container creation requests through underlying tools (such as Docker CLI or Containerd) without the involvement of the business application layer.

[0282] Processing logic: Extract the image ID, tenant ID, and resource configuration from the startup parameters of the creation request.

[0283] Based on the request type, generate a standardized request format and forward it to the system kernel.

[0284] Example: Docker CLI startup command: docker run --name nginx-container -m 4G --cpus=2 nginx:latest

[0285] Request generated after Docker module parsing:

[0286] {

[0287] "Request type": "Container",

[0288] "Image ID": "nginx:latest",

[0289] "Tenant ID": "tenant1",

[0290] "Resource quota": {

[0291] "CPU": "2",

[0292] "Memory": "4Gi"

[0293] }

[0294] }

[0295] Forwarding logic: Regardless of whether the request comes from the business application layer or the underlying tool, the Docker / Containerd module finally sends the standardized request to the system kernel, triggering the clone() and unshare() system calls.

[0296] S303: Logical differences between modules; differences between forwarding from the business application layer and direct requests from the underlying layer:

[0297] Forwarding from the business application layer: The authorization policy is already included, and only the standardized parameters need to be passed to the operating system layer when forwarding the request.

[0298] Direct request from the underlying layer: The authorization policy is not included, and the request parameters need to be parsed by the module and dynamically verified by the eBPF program from the eBPFMap.

[0299] Differences between container and virtual machine requests:

[0300] Container requests are processed by the Docker / Containerd module, involving the clone() and unshare() system calls. Virtual machine requests are processed by the KVM module, involving the fork() and exec() system calls.

[0301] Summary: This embodiment details the processing logic of the KVM module and the Docker / Containerd module in the operating system layer. Through the standardized encapsulation and forwarding of virtual machine and container creation requests, combined with the eBPF verification module in the system kernel, the present invention realizes the comprehensive control of resource creation requests, ensures the legality and security of requests, and at the same time provides a highly flexible modular architecture.

[0302] Advantages of this embodiment:

[0303] 1) Modular design: The KVM module and the Docker / Containerd module independently process virtual machine and container requests, enhancing the flexibility and scalability of the system. Multi-source compatibility: It supports both requests forwarded by the business application layer and requests directly sent by underlying tools, meeting the requirements of various usage scenarios.

[0304] 2) Enhanced security: All requests need to be uniformly authorized and verified by the eBPF verification module in the system kernel, preventing unauthorized resource creation.

[0305] Example 4: Abnormal resource detection and destruction

[0306] Based on Embodiments 1-3, this embodiment further describes how to detect and destroy abnormal resources during operation through the eBPF verification module. The abnormal resource detection and destruction function of the present invention can effectively identify unauthorized or illegal container and virtual machine resources and clean them up in a timely manner to ensure the security and controllability of system resources.

[0307] Refer to Figure 4 , this embodiment includes the following steps:

[0308] S401: Obtain the identification information of resources during operation. The eBPF verification module dynamically obtains the identification information of currently running containers or virtual machines through the process table or cgroup information in the kernel.

[0309] Implementation details: Obtaining container identification information:

[0310] The eBPF program is attached to system calls related to cgroups (such as cgroup.procs) or uses

[0311] The bpf_get_current_cgroup_id() kernel API obtains the cgroup ID of the container.

[0312] Based on the cgroup ID, extract the associated information from the kernel's task_struct:

[0313] Image ID: Resolved through the startup parameters of the container runtime;

[0314] Tenant ID: Obtained through environment variables or container configuration files;

[0315] Resource quota: Obtain the allocated CPU and memory through cgroup configuration.

[0316] Example:

[0317] Container information obtained through croup.procs:

[0318] {

[0319] "Container ID": "container_123",

[0320] "Image ID": "nginx:latest",

[0321] "Tenant ID": "tenant1",

[0322] "Resource quota": {

[0323] "CPU": "2",

[0324] "Memory": "4Gi"}

[0325] }

[0326] Obtaining virtual machine identification information:

[0327] The eBPF program is attached to the fork() and exec() system calls to extract identification information from the startup parameters of the virtual machine startup process:

[0328] Virtual machine ID: Resolved through the startup parameters of virtual machine management tools (such as QEMU);

[0329] Resource quota: Obtained through the configuration file of the virtual machine instance.

[0330] Example:

[0331] Virtual machine information extracted from the startup command:

[0332] {

[0333] "Virtual machine ID": "vm001",

[0334] "Resource Quota": {

[0335] "CPU": "4",

[0336] "Memory": "8Gi"

[0337] }

[0338] }

[0339] S402: Verify Identification Information and Authorization Policy

[0340] The eBPF verification module matches the obtained identification information with the authorization policy stored in the eBPF Map to determine whether the resources conform to the authorization policy.

[0341] Implementation Details:

[0342] Container Verification Logic:

[0343] Read the authorization policy from the eBPF Map according to the container ID or image ID.

[0344] Verify whether the tenant ID and resource quota (CPU, memory) in the request match the authorization policy.

[0345] Example:

[0346] Current Running Container Identification:

[0347] {

[0348] "Container ID": "container_123",

[0349] "Image ID": "nginx:latest",

[0350] "Tenant ID": "tenant1",

[0351] "Resource Quota": {

[0352] "CPU": "2",

[0353] "Memory": "4Gi"

[0354] }

[0355] }

[0356] Authorization Policy in eBPF Map: {

[0357] "Image ID": "nginx:latest",

[0358] "Tenant ID": "tenant1",

[0359] "Resource Quota": {

[0360] "CPU": "2",

[0361] "Memory": "4Gi"

[0362] }}

[0363] }}

[0364] Verification result: Consistent, the container continues to run.

[0365] Virtual machine verification logic:

[0366] Read the authorization policy from the eBPF Map according to the virtual machine ID.

[0367] Verify whether the resource quota in the virtual machine request matches the authorization policy.

[0368] Example:

[0369] Current running virtual machine identifier:

[0370] {

[0371] "Virtual Machine ID": "vm001",

[0372] "Resource Quota": {

[0373] "CPU": "4",

[0374] "Memory": "8Gi"

[0375] }}

[0376] }}

[0377] Authorization policy in eBPF Map:

[0378] {

[0379] "Virtual Machine ID": "vm001",

[0380] "Resource Quota": {

[0381] "CPU": "4",

[0382] "Memory": "8Gi"

[0383] }}

[0384] }}

[0385] Verification result: Consistent, the virtual machine continues to run.

[0386] S403: Detect abnormal resources

[0387] If the identification information of a running container or virtual machine does not match the authorization policy, it is determined to be an abnormal resource.

[0388] Implementation details: Detection of abnormal containers:

[0389] If the image ID or tenant ID of the container is inconsistent with the authorization policy, or the allocated resources exceed the authorized quota, it is marked as an abnormal resource.

[0390] Detection of abnormal virtual machines:

[0391] If the ID or resource quota of the virtual machine is inconsistent with the authorization policy, it is marked as an abnormal resource.

[0392] S404: Destroy abnormal resources

[0393] The eBPF checksum module destroys abnormal resources by sending a signal (such as SIGKILL) to the operating system.

[0394] Implementation details:

[0395] Container destruction:

[0396] The eBPF program obtains the main process ID of the container through the cgroup ID.

[0397] Use the bpf_send_signal() API to send a SIGKILL signal to the main process to terminate the operation of the abnormal container.

[0398] Example: kill-SIGKILL<container_pid>

[0399] Virtual machine destruction: The eBPF program sends a SIGKILL signal through the PID of the virtual machine process (extracted through the fork() or exec() system call) to terminate the operation of the abnormal virtual machine.

[0400] Example: kill-SIGKILL<vm_pid>

[0401] In summary, this embodiment uses the eBPF verification module to dynamically detect and destroy running resources, effectively ensuring the security and consistency of system resources. This function can identify and clean up unauthorized or illegal container and virtual machine resources, avoiding the risk of illegal occupation of system resources, and improving the overall management capabilities of the system.

[0402] Advantages of this embodiment:

[0403] 1) Strong real-time performance: The eBPF verification module implements dynamic detection of running resources through the Hook mounted in the kernel, and abnormal resources can be discovered and destroyed in real time.

[0404] 2) High security: Unauthorized containers or virtual machines are forcibly destroyed to prevent resource abuse and potential security risks. Fine-grained management: Through the eBPF Map, dynamic verification of resource authorization policies is achieved, supporting fine-grained control in a multi-tenant environment.

[0405] Example 5: Kernel-level resource creation control system based on eBPF

[0406] As Figure 5 shown, this embodiment provides a resource creation control system based on the eBPF kernel level. This system can effectively manage and control the creation requests of virtual machines and containers, ensuring that all resources comply with the authorization policy and are subject to real-time verification and control.

[0407] This system includes the following main modules:

[0408] 1. Business application layer:

[0409] Receive virtual machine and / or container creation requests; generate authorization policies corresponding to the requests; store the authorization policies in the eBPF Map; forward the creation requests to the operating system layer;

[0410] 2. Operating system layer:

[0411] It includes the following sub-modules: 2.1 KVM module: Receive virtual machine creation requests forwarded by the business application layer, or directly receive virtual machine creation requests issued by underlying tools (such as QEMU, libvirt); parse the requests and forward them to the system kernel; 2.2 Docker / Containerd module: Receive container creation requests forwarded by the business application layer, or directly receive container creation requests issued by underlying tools (such as Docker CLI); parse the requests and forward them to the system kernel.

[0412] 3. System kernel

[0413] It includes the following sub-modules: 3.1 eBPF verification module: Intercept virtual machine and / or container creation requests; read authorization policies from the eBPF Map; verify whether the identification information of the requests (such as virtual machine ID, container image ID, resource configuration, etc.) complies with the authorization policy; if the request complies with the authorization policy, allow the creation to be executed; if the request does not comply with the authorization policy, block the creation request and return an error message;

[0414] 3.2 eBPF Map: Store the authorization policies generated by the business application layer; provide the verification module for real-time comparison of creation requests and authorization policies.

[0415] 4. Abnormal resource handling module:

[0416] The eBPF verification module further supports detecting running virtual machines and / or containers: obtaining the identification information of running resources (e.g., obtained through cgroup or process table); determining whether the identification information is consistent with the authorization policy in the eBPF Map; if consistent, allowing the resources to continue running; if inconsistent, terminating the running of unauthorized resources by sending a SIGKILL signal.

[0417] System function flow:

[0418] 1. Request reception and authorization policy generation: The business application layer receives the virtual machine or container creation request submitted by the user, parses the request content (such as virtual machine ID, container image ID, tenant ID, resource configuration, etc.), generates the corresponding authorization policy and distributes it to the eBPF Map.

[0419] 2. Request forwarding and parsing: The business application layer forwards the request to the operating system layer. The KVM module or Docker / Containerd module in the operating system layer parses the request and sends it to the system kernel after standardizing it.

[0420] 3. Request interception and verification: The eBPF verification module is mounted on system calls (such as fork(), clone(), exec(), etc.) to intercept all virtual machine and container creation requests. The eBPF verification module reads the authorization policy from the eBPF Map and verifies whether the request conforms to the policy.

[0421] 4. Request execution or prevention: If the request conforms to the authorization policy, the eBPF verification module allows the request to continue execution to complete the creation of the virtual machine or container. If the request does not conform to the authorization policy, the eBPF verification module prevents the request and returns an error message.

[0422] 5. Abnormal resource detection and destruction: The eBPF verification module dynamically obtains the identification information of running virtual machines and containers through cgroup or process table. Verifying whether the running identification information conforms to the authorization policy: if it conforms, the resources continue to run; if not, the running of unauthorized resources is terminated by sending a SIGKILL signal to the operating system.

[0423] In summary, the resource creation control system based on the eBPF kernel level provided in this embodiment realizes the unified management and real-time verification of virtual machine and container creation requests through the collaborative design of the business application layer, the operating system layer, and the system kernel. The abnormal resource detection and destruction function of the system further improves the security and resource control ability, and is particularly suitable for multi-tenant and complex resource scheduling scenarios in the cloud computing environment.

[0424] The system advantages can be described as follows:

[0425] 1. Real-time performance: The eBPF verification module runs directly in the kernel mode, enabling real-time interception and verification of creation requests; the abnormal resource detection and destruction function responds in real time to the operation of unauthorized resources.

[0426] 2. Security: All creation requests must pass the authorization policy verification to prevent the creation or operation of unauthorized virtual machine or container resources; unauthorized resources can be promptly detected and destroyed during operation.

[0427] 3. Modular architecture: The system is divided into a business application layer, an operating system layer, and a system kernel, with separated responsibilities for easy maintenance and extension; the KVM module and the Docker / Containerd module independently process requests for virtual machines and containers, supporting unified management and control of multiple resource types.

[0428] 4. Flexibility and scalability: It supports requests from multiple sources, including requests forwarded by the business application layer and requests directly submitted by underlying tools. The authorization policy supports dynamic updates to adapt to multi-tenant and complex business scenarios.

[0429] The above are only the preferred embodiments of the present invention, and do not impose any form of limitation on the present invention. Therefore, any simple modifications, equivalent changes, and decorations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention still fall within the scope of the technical solution of the present invention.

Claims

1. A kernel-level resource creation and control method based on eBPF, characterized in that: The method comprises the following steps: When the system kernel receives a request to create a virtual machine and / or a container, the eBPF verification module reads the authorization policy corresponding to the creation request from the eBPF Map; Determining whether the request to create the virtual machine and / or container complies with the authorization policy; If the authorization policy is met, the execution of the virtual machine and / or container creation request is allowed, and the creation of the virtual machine and / or container is completed; If the authorization policy is not met, preventing the execution of the virtual machine and / or container creation request; The eBPF verification module runs in the system kernel and performs the verification operation of the above authorization policy in real time.

2. The kernel-level resource creation and control method based on eBPF according to claim 1, characterized in that: The real-time strong control method further includes the following steps: After receiving the virtual machine and / or container creation request from the request sender, the business application layer generates a corresponding authorization policy according to the identity of the request sender and the request content; Send the authorization policy to the eBPF Map, and forward the virtual machine and / or container creation request to the operating system layer; After receiving the virtual machine and / or container creation request, the operating system layer sends the request to the system kernel for subsequent processing.

3. The kernel-level resource creation and control method based on eBPF as claimed in claim 1, characterized in that: The real-time strong control method includes the following steps: When the KVM module of the operating system layer receives a virtual machine creation request forwarded from the business application layer, it sends a virtual machine creation request to the system kernel; Alternatively, when the KVM module receives a virtual machine creation request directly sent by the request sender, the KVM module sends the virtual machine creation request to the system kernel.

4. The method for creating and controlling kernel-level resources based on eBPF according to claim 1, characterized in that: The real-time strong control method also includes the following steps: When the Docker module or Containerd module at the operating system layer receives a container creation request forwarded from the business application layer, it sends a container creation request to the system kernel; Alternatively, when the Docker module or the Containerd module receives a container creation request directly sent by the request sender, the container creation request is sent to the system kernel.

5. The kernel-level resource creation and control method based on eBPF according to claim 1, characterized in that: The real-time strong control method also includes the following steps: The eBPF check module extracts identification information from the running virtual machines and / or containers; Determine whether the identification information is consistent with the authorization policy stored in the eBPF Map; If they are consistent, the virtual machine and / or container is allowed to continue running; If they are inconsistent, a destruction signal is sent to the operating system to terminate the running virtual machine and / or container process.

6. The kernel-level resource creation and control method based on eBPF as described in claims 1-5, characterized in that: The authorization policy The following fields are included: For container creation requests: image ID, tenant ID, CPU core count, and memory size; For virtual machine creation requests: virtual machine ID, CPU core number information, and memory size information; If any field of the creation request is inconsistent with the authorization policy in the eBPF Map, it is determined that the request does not comply with the authorization policy.

7. A kernel-level resource creation and control system based on eBPF, characterized in that: The system comprises: Business application layer; Operating system layer; System kernel, including eBPF verification module and eBPF Map; The business application layer is used to receive the virtual machine and / or container creation request from the request sender, generate an authorization policy based on the request, send the authorization policy to the eBPF Map, and forward the creation request to the operating system layer. The operating system layer includes the KVM module and the Docker module / Containerd module, which are used to receive the creation request and send the request to the system kernel; The eBPF verification module in the system kernel is used to intercept virtual machine and / or container creation requests, read the authorization policy from the eBPF Map, and determine whether the request complies with the authorization policy. If it complies, the request is executed; if it does not, the request is blocked.

8. The eBPF-based kernel-level resource creation and control system according to claim 6, characterized in that: The system further comprises: The KVM module is used to receive a virtual machine creation request forwarded by the business application layer, or receive a virtual machine creation request sent directly, and forward the request to the system kernel.

9. The eBPF-based kernel-level resource creation and control system according to claim 7, characterized in that: The operating system layer also includes: The Docker module or the Containerd module is used to receive container creation requests forwarded by the business application layer, or to receive container creation requests sent directly, and forward the requests to the system kernel.

10. The eBPF-based kernel-level resource creation and control system according to claim 7, characterized in that: The eBPF verification module is further used to obtain the identification information of the running virtual machine and / or container, and determine whether the identification information is consistent with the authorization policy in the eBPFMap. If it is consistent, it is allowed to continue running. If it is inconsistent, a destruction signal is sent to the operating system to terminate the running virtual machine and / or container process.

Images