A Kubernetes-based automated pre-admission management method and system

Abstract

This invention discloses an automated pre-approval management method and system based on Kubernetes. The method includes: intercepting all requests to the Kube-Apiserver; pre-approving the requests and parsing the information messages of the requests; obtaining fields that need to be audited based on the information messages; using static and dynamic admission mechanisms to check the fields that need to be audited to manage whether the request is approved or needs to be modified; summarizing and storing the information of the requests based on the check results; and sending the approved requests to the Kube-Apiserver to execute the subsequent corresponding resource creation process. This invention can effectively reduce the performance anxiety of the Kube-Apiserver; at the same time, by using static and dynamic admission mechanisms to check all requests during the request management process, it can intercept or warn against requests that do not conform to the admission rules, thereby achieving the interception of illegal and erroneous requests and timely warning of suspicious requests, preventing adverse effects caused by human error.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and in particular to an automated pre-access management method and system based on Kubernetes. Background Technology

[0002] With the popularization of the cloud-native concept and the rapid development of cloud computing technology, container technology has been rapidly accepted by major enterprises due to its technical characteristics such as agile and efficient deployment, secure resource isolation, and unified versions across multiple environments. More and more companies are beginning to migrate their businesses from traditional host environments to container environments.

[0003] Given the lightweight nature of containers, and the fact that they are used to host business applications, the number of containers is typically quite large, thus requiring an efficient and convenient distributed cluster management solution. Among numerous solutions, Kubernetes, with its advanced design philosophy, robust scalability, and high orchestration efficiency, has become the preferred solution for many enterprises to manage container clouds.

[0004] However, in real-world business data processing, erroneous Kubernetes requests can have unpredictable and severe impacts on the cluster or business operations. For example, incorrectly modifying the number of Pods (the basic unit of service provision in Kubernetes, serving as Pod objects within a container group), accidentally deleting core components providing business services, or maliciously attacking cluster components with known access methods, including CSI (Channel State Information), CNI (Container Network Interface), CRI (Container Runtime Interface), CoreDNS (DNS server / forwarder), and IngressController (admission manager). Currently, a common solution is to use the Kube-Apiserver component with auditing enabled to log all request information to a local log file. However, simply recording information only allows for request tracking and tracing; it cannot intercept illegal or erroneous requests or provide timely warnings for suspicious requests.

[0005] Therefore, the existing technology still needs further development. Summary of the Invention

[0006] To address the aforementioned technical issues, this invention provides an automated pre-admission management method and system based on Kubernetes, which can intercept and warn of erroneous requests.

[0007] A first aspect of the present invention provides an automated pre-admission management method based on Kubernetes, comprising:

[0008] Intercept all requests to Kube-Apiserver (the component that provides the API Server within the Kubernetes solution, which is the entry point for all request calls), prepend the requests, and parse the information messages of the requests;

[0009] Based on the information message, the fields that need to be audited are obtained, and the fields that need to be audited are checked using static and dynamic admission mechanisms to manage whether the request is approved or needs to be modified.

[0010] The information of the request is summarized and stored based on the inspection results, and the access request is sent to the Kube-Apiserver to execute the subsequent corresponding resource creation process.

[0011] In some implementations, the step of pre-processing the request and parsing the request message includes:

[0012] All requests to the Kube-Apiserver are forwarded to the admission front server, which parses the information packets of the requests. The admission front server exists outside the Kubernetes cluster.

[0013] In some implementations, the use of static and dynamic admission mechanisms to check the fields requiring auditing in order to manage whether a request is granted access or needs modification includes:

[0014] The static admission mechanism is used to check the image download address, service exposure port number, and request address in the request. Requests with image download addresses, service exposure port numbers, and request addresses that conform to the static admission mechanism are determined as admission requests. Requests with image download addresses, service exposure port numbers, and request addresses that do not conform to the static admission mechanism are intercepted or a notification that modification is required is issued.

[0015] In some implementations, the step of using static and dynamic admission mechanisms to check the fields requiring auditing in order to manage whether the request is approved or needs to be modified further includes:

[0016] The dynamic admission mechanism checks the limits on the number of single container resources, resource replicas, and elastic scaling of resources in the request. Requests whose resource quantity does not exceed the limits on the number of single container resources, resource replicas, and elastic scaling of resources in the Kubernetes system are determined to be admission requests. Requests whose resource quantity does not exceed the limits on the number of single container resources, resource replicas, and elastic scaling of resources in the Kubernetes system are intercepted or a notification requiring modification is issued.

[0017] In some implementations, the static admission mechanism is manually configured by the user, while the dynamic admission mechanism dynamically checks the resource request status of the request based on the monitoring data of the current Kubernetes cluster, and issues warnings or modifications to the quantity and size of the resource request based on the resource status of the current Kubernetes cluster.

[0018] A second aspect of the present invention provides an automated pre-access management system based on Kubernetes, comprising:

[0019] The admission front-end is configured to acquire all intercepted requests to the Kube-Apiserver, parse the information packets of the requests, and send them to the rules server.

[0020] The rules server is configured to obtain the fields to be audited based on the information message, use static and dynamic admission mechanisms to check the fields to be audited in order to manage whether the request is admitted or needs to be modified; and send the admitted request to the Kube-Apiserver to execute the subsequent corresponding resource creation process, summarize the information of the request according to the check results, and send the summarized information of the request to the audit report system for storage.

[0021] In some implementations, the rule server includes a static rule module, which is configured to: use a static admission mechanism to check the image download address, service exposure port number, and request address in the request; determine the requests corresponding to the image download address, service exposure port number, and request address that conform to the static admission mechanism as admission requests; and intercept or issue a notification that the requests corresponding to the image download address, service exposure port number, and request address that do not conform to the static admission mechanism.

[0022] In some implementations, the rule server includes a dynamic rule module configured to: use a dynamic admission mechanism to check the single container resource usage limit, resource replica limit, and resource elastic scaling limit in the request; determine the request whose requested resource quantity does not exceed the single container resource usage limit, resource replica limit, and resource elastic scaling limit in the Kubernetes system as an admission request; and intercept or issue a notification that modification is required for the request whose requested resource quantity does not exceed the single container resource usage limit, resource replica limit, and resource elastic scaling limit in the Kubernetes system.

[0023] In some implementations, the static admission mechanism is manually configured by the user, while the dynamic admission mechanism dynamically checks the resource request status of the request based on the monitoring data of the current Kubernetes cluster, and issues warnings or modifications to the quantity and size of the resource request based on the resource status of the current Kubernetes cluster.

[0024] A third aspect of the present invention provides an electronic device comprising:

[0025] At least one processor; and at least one memory communicatively connected to the processor, wherein the memory stores program instructions executable by the processor, and the processor invokes the program instructions to perform the method as described in the first aspect of the present invention.

[0026] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a computer, performs the method described in the first aspect of the embodiments of the present invention.

[0027] This invention intercepts all requests to the Kube-Apiserver and forwards these requests, effectively reducing the performance anxiety of the Kube-Apiserver. Simultaneously, during the request management process, static and dynamic admission mechanisms are used to check all requests, intercepting or issuing warnings for requests that do not conform to the admission rules. This achieves the interception of illegal and erroneous requests and timely warnings for suspicious requests, preventing adverse effects caused by human error. Attached Figure Description

[0028] Figure 1 This is a schematic diagram illustrating the operation of an automated pre-access management system based on Kubernetes in an embodiment of the present invention.

[0029] Figure 2 This is a flowchart illustrating an automated pre-admission management method based on Kubernetes in an embodiment of the present invention. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Kubernetes audit logs are structured logs generated by the Kube-Apiserver, with configurable policies, recording all access events to the Kube-Apiserver. Audit logs provide an additional dimension for cluster observation besides Metrics (a Java library that provides code execution insights). By viewing and analyzing audit logs, you can trace changes to the cluster state, understand the cluster's operational status, troubleshoot anomalies, and discover potential performance risks. Audit logs consist of three parts: metadata, request objects, and response objects. By default, audit logs do not record the contents of request or response objects; they primarily record metadata information. Metadata contains contextual information about the request, such as who initiated the request, where it originated, what resource was accessed, and what specific operations were performed. This information helps administrators gain a better understanding of the current state of the cluster.

[0032] Kubernetes' admission controller intercepts data after it has been created and authenticated, and before the data is written to etcd (a highly available key / value storage system), and then performs relevant checks on the resources. It can be said to be the last line of defense before the request affects the cluster. Therefore, admission and auditing can be said to be two important means to ensure the normal operation of Kubernetes.

[0033] However, existing technologies only have a logging function and cannot intercept illegal or erroneous requests or provide timely warnings for suspicious requests. This invention utilizes an independent access control front-end to handle all requests. While some access control mechanisms exist in existing technologies, these mechanisms are not used independently; they only combine with preset rules to schedule traffic and resources. This does not prevent human error and cannot alleviate the operational pressure on the Kube-Apiserver, actually increasing it to some extent.

[0034] Based on the above, such as Figure 1As shown, this invention provides an automated pre-approval management system based on Kubernetes, including: an admission front-end server and a rule server. The admission front-end server exists outside the Kubernetes cluster and is isolated from it. Since the admission service intercepts requests before the Kube-Apiserver, it can effectively reduce the performance anxiety of the Kube-Apiserver. Even if the admission front-end server malfunctions and affects downstream services, it can be bypassed through degradation or other methods, thus not affecting the cluster itself. The role of the rule server is to review all requests and provide different management responses for requests with different risk levels. Even if adverse effects are caused by human error, it can intercept illegal and erroneous requests and provide timely warnings for suspicious requests. In one embodiment:

[0035] The admission front-end is configured to acquire all intercepted requests to the Kube-Apiserver, parse the information packets of the requests, and send them to the rules server.

[0036] The rule server is configured to obtain the fields to be audited based on the information message, and use static and dynamic admission mechanisms to check the fields to be audited in order to manage whether the request is admitted or needs to be modified; and to send the admitted request to the Kube-Apiserver to execute the subsequent corresponding resource creation process (such as...). Figure 1 The system consists of two processes: the Controller and the Schedule, which control different pods and nodes respectively. Based on the inspection results, the system summarizes the information of the requests and sends the summarized information to the audit report system for storage.

[0037] It should be understood that the access control front-end includes a proxy server capable of loading Kubernetes TLS certificates. Positioned in the Kubernetes architecture, it intercepts all requests to the Kube-Apiserver and then parses the corresponding request information packets. The request packet is a standard structure containing elements such as request type (requestKind), requested resource configuration information (name / namespace / spec), and request source account information (userInfo). Specifically, the request information can be split, and the fields requiring auditing can be extracted; then, these auditable fields are sent to the rules server for auditing.

[0038] When sending the fields requiring auditing to the rule server, the request objects can be recombined based on the source IP obtained from the admission front-end. For request admission and blocking, requests with known IP addresses can be blocked in batches, directly rejecting access to the Kubernetes cluster by IP address. Therefore, in practice, request objects can be recombined based on the IP source of the requests, and requests with consistent request objects can be sent in batches to the rule server for auditing, effectively reducing auditing pressure.

[0039] The rule server employs two inspection mechanisms to check the requests: static admission and dynamic admission. These mechanisms correspond to static rules and dynamic rules, respectively. Both rule types support three management modes: request rejection, request modification, and warning request, each corresponding to requests with different risk levels.

[0040] The primary objective of this invention is to prevent adverse effects caused by human error; it utilizes the two aforementioned inspection rules to check and block the requests. As the background information indicates, these requests encompass various types, namely all requests to the Kube-Apiserver. Therefore, the static admission mechanism primarily serves as a rule for checking human behavior. It can be manually configured by users or administrators, and the specific configuration can vary widely, tailored to different project needs. For example, the static admission mechanism can be configured with rules that conform to the company's security baseline, such as directly denying access to the cluster from sensitive IP addresses, limiting the port range and image pull addresses after container deployment, etc.

[0041] The dynamic admission mechanism primarily checks resource requests based on multi-dimensional monitoring data of the current Kubernetes cluster. It issues warnings or modifies resource requests based on the actual situation of the Kubernetes cluster, such as the quantity and size of the requested resources. For example, it can check the upper and lower limits of resource usage for individual containers, the number of resource replicas, and the upper and lower limits of elastic resource scaling. Essentially, it checks whether the resource requests in the request are reasonable and whether the Kubernetes cluster can fulfill them. If not, it blocks or issues a warning; if they can be fulfilled, it processes the request as an admission request.

[0042] Static admission mechanisms effectively satisfy the checks for human operations that conform to the company's project baseline, intercepting some erroneous events caused by human operations using static rules; while dynamic admission mechanisms effectively satisfy the checks for the quantity of Kubernetes cluster resources other than human operations. Whether they can satisfy the checks depends on the Kubernetes cluster requesting the current resource data. That is, for some human operation events that cannot be intercepted by static rules, dynamic rules are used to intercept them based on the current situation.

[0043] The rule server is also used to apply the inspection results to subsequent audit follow-up and related process optimization, such as log recording for analysis after a failure. For example, the rule server summarizes the request information based on the inspection results and stores the summarized request information in the audit reporting system.

[0044] After the rule server processes the request, it copies the processed request object in memory. The rule server then sends the approved request to the Kube-Apiserver to execute the subsequent resource creation process. A copy is sent to the audit reporting system along with the original request object for subsequent operation auditing and traceability. Users can also periodically optimize the corresponding rules and processes based on the data in the audit reporting system.

[0045] In summary, this invention intercepts all requests to the Kube-Apiserver and forwards these requests, effectively reducing the performance anxiety of the Kube-Apiserver. Simultaneously, the use of static and dynamic admission mechanisms to check all requests during the request management process prevents adverse effects caused by human error. Requests that do not conform to the admission rules are intercepted or warned, enabling the interception of illegal and erroneous requests as well as timely warnings of suspicious requests.

[0046] Furthermore, the rule server includes a static rule module and a dynamic rule module. The static rule module executes the static admission mechanism, and the dynamic rule module executes the dynamic admission mechanism. The static admission mechanism is manually configured by the user, for example, by providing a manual configuration interface where the user inputs parameter values ​​or restrictions. Alternatively, the user can write code to manage the rules, implementing automatic admission judgment through code. In this invention, the field information in the request is used for rule checking, which can be achieved by setting admission rules for the fields or by automatically checking the fields through code. The dynamic admission mechanism mainly detects whether the resource request is reasonable. For example, it dynamically checks the resource request status based on the current Kubernetes cluster monitoring data, and issues warnings or modifications to the quantity and size of the resource request based on the current resource status of the Kubernetes cluster.

[0047] In some embodiments, the static rules module is configured to: use a static admission mechanism to check the image download address, service exposure port number, and request address in the request; determine the requests corresponding to the image download address, service exposure port number, and request address that conform to the static admission mechanism as admission requests; and intercept or issue a notification that modifications are needed for the requests corresponding to the image download address, service exposure port number, and request address that do not conform to the static admission mechanism. For example, in a Kubernetes-based automated pre-admission management system, the static rules module is responsible for auditing the necessary fields when creating resources, including the image download address, service exposure port number, and request source address. Static rules include two filtering actions: admission and interception. Users can freely combine these two filtering actions with the aforementioned audit fields to achieve preliminary auditing and prevention of resource creation requests.

[0048] The dynamic rules module is configured to: use a dynamic admission mechanism to check the resource usage limits, resource replica counts, and elastic scaling limits of individual containers in the requests; determine that requests for resources not exceeding these limits in the Kubernetes system as admission requests; and intercept or issue a notification requiring modification for requests that do not exceed these limits. For example, the dynamic rules module is responsible for auditing the specific resource requirements during resource creation, including the upper and lower limits of individual container resource usage, resource replica counts, and elastic scaling limits. Dynamic rules include three actions: admission, modification, and interception. This module dynamically intercepts / adjusts resource creation requests based on real-time monitoring data and the current total cluster capacity. When an anomaly occurs, such as a user deploying a service involving multiple resources, but due to an error, the quantity of several resources is increased from 2 to 2000, and the current total cluster resource limit is insufficient to support such a large expansion, the request will be identified as an anomaly by the admission front-end machine to avoid deployment failure. The admission front-end machine will then modify the expansion quantity based on the current remaining cluster capacity and notify the user and administrator, providing a resource shortage warning. This warning and modification can be executed through the monitoring and alarm system.

[0049] In a native Kubernetes cluster, Kube-Apiserver is the entry point for all requests. With auditing enabled, Kube-Apiserver needs to copy and store the complete request information locally. Since the complete request information includes all request metadata, this can cause performance issues for Kube-Apiserver under large volumes of requests. This invention forwards all requests to Kube-Apiserver to the admission front-end server, thus resolving this problem.

[0050] like Figure 2 As shown, this invention provides an automated pre-admission management method based on Kubernetes, comprising:

[0051] Step 210: Intercept all requests to Kube-Apiserver, prepend the requests, and parse the information messages of the requests.

[0052] Step 220: Based on the information message, obtain the fields that need to be audited, and use static and dynamic admission mechanisms to check the fields that need to be audited to manage whether the request is approved or needs to be modified. The static admission mechanism is manually configured by the user, while the dynamic admission mechanism dynamically checks the resource request status of the request based on the current Kubernetes cluster monitoring data, and issues warnings or modifications to the quantity and size of resource requests based on the current resource status of the Kubernetes cluster. Warnings can be issued using pop-up windows, while modifications can provide a modification interface or directly modify the content of the initial request sent to the Kube-Apiserver.

[0053] Step 230: Summarize and store the information of the requests based on the inspection results, and send the admission request to the Kube-Apiserver to execute the subsequent corresponding resource creation process. The inspection result information is stored by the Kubernetes cluster's audit reporting system, in the same location as the logs, but processed by the rules server, i.e., the result of executing the static and dynamic admission mechanisms described above.

[0054] In step 210, the step of pre-processing the request and parsing the information message of the request includes:

[0055] All requests to the Kube-Apiserver are forwarded to the admission front server, which parses the information packets of the requests. The admission front server exists outside the Kubernetes cluster.

[0056] In step 220, the step of using static and dynamic admission mechanisms to check the fields requiring auditing in order to manage whether the request is approved or needs to be modified includes:

[0057] The static admission mechanism is used to check the image download address, service exposure port number, and request address in the request. Requests with image download addresses, service exposure port numbers, and request addresses that conform to the static admission mechanism are determined as admission requests. Requests with image download addresses, service exposure port numbers, and request addresses that do not conform to the static admission mechanism are intercepted or a notification that modification is required is issued.

[0058] Furthermore, the method of using static and dynamic admission mechanisms to check the fields requiring auditing in order to manage whether the request is approved or needs modification also includes:

[0059] The dynamic admission mechanism checks the limits on the number of single container resources, resource replicas, and elastic scaling of resources in the request. Requests whose resource quantity does not exceed the limits on the number of single container resources, resource replicas, and elastic scaling of resources in the Kubernetes system are determined to be admission requests. Requests whose resource quantity does not exceed the limits on the number of single container resources, resource replicas, and elastic scaling of resources in the Kubernetes system are intercepted or a notification requiring modification is issued.

[0060] This invention provides an automated pre-access management method based on Kubernetes, which can be understood in conjunction with the content of this invention regarding the automated pre-access management system based on Kubernetes, and will not be repeated here.

[0061] The present invention also provides an electronic device, comprising:

[0062] At least one processor; and at least one memory communicatively connected to the processor, wherein the memory stores program instructions executable by the processor, and the processor can execute the above-described Kubernetes-based automated pre-admission management method by invoking the program instructions.

[0063] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described Kubernetes-based automated pre-admission management method.

[0064] It is understood that computer-readable storage media can include: any entity or device capable of carrying computer programs, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc. Computer programs include computer program code. Computer program code can be in the form of source code, object code, executable files, or certain intermediate forms, etc. Computer-readable storage media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc.

[0065] In some embodiments of the present invention, the device may include a controller, which is a microcontroller chip integrating a processor, memory, communication module, etc. The processor may refer to the processor included in the controller. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0066] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0067] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0068] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An automated pre-admission management method based on Kubernetes, characterized in that, include: Intercept all requests to Kube-Apiserver, prepend the requests, and parse the information messages of the requests; This includes forwarding all requests to the Kube-Apiserver to the admission front server, which parses the information packets of the requests. The admission front server exists outside the Kubernetes cluster. Based on the information message, the fields that need to be audited are obtained. Static and dynamic admission mechanisms are used to check the fields that need to be audited in order to manage whether the request is allowed or needs to be modified. The static admission mechanism is used to check the rules of human behavior. The dynamic admission mechanism can dynamically intercept or adjust resource creation requests based on the monitoring data transmitted in real time and the total capacity of the current cluster. The dynamic admission mechanism can dynamically check the resource application status of the request based on the monitoring data of the current Kubernetes cluster, and issue warnings or modifications to the number and size of resource applications based on the resource status of the current Kubernetes cluster. The information of the request is summarized and stored based on the inspection results, and the access request is sent to the Kube-Apiserver to execute the subsequent corresponding resource creation process.

2. The Kubernetes-based automated pre-admission management method according to claim 1, characterized in that, The method of using static and dynamic admission mechanisms to check the fields requiring auditing in order to manage whether a request is approved or needs modification includes: The static admission mechanism is used to check the image download address, service exposure port number, and request address in the request. Requests with image download addresses, service exposure port numbers, and request addresses that conform to the static admission mechanism are determined as admission requests. Requests with image download addresses, service exposure port numbers, and request addresses that do not conform to the static admission mechanism are intercepted or a notification that modification is required is issued.

3. The Kubernetes-based automated pre-admission management method according to claim 2, characterized in that, The method of using static and dynamic admission mechanisms to check the fields requiring auditing in order to manage whether a request is approved or needs modification also includes: The dynamic admission mechanism checks the single container resource usage limit, resource replica limit, and resource elastic scaling limit in the request. Requests whose resource quantity does not exceed the single container resource usage limit, resource replica limit, and resource elastic scaling limit in the Kubernetes system are determined to be admission requests.

4. The Kubernetes-based automated pre-admission management method according to claim 1, characterized in that, The static admission mechanism is configured manually by the user.

5. An automated pre-access management system based on Kubernetes, characterized in that, include: The admission front-end is configured to acquire all intercepted requests to the Kube-Apiserver, parse the information packets of the requests, and send them to the rules server. This includes forwarding all requests to the Kube-Apiserver to the admission front-end, which parses the information packets of the requests. The admission front-end exists outside the Kubernetes cluster. The rules server is configured to obtain the fields that need to be audited based on the information message, and use static and dynamic admission mechanisms to check the fields that need to be audited in order to manage whether the request is approved or needs to be modified. The process involves sending the access request to the Kube-Apiserver to execute the subsequent resource creation process, summarizing the request information based on the inspection results, and storing the summarized request information in the audit reporting system; wherein: The static admission mechanism is used to check rules for human behavior; the dynamic admission mechanism can dynamically intercept or adjust resource creation requests based on real-time monitoring data and the current total capacity of the cluster. The dynamic admission mechanism can dynamically check the resource request status of the request based on the current Kubernetes cluster monitoring data, and issue warnings or modifications to the quantity and size of the resource requests based on the current resource status of the Kubernetes cluster.

6. The Kubernetes-based automated pre-access management system according to claim 5, characterized in that, The rule server includes a static rule module, which is configured to: use a static admission mechanism to check the image download address, service exposure port number, and request address in the request; determine the requests corresponding to the image download address, service exposure port number, and request address that conform to the static admission mechanism as admission requests; and intercept or issue a notification that modification is required for the requests corresponding to the image download address, service exposure port number, and request address that do not conform to the static admission mechanism.

7. The Kubernetes-based automated pre-access management system according to claim 5, characterized in that, The rule server includes a dynamic rule module, which is configured to: use a dynamic admission mechanism to check the single container resource usage limit, resource replica limit, and resource elastic scaling limit in the request; and determine the request as an admission request if the number of requested resources does not exceed the single container resource usage limit, resource replica limit, and resource elastic scaling limit in the Kubernetes system.

8. The Kubernetes-based automated pre-access management system according to claim 5, characterized in that, The static admission mechanism is configured manually by the user.

9. An electronic device, characterized in that, include: At least one processor; And at least one memory communicatively connected to the processor, wherein: the memory stores program instructions executable by the processor, and the processor can execute the method as described in any one of claims 1 to 4 by invoking the program instructions.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a computer, performs the method as described in any one of claims 1 to 4.

Images