A k8s-oriented RESTful API anomaly detection method

Abstract

The application discloses a kind of RESTful API exception detection methods for k8s, belong to RESTful API fuzzy test technical field, including: obtaining the source code of Kubernetes, modify source code so that Kubernetes can output coverage before responding to request, compile and run Kubernetes API Server;API specification file is obtained and is parsed, initiates several rounds of fuzzy test, and updates seed queue according to the output coverage, randomly mutates each request in seed queue, and carries out fuzzy test based on the request after mutation;Based on the request in each round of fuzzy test and corresponding response, all 5xx responses are screened out, the corresponding request is replayed, and the source code line number that triggers exception is located in the call stack printed in Kubernetes API Server according to the response of replay request.

Description

Technical Field

[0001] This invention belongs to the field of RESTful API fuzz testing technology, and in particular relates to a method for detecting anomalies in RESTful APIs for Kubernetes. Background Technology

[0002] Kubernetes (k8s) has rapidly gained widespread adoption in the internet industry due to its capabilities in automated deployment, elastic scaling, service discovery, and fault self-healing. Compared to the previously more common physical machine deployment method, Kubernetes greatly improves deployment flexibility; its related plugins and toolchains continue to expand, providing enterprises with reliable support and abundant technical resources for their cloud-native architecture transformation.

[0003] One of the core components of Kubernetes is the Kubernetes API Server. Its primary responsibility is to serve as the unified entry point for the cluster, receiving, validating, and processing requests from clients. The API Server exposes RESTful application programming interfaces (APIs), and all resource objects are manipulated using standard HTTP methods. Request and response data are serialized in JSON format, supporting parameterized queries such as filtering, pagination, and field selection via HTTP Query Parameters, enabling flexible data access and resource control. Kubernetes also provides standardized API documentation to help users correctly utilize its RESTful API.

[0004] Through these RESTful interfaces, external systems can directly interact with the Kubernetes cluster to dynamically create, update, and delete resources. However, this open interaction method also introduces certain correctness and security risks. On the one hand, the API Server is the sole entry point to the cluster state; any erroneous or unverified request may lead to service anomalies. Furthermore, Kubernetes' handling of some anomalies may be incorrect, potentially significantly increasing Kubernetes overhead and creating vulnerabilities for DoS attacks. Fuzzing these RESTful APIs can reveal these risks and is therefore of positive significance.

[0005] Against this backdrop, there is currently very little research on fuzzing Kubernetes RESTful APIs. Existing fuzzing tools, such as Restler, either cannot handle the highly structured fuzzing required for RESTful API scenarios or have numerous functional limitations, which can be summarized as follows:

[0006] 1. Existing RESTful API fuzzing tools lack targeted system design regarding resource creation and Kubernetes error responses. Firstly, RESTful APIs have basic dependencies; for example, a query API is only meaningful if it is called (GET) after a POST API is created. However, in practice, existing RESTful API fuzzing tools do not handle this properly, or only address dependencies on Kubernetes resources, not dependencies on these HTTP methods. Furthermore, Kubernetes 422 response bodies contain specific error categories indicating the specific error type of the user's HTTP request; this information is also not accurately used by existing RESTful API fuzzing tools.

[0007] 2. Insufficient mutation strategies. RESTful API fuzzing places high demands on the validity of HTTP request JSON and also requires maximizing mutation as much as possible. Existing fuzzing tools generally do not consider the mutation characteristics of many JSON scenarios in their implementation, such as removing arbitrary nodes and their child nodes from the JSON tree, randomly changing the value of JSON fields to arbitrary types, and concatenating two existing JSONs in the child queue, etc.

[0008] 3. Fuzzing is generally not guided by the fundamental block coverage of programming languages. Existing RESTful API fuzzing tools are generally pure black-box testing. This is because, in RESTful API fuzzing, the industry consensus is that the server-side software is inaccessible to testers. In this situation, obtaining real-time fundamental block coverage of the server-side software is impractical, let alone using it to guide fuzzing. Existing RESTful API fuzzing tools generally only use "API specification coverage," that is, the proportion of successfully executed API requests to the total number of requests defined in the API specification. Obviously, this is a very indirect metric and cannot directly reflect the internal behavior of the software. In addition, some traditional fuzzing tools, such as AFL, do guide fuzzing based on line or fundamental block coverage; however, these traditional fuzzing tools are only suitable for generating binary data and are powerless when faced with the structured HTTP requests of RESTful APIs. Summary of the Invention

[0009] The purpose of this application is to provide a method for detecting anomalies in RESTful APIs for Kubernetes, addressing the problems existing in the prior art.

[0010] According to a first aspect of the embodiments of this application, a method for detecting anomalies in a RESTful API for Kubernetes is provided, comprising:

[0011] Obtain the Kubernetes source code, modify the source code so that Kubernetes can output coverage before responding to each received HTTP request, compile and run the Kubernetes API Server;

[0012] Obtain and parse the API specification file that matches the source code, initiate several rounds of fuzz testing based on the parsed API specification file, update the seed queue according to the output coverage, randomly mutate each request in the seed queue, and perform fuzz testing based on the mutated requests.

[0013] Based on the requests and corresponding responses in each round of fuzzing, all 5xx responses are filtered out, the corresponding requests are replayed, and the source code line number that triggered the exception is located in the call stack printed by the Kubernetes API Server according to the response of the replayed request.

[0014] Furthermore, obtain the Kubernetes source code, modify the source code so that Kubernetes can output coverage before responding to each received HTTP request, compile and run the Kubernetes API Server, including:

[0015] Obtain the latest Kubernetes source code and add a custom processing function to the HTTP request function processing list of the source code, so that Kubernetes can output a coverage file to the directory specified by the environment variable before responding to each received HTTP request;

[0016] Obtain a compiler that matches your Kubernetes version, download and install it, and compile the modified Kubernetes source code.

[0017] Download and run the Etcd binary, run the Kubernetes API Server from the compilation results separately, and redirect the output stream of the Kubernetes API Server to a fixed file.

[0018] Further, the API specification file matching the source code is obtained and parsed. Based on the parsed API specification file, several rounds of fuzz testing are initiated, and the fuzz test seed queue is updated according to the output coverage, including:

[0019] Obtain the API specification file that matches the source code, parse the part of the API specification file that involves HTTP requests, and group them according to the HTTP request path. In each group, sort them according to the four HTTP request methods: POST, GET, PUT, and DELETE.

[0020] Based on the parsed API specification file, all required fields of the POST request are filled with valid fixed values ​​according to the API specification, and all optional fields are left unfilled. The filled POST requests are then sent to the Kubernetes API Server in sequence. If the Kubernetes API Server responds with a 422 response, the request is modified according to the response information and the request is sent again, until the Kubernetes API Server responds with a 2xx response or the predetermined number of requests is reached.

[0021] Based on the parsed API specification file, for each type of request, all required fields are filled with valid fixed values ​​according to the API specification, and all optional fields are filled with valid random values ​​or left blank. The filled requests are sent to the Kubernetes API Server in sequence, and the difference in coverage between the current request and the previous request is monitored. If the current request generates new coverage, the request is added to the seed queue.

[0022] Each request in the seed queue is taken out in sequence, and the taken-out request is randomly mutated several times. Fuzz testing is performed on the mutated request, and the seed queue is updated according to the output coverage, until the seed queue is empty.

[0023] Furthermore, if the Kubernetes API Server issues a 422 response, the request is modified based on the `causes.reason` field of the response, specifically as follows:

[0024] If a FieldValueRequired error occurs, it means that some fields required by Kubernetes have not been filled. In this case, the fields mentioned in the error message should be filled.

[0025] If the error FieldValueInvalid or FieldValueNotSupported is reported, it means that some fields required by Kubernetes have been incorrectly filled. Replace them according to the fields mentioned in the error and their corresponding valid values.

[0026] Furthermore, the random mutation is implemented through any of the following mutation strategies, which include:

[0027] Random field modification: Based on the parsed API specification file, randomly select a random number of fields from the request parameter k and randomly modify their values ​​and value types;

[0028] Randomly add fields: Based on the parsed API specification file, randomly select a random number of fields that are not present in the request k parameter but exist in the API specification, and add random values ​​to them;

[0029] Random field deletion: Based on the parsed API specification file, randomly select a random number of fields from the request parameter k and delete them;

[0030] Merging fields from multiple requests: Randomly select a request m from the seed queue, and randomly select some parameters from request k and request m for merging.

[0031] Furthermore, based on the requests and corresponding responses in each round of fuzzing, all 5xx responses are filtered out, and the corresponding requests are replayed. Based on the responses of the replayed requests, the line numbers of the source code that triggered the exception are located in the call stack printed by the Kubernetes API Server, including:

[0032] Obtain the requests and corresponding responses in each round of fuzz testing, and filter out all 5xx responses and their corresponding requests;

[0033] All selected requests are replayed to the Kubernetes API Server, and it is confirmed that the obtained response is still 5xx. Then, the call stack printed by Kubernetes is obtained, and the function called that threw the exception is matched. The function call before that function is the function that threw the exception, thereby locating the source code line number that triggered the exception.

[0034] According to a second aspect of the embodiments of this application, a RESTful API anomaly detection device for Kubernetes is provided, comprising:

[0035] The environment setup module is used to obtain the Kubernetes source code, modify the source code so that Kubernetes can output coverage before responding to each received HTTP request, compile and run the Kubernetes API Server;

[0036] The fuzzing module is used to obtain and parse the API specification file that matches the source code, initiate several rounds of fuzzing based on the parsed API specification file, update the seed queue according to the output coverage, randomly mutate each request in the seed queue, and perform fuzzing based on the mutated requests.

[0037] The anomaly localization module is used to filter out all 5xx responses based on the requests and corresponding responses in each round of fuzzing, replay the corresponding requests, and locate the source code line number that triggered the anomaly in the call stack printed by the Kubernetes API Server based on the responses of the replayed requests.

[0038] According to a third aspect of the embodiments of this application, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the method described in the first aspect.

[0039] According to a fourth aspect of the embodiments of this application, an electronic device is provided, comprising:

[0040] One or more processors;

[0041] Memory, used to store one or more programs;

[0042] When the one or more programs are executed by the one or more processors, the one or more processors perform the method as described in the first aspect.

[0043] According to a fifth aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0044] The technical solutions provided by the embodiments of this application may include the following beneficial effects:

[0045] This invention focuses on the Kubernetes API Server scenario. It can improve the effectiveness of fuzz testing by modifying POST requests in real time through Kubernetes responses, and can also automatically locate the Kubernetes source code lines in the call stack that cause anomalies, thereby assisting developers in efficiently and accurately fixing Kubernetes.

[0046] This invention targets HTTP web services like Kubernetes, which are written in Golang. It uses basic block coverage to guide fuzz testing, significantly improving the efficiency of fuzz testing compared to existing general RESTful API fuzz testing techniques.

[0047] This invention proposes a phased fuzzing method that ensures, to the greatest extent possible, that resources are correctly created and invoked before large-scale fuzzing is conducted, thereby improving the effectiveness and efficiency of fuzzing compared to existing technologies.

[0048] Compared to existing technologies, this invention can detect significantly more internal Kubernetes anomalies in a shorter time; furthermore, the anomalies detected by this invention, if maliciously exploited, can indeed lead to a significant increase in the load of the Kubernetes cluster, thus having practical significance.

[0049] Only a small portion of the non-core functions of this invention are specifically designed for Kubernetes; the rest are all general fuzzing methods. This means that with slight modifications, this invention can perform fuzzing on any HTTP web service written in Golang that has an API specification document, demonstrating strong scalability.

[0050] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0052] Figure 1 This is a flowchart illustrating an anomaly detection method for a RESTful API targeting Kubernetes, according to an exemplary embodiment.

[0053] Figure 2 This is a block diagram illustrating an anomaly detection device for a RESTful API in Kubernetes, according to an exemplary embodiment.

[0054] Figure 3 This is a schematic diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0055] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0056] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0057] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0058] Figure 1 This is a flowchart illustrating an anomaly detection method for a RESTful API targeting Kubernetes, according to an exemplary embodiment. Figure 1 As shown, the method may include the following steps:

[0059] S1: Obtain the Kubernetes source code, modify the source code so that Kubernetes can output coverage before responding to each received HTTP request, compile and run the Kubernetes API Server;

[0060] The specific implementation of step S1 may include the following sub-steps:

[0061] S11: Obtain the latest Kubernetes source code and add a custom processing function to the HTTP request function processing list of the source code, so that Kubernetes can output a coverage file to the directory specified by the environment variable before responding to each received HTTP request;

[0062] Specifically, download the latest source code from the official Kubernetes Git repository. Then, modify the Kubernetes source code by adding a custom handler function to the `DefaultBuildHandlerChain` list of HTTP request handling functions. This function uses the coverage statistics functionality built into the Golang standard library to output a coverage file to the directory specified by the environment variable `GOCOVERDIR` before Kubernetes responds to each received request. This modification to the source code needs to ensure that "output coverage" is the last operation before the Kubernetes API Server responds; this ensures the integrity of the output coverage, that is, it fully counts the basic blocks covered by this request processing.

[0063] More specifically, the coverage output here is the sum of all basic blocks covered from the time the Kubernetes API Server starts up until the time of output.

[0064] S12: Obtain a compiler that matches the Kubernetes version, download and install it, and compile the modified Kubernetes source code;

[0065] Specifically, obtain a compiler from the Golang website that matches the Kubernetes version used in step S11, download and install it. Then, configure the GOBLAGS and GOCOVERDIR environment variables so that the compilation results can print coverage files in the expected directory. Finally, use the `make` command to compile the modified Kubernetes source code repository from step S11.

[0066] S13: Download and run the Etcd binary, run the Kubernetes APIServer from the compilation results separately, and redirect the output stream of the Kubernetes API Server to a fixed file;

[0067] First, download and run Etcd, a storage component that Kubernetes depends on but is not included in the Kubernetes source code. Then, run the kube-apiserver binary file from the Kubernetes compilation output. When running the command and parameters, pay attention to the following points:

[0068] For convenience, it is recommended to configure startup command parameters to exclude authentication and authorization processes as much as possible; for authorization steps that cannot be excluded, specify a fixed authorization token in the startup command parameters.

[0069] For ease of subsequent fuzz testing, a fixed TCP listening port is specified in the startup command parameters.

[0070] The output stream of the Kubernetes API Server is redirected to a fixed file to prepare for subsequent call stack analysis.

[0071] By following the steps above, you have completed the setup of the Kubernetes API Server environment.

[0072] S2: Obtain the API specification file that matches the source code and parse it. Initiate several rounds of fuzz testing based on the parsed API specification file and update the fuzz test seed queue according to the output coverage.

[0073] Specifically, this step may include the following sub-steps:

[0074] S21: Obtain the API specification file that matches the source code, parse the part of the API specification file that involves HTTP requests, and group them according to the HTTP request path. In each group, sort them according to the four HTTP request methods: POST, GET, PUT, and DELETE.

[0075] Specifically, obtain the API specification file from the Kubernetes website that matches the Kubernetes version specified in step S11. Ensure the API specification file largely conforms to the OpenAPI v3 definition. Then, correctly parse the HTTP request sections of the API specification file and group them according to HTTP request paths. Within each group, further sort them according to the four HTTP request methods: POST, GET, PUT, and DELETE. This is done to prepare for subsequent fuzzing. Each HTTP request path generally corresponds to a resource type in Kubernetes. Clearly, a resource needs to be created (POST), then retrieved / modified (GET, PUT), and finally deleted (DELETE). Performing fuzzing in this order allows for deeper penetration into the business logic of Kubernetes' handling of these requests, thus improving fuzzing coverage; rather than stopping at the surface level of business logic due to failed resource validity verification. The subsequent fuzzing process will also rely on this sorting, so it's essential to sort them correctly beforehand.

[0076] S22: Based on the parsed API specification file, fill all required fields of the POST request with valid fixed values ​​according to the API specification, leave all optional fields blank, and send the filled POST requests to the Kubernetes API Server in sequence; if the Kubernetes API Server responds with a 422 response, modify the request according to the response information and resend the request, until the Kubernetes API Server responds with a 2xx response or the predetermined number of requests is reached;

[0077] Specifically, based on the parsed API specification from step S21, all POST requests are selected, and all required fields are filled with valid fixed values ​​according to the API specification. Optional fields are left unfilled. Specifically, filling with a valid fixed value means that for each field, only one fixed, valid value conforming to the specification document's definition of that field type is filled; for example, for string fields, "fixed" is filled uniformly, and for numeric fields, "1" is filled uniformly. Subsequently, these POST requests are sent sequentially to the running Kubernetes API Server.

[0078] If the Kubernetes API Server responds with a 422 response, the request is modified based on the `causes.reason` field in the response. Kubernetes has a relatively stable pattern for `causes.reason`, as follows:

[0079] (1) Error FieldValueRequired: This means that some fields required by Kubernetes have not been filled in this step; when you encounter this error, just fill in the fields mentioned in the error, and the filling method is the same as the above method.

[0080] (2) Error FieldValueInvalid or FieldValueNotSupported: This means that some fields required by Kubernetes have been incorrectly filled in this step; when encountering this error, replace them according to the fields mentioned in the error and their corresponding valid values.

[0081] Then, the request is resent, and this process is repeated up to 5 times until the HTTP response code from Kubernetes is 2xx; if a 2xx response is still not obtained, the request is skipped.

[0082] If the Kubernetes API Server issues a response other than a 422 or 2xx response, the request is skipped.

[0083] The significance of this step is to ensure, to the greatest extent possible, that the resources have been correctly created (POST) before the formal fuzzing process begins. This invention first modifies the POST request based on the content of the 422 response body (if any) from the Kubernetes API Server's POST response. As mentioned earlier, Kubernetes responses are highly structured; `causes.reason` contains fixed strings describing the type of 422 error, and each error corresponds to a deterministic modification method. Therefore, this invention uses this as a basis to modify failed POST requests and resend them. In practice, the `causes.reason` returned by the Kubernetes API Server mainly consists of the two types mentioned above, while many other types of `causes.reason` are also written in the Kubernetes API Server source code, making it easy to modify POST requests based on them.

[0084] S23: Based on the parsed API specification file, for each type of request (including POST, GET, PUT, DELETE), all required fields are filled with valid fixed values ​​according to the API specification, and all optional fields are filled with valid random values ​​or left blank. The filled requests are sent to the Kubernetes API Server in sequence, and the difference in coverage between the current request and the previous request is monitored. If the current request generates new coverage, the request is added to the seed queue.

[0085] Specifically, after step S22 is completed, based on the API specification parsed in step S21, all required fields are filled with valid fixed values ​​according to the API specification. All optional fields can be filled with valid random values ​​or left blank. The term "valid fixed values" has already been explained in step S22. "Valid random values" means that for each field, any value conforming to the specification document's definition of that field type can be filled: for example, if a field is only required to be "string type", then any string type such as "foo" or "bar" can be filled in.

[0086] These requests are then sent sequentially to the running Kubernetes API Server, and the above loop is repeated several times.

[0087] The significance of conducting fuzz testing in the order of S22 first, then S23 is to first ensure that the resources are created correctly as much as possible, and then conduct fuzz testing on the created resources.

[0088] More specifically, the required fields in S22 and S23 are filled with consistent, fixed values. The advantage of this is that fields marked as required in the Kubernetes API specification are generally very important; for example, resource names are usually required. The fact that the required fields in S22 and S23 are filled with consistent, fixed values ​​ensures that resources created in S22 can be accessed by GET, PUT, DELETE, and other requests in S23 as much as possible.

[0089] During execution, monitor for differences in coverage output between the current request and the previous request. Specifically, the official Golang tool `go tool covdata` can be used to compare the coverage files of the two requests. If the current request generates new coverage, the request is added to the seed queue. Coverage files that have been compared and are no longer needed are periodically cleaned up to improve system efficiency.

[0090] The advantage of coverage-based fuzzing is that it can quickly filter out meaningless mutation directions. The coverage scheme used in this invention is Golang's basic block coverage, meaning it can detect whether each code branch is covered. In this implementation, the coverage output by the Kubernetes API Server each time is the sum of all basic blocks covered from its startup time to the time of output. For two requests A and B mutated and sent sequentially by the fuzzing tool, if the coverage of B is exactly the same as that of A, it means that B has not triggered any new Kubernetes API Server source code branches; therefore, this mutation direction of request B should not be considered, and the seed queue should not be filled with B.

[0091] S24: Take out each request in the seed queue in order, perform several random mutations on the taken requests, perform fuzz testing based on the mutated requests, and update the seed queue according to the output coverage until the seed queue is empty.

[0092] For each request k retrieved, the random mutation can adopt any of the following four random mutation strategies:

[0093] ① Randomly Modify Fields: Based on the parsed API specification file, randomly select a random number of fields from the request parameter k, and randomly modify them to random values. The data type of the values ​​is also random. The modified request is denoted as k. m1 ;

[0094] ② Randomly add fields: Based on the parsed API specification file, randomly select a random number of fields that are not present in the API specification but are not present in the request parameter k, and randomly add values ​​to these fields. The data type of the values ​​is also random. The request after adding these fields is denoted as k. m2 ;

[0095] ③ Random field deletion: Based on the parsed API specification file, randomly select a random number of fields from the request parameter k and delete them all. The request after deletion is denoted as k. m3 ;

[0096] ④ Merging fields from multiple requests: Randomly select a request m from the seed queue generated in step S23, randomly select some parameters from request k and request m, and merge them. The merged request is denoted as k. m4 ;

[0097] The purpose of step S24 is primarily to mutate the request as much as possible. S24 focuses on mutating the rest of the request to the greatest extent possible, provided that the key names of the request fields still conform to the API specification. This includes randomly adding, deleting, or modifying one or a group of parameter values, as well as merging parameters with those in other seed queues.

[0098] S3: Based on the requests and their corresponding subsequent iterations in each round of fuzzing, these mutated requests are sequentially sent to the running Kubernetes API Server. During execution, the difference in coverage output between the current request and the previous request is monitored. If the current request generates new coverage, the request is added to the seed queue. This process is repeated until the seed queue is empty. Coverage files that have been compared and are no longer used are periodically cleaned up to improve system efficiency.

[0099] The response is filtered to identify all 5xx responses. The corresponding request is replayed, and the line number of the source code that triggered the exception is located in the call stack printed by the Kubernetes API Server based on the response of the replayed request.

[0100] In a specific implementation, step S3 may include:

[0101] S31: Obtain the requests and corresponding responses in each round of fuzz testing, and filter out all 5xx responses and their corresponding requests;

[0102] Collect all response results from steps S22, S23, and S24, classify them according to the response code, and obtain all responses for 5xx status codes and their corresponding requests.

[0103] S32: Replay all the filtered requests to the Kubernetes API Server and confirm whether the obtained response is still 5xx. Then obtain the call stack printed by Kubernetes, match the function called that threw the exception, and the function call before that function is the function that threw the exception, thereby locating the source code line number that triggered the exception.

[0104] The response to the replay request will be recorded in the following two ways:

[0105] If the response code is not 5xx, store the request for later manual analysis.

[0106] If the response code is 5xx, the call stack printed by Kubernetes through S13 is collected, and the string "handlers.(*RequestScope).err" of the function called that threw the exception is matched. The function call preceding this function (denoted as function f) is the function that threw the exception. The line number of function f displayed in the call stack is stored. In rare cases, the matching may fail, and the requests that fail to match are also stored.

[0107] The purpose of this replay step is to demonstrate that in S2 practice, the Kubernetes API Server may issue 5xx responses due to other unknown instability reasons. This invention primarily focuses on reproducible 5xx requests, that is, situations where it is clearly an implementation error in the Kubernetes API Server's request processing chain that leads to a stable 5xx response. For 5xx situations that cannot be reproduced, the causes may be relatively complex and require further manual analysis, so they are also stored in this step.

[0108] After this, all the contents stored in steps S31 and S32 can be serialized and output to a file.

[0109] Corresponding to the aforementioned embodiments of the RESTful API anomaly detection method for Kubernetes, this application also provides embodiments of a RESTful API anomaly detection device for Kubernetes.

[0110] Figure 2 This is a block diagram illustrating an anomaly detection device for a RESTful API in Kubernetes, according to an exemplary embodiment. (Refer to...) Figure 2 The device may include:

[0111] Environment setup module 21 is used to obtain the source code of Kubernetes, modify the source code so that Kubernetes can output coverage before responding to each received HTTP request, compile and run the Kubernetes API Server;

[0112] The fuzzing module 22 is used to obtain and parse the API specification file that matches the source code, initiate several rounds of fuzzing based on the parsed API specification file, update the seed queue according to the output coverage, randomly mutate each request in the seed queue, and perform fuzzing based on the mutated requests.

[0113] The anomaly localization module 23 is used to filter out all 5xx responses based on the requests and corresponding responses in each round of fuzzing, replay the corresponding requests, and locate the source code line number that triggered the anomaly in the call stack printed by the Kubernetes API Server based on the response of the replayed requests.

[0114] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0115] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0116] Accordingly, this application also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the above-described RESTful API anomaly detection method for Kubernetes.

[0117] Accordingly, this application also provides an electronic device, including: one or more processors; a memory for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the above-described RESTful API anomaly detection method for Kubernetes. Figure 3The diagram shown is a hardware structure diagram of any device with data processing capabilities, where a RESTful API anomaly detection device for Kubernetes provided by an embodiment of the present invention can be located. (Except for...) Figure 3 In addition to the processor, memory, and network interface shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0118] Accordingly, this application also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the aforementioned RESTful API anomaly detection method for Kubernetes. The computer-readable storage medium can be an internal storage unit of any data-processing device as described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data-processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data-processing device, and can also be used to temporarily store data that has been output or will be output.

[0119] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

Claims

1. A k8s-oriented RESTful API anomaly detection method, characterized in that, The method comprises the following steps: obtaining the source code of Kubernetes, modifying the source code so that Kubernetes can output coverage before responding to each received HTTP request, compiling and running the Kubernetes API Server; obtaining an API specification file matched with the source code and parsing the API specification file, initiating several rounds of fuzz testing based on the parsed API specification file, and updating the seed queue according to the output coverage, randomly mutating each request in the seed queue, and performing fuzz testing based on the mutated request; based on the request and the corresponding response in each round of fuzz testing, all 5xx responses are screened out, the corresponding request is replayed, and the source code line number triggering the exception is located in the call stack printed by the Kubernetes API Server according to the response of the replay request; wherein, obtaining an API specification file matched with the source code and parsing the API specification file, initiating several rounds of fuzz testing based on the parsed API specification file, and updating the fuzz testing seed queue according to the output coverage comprises: obtaining an API specification file matched with the source code, parsing the part related to HTTP request in the API specification file, and grouping according to HTTP request path, and sorting according to POST, GET, PUT and DELETE four kinds of HTTP request methods in each group; based on the parsed API specification file, all mandatory fields of POST request are filled with legal fixed values according to the API specification, all optional fields are not filled, and the filled POST request is sent to the Kubernetes API Server in turn; if the Kubernetes API Server makes a 422 response, the request is modified and initiated again until the Kubernetes API Server makes a 2xx response or reaches a predetermined number of request initiation times; based on the parsed API specification file, for each type of request, all mandatory fields are filled with legal fixed values according to the API specification, all optional fields are filled with legal random values or not filled, and the filled request is sent to the Kubernetes API Server in turn, and the difference between the coverage output by the current request and the last request is monitored; if the current request produces new coverage, the request is added to the seed queue; each request in the seed queue is taken out in order, the taken-out request is randomly mutated several times, fuzz testing is performed based on the mutated request, the seed queue is updated according to the output coverage, and the seed queue is empty.

2. The method of claim 1, wherein, obtaining the source code of Kubernetes, modifying the source code so that Kubernetes can output coverage before responding to each received HTTP request, compiling and running the Kubernetes API Server, comprising: Obtain the current latest source code of Kubernetes, add a custom processing function in the HTTP request function processing list of the source code, so that Kubernetes can output the coverage file to the directory specified by the environment variable before responding to each received HTTP request; Obtain a compiler matching the Kubernetes version, download and complete the installation, and compile the modified Kubernetes source code; Download and run the Etcd binary file, run the Kubernetes API Server in the compilation result separately, and redirect the output stream of the Kubernetes API Server to a fixed file.

3. The method of claim 1, wherein, If the Kubernetes API Server makes a 422 response, modify the request according to the causes.reason field of the response, specifically: If the error FieldValueRequired, which means that some fields required by Kubernetes are not filled in, is reported, fill in the fields mentioned in the error; If the error FieldValueInvalid or FieldValueNotSupported, which means that some fields required by Kubernetes are filled in incorrectly, is reported, replace the fields mentioned in the error with the corresponding legal values.

4. The method of claim 1, wherein, The random mutation is implemented by any of the following mutation strategies, including: Randomly modify fields: based on the parsed API specification file, randomly select a random number of fields in the request k parameter, and randomly modify the values and value types; Randomly add fields: based on the parsed API specification file, randomly select a random number of fields that do not exist in the request k parameter and exist in the API specification, and add random values; Randomly delete fields: based on the parsed API specification file, randomly select a random number of fields in the request k parameter for deletion; Merge fields of multiple requests: randomly select a request m from the seed queue, and randomly select and merge part of the parameters in the request k and the request m.

5. The method of claim 1, wherein, Based on the requests and corresponding responses in each round of fuzz testing, all 5xx responses are filtered out, the corresponding requests are replayed, and the source code line number triggering the exception is located in the call stack printed by the Kubernetes APIServer, including: Obtain the request and corresponding response in each round of fuzz testing, filter out all 5xx responses and corresponding requests; Replay all the filtered requests to the Kubernetes API Server, and confirm whether the obtained response is still 5xx, then obtain the call stack printed by Kubernetes, match the function called to throw an exception, and the previous function call of the function is the function that throws an exception, thereby locating the source code line number triggering the exception.

6. A k8s-oriented RESTful API anomaly detection apparatus, characterized by, Including: An environment building module is configured to obtain source code of Kubernetes, modify the source code to enable the Kubernetes to output coverage before responding to each received HTTP request, compile and run the Kubernetes API Server; A fuzzing module is configured to obtain and parse an API specification file matched with the source code, initiate several rounds of fuzzing based on the parsed API specification file, and update a seed queue according to the output coverage, randomly mutate each request in the seed queue, and perform fuzzing based on the mutated request, and update the seed queue according to the output coverage. An exception locating module is configured to filter out all 5xx responses based on the request and the corresponding response in each round of fuzzing, replay the corresponding request, and locate the source code line number triggering the exception in the call stack printed by the Kubernetes API Server according to the response of the replayed request. The obtaining and parsing of the API specification file matched with the source code, the initiation of several rounds of fuzzing based on the parsed API specification file, and the updating of the fuzzing seed queue according to the output coverage include: The API specification file matched with the source code is obtained, the part related to the HTTP request in the API specification file is parsed, and the HTTP request paths are grouped, and the four HTTP request methods of POST, GET, PUT and DELETE are sorted in each group. Based on the parsed API specification file, all mandatory fields of POST requests are filled with legal fixed values according to the API specification, all optional fields are not filled, and the filled POST requests are sent to the Kubernetes API Server in sequence. If the Kubernetes API Server makes a 422 response, the request is modified and initiated again until the Kubernetes API Server makes a 2xx response or reaches a predetermined number of request initiations. Based on the parsed API specification file, for each type of request, all mandatory fields are filled with legal fixed values according to the API specification, all optional fields are filled with legal random values or not filled, and the filled requests are sent to the Kubernetes API Server in sequence, and the difference between the current request and the previous request is monitored. If the current request produces new coverage, the request is added to the seed queue. Each request in the seed queue is sequentially taken out, and the taken request is randomly mutated several times, and fuzzing is performed based on the mutated request, and the seed queue is updated according to the output coverage until the seed queue is empty.

7. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions are executed by the processor to implement the method of any one of claims 1-5.

8. An electronic device, comprising: The computer program / instructions are executed by the processor to implement the method of any one of claims 1-5. The computer program / instructions are executed by the processor to implement the method of any one of claims 1-5. The computer program / instructions are executed by the processor to implement the method of any one of claims 1-5. The computer program / instructions are executed by the processor to implement the method of any one of claims 1-5. When the one or more programs are executed by the one or more processors, the one or more processors implement a method according to any of claims 1-5.

9. A computer readable storage medium having stored thereon computer instructions, wherein, The instructions, when executed by a processor, implement steps of a method according to any of claims 1-5.

Images