A method and system for designing security dynamic fuzz testing for Kubernetes RESTful API

Abstract

The application discloses a Kubernetes RESTful API design security dynamic fuzzing method and system, and relates to the technical fields of cloud native and fuzzing testing.The application extracts semantic information from an OpenAPI specification document based on NLP technology to construct a new OpenAPI specification document and a fuzzy dictionary, so that high-quality request sequence test cases are generated.Then, the test cases are sent to a Kubernetes API Server component for testing, response messages are collected and analyzed, and finally, detected errors are analyzed for bugs.Parameter values conforming to semantics are generated for request sequences, so that the probability of discovering security problems in Kubernetes API design is increased.

Description

Technical Field

[0001] This invention relates to the fields of cloud-native and fuzzing technologies, and more specifically to a dynamic fuzzing method and system for security design of Kubernetes RESTful APIs. Background Technology

[0002] Kubernetes, also known as k8s, is an open-source software system hosted by the Cloud Native Computing Foundation (CNCF) for managing containerized applications across multiple hosts, providing the primary mechanism for application deployment, maintenance, and scaling. Because it significantly accelerates deployment by eliminating the burden of repetitive manual operations during container deployment, Kubernetes is frequently used in practical container cloud platforms. According to surveys, organizations such as the U.S. Department of Defense use Kubernetes to manage their application deployments, reducing the release time of 37 projects from 3-8 months to a week, saving over 100 years of time. Due to the widespread adoption of Kubernetes, it has become a significant target for cloud attacks by hackers in recent years.

[0003] According to the Kubernetes threat matrix and the OWASP Security Cheat Sheet on Kubernetes, Kubernetes currently faces major security issues such as misconfiguration, unauthorized access, and malicious images. However, they overlook a crucial issue: security vulnerabilities stemming from design flaws in Kubernetes' API itself. The official CVE website reveals that of the 179 existing Kubernetes-related CVEs, 40 are caused by API design vulnerabilities. Furthermore, of the 24,995 bug-related issues in the official Kubernetes community, 4,666 bugs are caused by API vulnerabilities. Therefore, the security problems arising from the Kubernetes API design are becoming increasingly serious, urgently requiring a fuzzing tool for the Kubernetes API to automatically uncover design flaws within the API itself.

[0004] The Kubernetes API follows the Representational State Transfer (REST) ​​architectural style. Therefore, most current RESTful API fuzzing techniques are also applicable to Kubernetes API testing. The most advanced RESTful API black-box testing tools include RESTler, RESTTESTGEN, and RESTest. These tools first use the OpenAPI specification document as test input, generating random test cases using various strategies to execute the API endpoints defined in the document. They then determine whether an unexpected error was triggered based on whether the returned response status code is 5xx, thus uncovering problems in the API design. However, these RESTful API fuzzing tools randomly select the value of each parameter when generating requests, making it almost impossible to generate valid test cases that pass the semantic checks of the Kubernetes API server. For example, RESTler first parses the input OpenAPI document and infers producer-consumer dependencies between operations. For example, if request A depends on a resource created by request B, then there is a dependency relationship A depends on B. Then, based on the dependencies, it uses a search-based algorithm and random value filling methods to generate and expand the request sequence. Furthermore, a new request matching the dependency relationship is only added to the request sequence for expansion if a previous request receives a 2xx response. However, due to Kubernetes' own rules and user-defined rules, some parameters are set to fixed values. When the Kubernetes API server receives a request, it performs a semantic check on the parameters to verify if the parameter values ​​conform to Kubernetes' own and user-defined rules. Requests that do not conform are treated as invalid and return a 4xx response. Following the request sequence extension rules, the request sequence will no longer be extended, resulting in a large number of invalid test cases with a request sequence length of 1, which fails to effectively uncover security issues in the Kubernetes API design. Summary of the Invention

[0005] To overcome the shortcomings and deficiencies of the existing technologies, this invention provides a dynamic fuzz testing method and system for the security of Kubernetes RESTful API designs. The purpose of this invention is to address the inability of existing technologies to effectively uncover security issues in Kubernetes API design. This invention uses NLP technology to collect semantic information (primarily recommended values ​​for parameters) contained in the Kubernetes OpenAPI documentation and test responses, generating semantically consistent parameter values ​​for request sequences, thereby increasing the probability of discovering security issues in Kubernetes API design.

[0006] To address the problems existing in the prior art, the present invention is achieved through the following technical solution.

[0007] The first aspect of this invention provides a dynamic fuzz testing method for security design of Kubernetes RESTful APIs, comprising the following steps:

[0008] S1. Extract semantic information from the OpenAPI specification document and test case responses based on NLP technology, and construct a new OpenAPI specification document and fuzzy test dictionary based on the extracted semantic information;

[0009] S2. By parsing the new OpenAPI specification document built in step S1, the dependencies between API operations are inferred, a test request sequence is generated based on the dependencies, the test request sequence is rendered based on the fuzzy test dictionary built in step S1 and the parameter information in the OpenAPI specification document, test cases are generated and sent to Kubernetes for testing.

[0010] S3. Collect all responses generated by test cases, and then filter out responses with response codes 4xx and 5xx respectively. Responses with response codes 4xx are considered to contain semantic information and are sent to step S1 for further semantic information extraction. Responses with response codes 5xx are considered to have triggered an unexpected error in the Kubernetes API server and are considered bugs for error analysis.

[0011] More preferably, step S1 specifically includes the following steps:

[0012] S101. Parse the Kubernetes OpenAPI specification document and extract the description field corresponding to all parameters in the specification document;

[0013] S102. If the test case response from step S3 is received, extract the message field from the test case response using the method described in step S101.

[0014] S103. Use CoreNLP functions to call the word-tokenize model, part-of-speech model, and dependency-parsing model to process the description and message fields, and then extract semantic information related to the parameters.

[0015] S104. Based on the semantic information extracted in step S103, dynamically update the Kubernetes OpenAPI specification document and fuzz test fields.

[0016] More preferably, in step S101, the specific process of parsing the Kubernetes OpenAPI specification document is as follows: obtain the key-value pairs under the path field in each API operation of the Kubernetes OpenAPI specification document; if the key contains the parameters field, then iterate through and obtain the parameter values ​​of the name and description fields under the parameters field, and store them in the parameter_list and description_list lists respectively.

[0017] Furthermore, in step S103, semantic information is extracted from the description, specifically as follows:

[0018] S1031. Using the parameter_list and description_list lists generated in step S101, iterate through the parameter_list and description_list lists, taking each parameter and description as input;

[0019] S1032. Use the word-tokenize model, part-of-speech model and dependency-parsing model to perform word segmentation, part-of-speech tagging and dependency parsing on the input description, and store the results in result_list;

[0020] S1033. Iterate through each word in result_list and try to match it with the specified parameter;

[0021] S1034. Iterate through each word in result_list and find all words related to the specified parameter.

[0022] Furthermore, in step S1032, each word is represented as a dictionary containing information such as id, text, pos, head, and deprel.

[0023] In a further preferred embodiment, in step S1033, if a matching word is found, its number is stored in the root_id variable.

[0024] In a further preferred embodiment, in step S1034, it checks whether the current word is a punctuation mark; if so, it skips the step. Otherwise, it determines whether the head of the current word is equal to the root_id; if so, it adds the text content of the word to the example_words dictionary. At the same time, it also determines whether the head of the word corresponding to the head of the current word is equal to the root_id; if so, it adds the text content of the word to the example_words dictionary. At this point, example_words represents the semantic information value corresponding to this parameter.

[0025] Furthermore, in step S104, dynamically updating the Kubernetes OpenAPI specification document specifically refers to...

[0026] S1041. Iterate through each API parameter in the original document. Check if an enum field exists for the parameter in the original document; if not, create an enum field and add the parameter value corresponding to the dictionary example_words to the enum field; if an enum key already exists for the parameter in the original document, compare the parameter value in the dictionary example_words with the enum field value to remove duplicates, and add the deduplication result to the enum field.

[0027] S1042. Save the modified original document as a new OpenAPI specification document;

[0028] S1043. Traverse the example_words dictionary and the fuzzy test dictionary, and check whether the example_words dictionary has the same key value as the fuzzy test dictionary, i.e., the corresponding parameter in the OpenAPI. If it does not exist, it means that the fuzzy test dictionary does not contain this parameter and the corresponding parameter value. Then add this parameter and the corresponding parameter value to the fuzzy test dictionary. If it exists, update the corresponding parameter value in the fuzzy test dictionary.

[0029] More preferably, step S2 specifically includes

[0030] S201. Parse the Kubernetes OpenAPI specification document, obtain each API operation request, and create a request template for each operation request that includes the request name and request parameters. The created request templates are stored in the req_list list for use in step S202. The parameter values ​​of the request parameters are replaced with placeholders, waiting to be rendered in step S203.

[0031] S202. Create a list `req_seqs` to store all current request sequences, initially empty; double-traverse `req_seqs` and `req_list` to obtain the current request sequence `seq` and all requests in the OpenAPI; determine if any request in the current request sequence has a producer-consumer dependency relationship with the currently selected request; if a dependency relationship exists, add the request `req` to the current request sequence to expand it into a new request sequence `new_seq`, and add it to `req_seqs`; finally, proceed to step S203 for rendering.

[0032] S203. Render the request template for each request sequence in req_seqs in order, and replace the parameter value placeholders in the request template with the actual values.

[0033] S204: Send the rendered request sequence, i.e. the test cases, to Kubernetes for testing and collect test responses.

[0034] More preferably, the rendering rule in step S203 is as follows: if the parameter value corresponding to the parameter has a default value in the OpenAPI documentation, i.e., the enum field, then the enum field is traversed for rendering; otherwise, the fuzzy dictionary is checked to see if the parameter exists. If it exists, the parameter value corresponding to the parameter is used for rendering; if neither exists, a random value is used for rendering.

[0035] The second aspect of this invention provides a dynamic fuzz testing system for security design of Kubernetes RESTful APIs, the system comprising a semantic information extraction module, a test case generation module, and a response filtering module;

[0036] The semantic information extraction module extracts semantic information from the OpenAPI specification document and test case responses based on NLP technology, and constructs a new OpenAPI specification document and fuzzy test dictionary based on the extracted semantic information.

[0037] The test case generation module parses the new OpenAPI specification document constructed by the semantic information extraction module, infers the dependencies between API operations, generates a test request sequence based on the dependencies, renders the test request sequence based on the fuzzy test dictionary constructed by the semantic information extraction module and the parameter information in the OpenAPI specification document, generates test cases, and sends them to the Kubernetes API Server component for testing.

[0038] The response filtering module collects all responses generated by test cases and then filters out responses with response codes 4xx and 5xx respectively. Responses with response codes 4xx are considered to contain semantic information and are sent to step S1 for further semantic information extraction. Responses with response codes 5xx are considered to have triggered an unexpected error in the Kubernetes API server and are considered bugs for error analysis.

[0039] Compared with the prior art, the beneficial technical effects of the present invention are as follows:

[0040] This invention implements dynamic fuzz testing for the security of Kubernetes RESTful API design through the construction of three sub-modules. It can uncover security issues in the design of Kubernetes RESTful API to a greater extent and test the security of Kubernetes clusters from the perspective of API design security. Attached Figure Description

[0041] Figure 1 This invention presents a dynamic fuzz testing framework diagram for security design of Kubernetes RESTful APIs. Detailed Implementation

[0042] The following are exemplary embodiments of the invention as defined by the claims and their equivalents, taken in conjunction with the accompanying drawings, to aid in a comprehensive understanding. The specific details described herein are to be considered exemplary only and not to limit the scope of the invention. Therefore, those skilled in the art can make various changes and modifications to the embodiments without departing from the scope and spirit of the invention.

[0043] Example 1

[0044] As a preferred embodiment of the present invention, this embodiment discloses a dynamic fuzzing method for security design of Kubernetes RESTful APIs, including the following steps:

[0045] S1. Extract semantic information from the OpenAPI specification document and test case responses based on NLP technology, and construct a new OpenAPI specification document and fuzzy test dictionary based on the extracted semantic information;

[0046] S2. By parsing the new OpenAPI specification document built in step S1, the dependencies between API operations are inferred, a test request sequence is generated based on the dependencies, the test request sequence is rendered based on the fuzzy test dictionary built in step S1 and the parameter information in the OpenAPI specification document, test cases are generated and sent to Kubernetes for testing.

[0047] S3. Collect all responses generated by test cases, and then filter out responses with response codes 4xx and 5xx respectively. Responses with response codes 4xx are considered to contain semantic information and are sent to step S1 for further semantic information extraction. Responses with response codes 5xx are considered to have triggered an unexpected error in the Kubernetes API server and are considered bugs for error analysis.

[0048] Example 2

[0049] As another preferred embodiment of the present invention, this embodiment is a further detailed preliminary explanation and description of the technical solution of the present invention based on the above embodiment 1. In this embodiment, step S1 specifically includes the following steps:

[0050] S101. Parse the Kubernetes OpenAPI specification document and extract the description field corresponding to all parameters in the specification document;

[0051] S102. If the test case response from step S3 is received, extract the message field from the test case response using the method described in step S101.

[0052] S103. Use CoreNLP functions to call the word-tokenize model, part-of-speech model, and dependency-parsing model to process the description and message fields, and then extract semantic information related to the parameters.

[0053] S104. Based on the semantic information extracted in step S103, dynamically update the Kubernetes OpenAPI specification document and fuzz test fields.

[0054] Furthermore, in step S101, the specific process of parsing the Kubernetes OpenAPI specification document is as follows: obtain the key-value pairs under the path field in each API operation of the Kubernetes OpenAPI specification document; if the key contains the parameters field, then iterate through and obtain the parameter values ​​of the name and description fields under the parameters field, and store them in the parameter_list and description_list lists respectively.

[0055] In step S103, semantic information is extracted from the description, specifically...

[0056] S1031. Using the parameter_list and description_list lists generated in step S101, iterate through the parameter_list and description_list lists, taking each parameter and description as input;

[0057] S1032. Use the word-tokenize model, part-of-speech model and dependency-parsing model to perform word segmentation, part-of-speech tagging and dependency parsing on the input description, and store the results in result_list;

[0058] S1033. Iterate through each word in result_list and try to match it with the specified parameter;

[0059] S1034. Iterate through each word in result_list and find all words related to the specified parameter.

[0060] Furthermore, in step S1032, each word is represented as a dictionary containing information such as id, text, pos, head, and deprel.

[0061] In a further preferred embodiment, in step S1033, if a matching word is found, its number is stored in the root_id variable.

[0062] In a further preferred embodiment, in step S1034, it checks whether the current word is a punctuation mark; if so, it skips the step. Otherwise, it determines whether the head of the current word is equal to the root_id; if so, it adds the text content of the word to the example_words dictionary. At the same time, it also determines whether the head of the word corresponding to the head of the current word is equal to the root_id; if so, it adds the text content of the word to the example_words dictionary. At this point, example_words represents the semantic information value corresponding to this parameter.

[0063] Furthermore, in step S104, dynamically updating the Kubernetes OpenAPI specification document specifically refers to...

[0064] S1041. Iterate through each API parameter in the original document. Check if an enum field exists for the parameter in the original document; if not, create an enum field and add the parameter value corresponding to the dictionary example_words to the enum field; if an enum key already exists for the parameter in the original document, compare the parameter value in the dictionary example_words with the enum field value to remove duplicates, and add the deduplication result to the enum field.

[0065] S1042. Save the modified original document as a new OpenAPI specification document;

[0066] S1043. Traverse the example_words dictionary and the fuzzy test dictionary, and check whether the example_words dictionary has the same key value as the fuzzy test dictionary, i.e., the corresponding parameter in the OpenAPI. If it does not exist, it means that the fuzzy test dictionary does not contain this parameter and the corresponding parameter value. Then add this parameter and the corresponding parameter value to the fuzzy test dictionary. If it exists, update the corresponding parameter value in the fuzzy test dictionary.

[0067] Example 3

[0068] As another preferred embodiment of the present invention, this embodiment is a further detailed supplement and explanation of the technical solution of the present invention based on the above-described embodiment 1 or embodiment 2. In this embodiment, step S2 specifically includes...

[0069] S201. Parse the Kubernetes OpenAPI specification document, obtain each API operation request, and create a request template for each operation request that includes the request name and request parameters. The created request templates are stored in the req_list list for use in step S202. The parameter values ​​of the request parameters are replaced with placeholders, waiting to be rendered in step S203.

[0070] S202. Create a list `req_seqs` to store all current request sequences, initially empty; double-traverse `req_seqs` and `req_list` to obtain the current request sequence `seq` and all requests in the OpenAPI; determine if any request in the current request sequence has a producer-consumer dependency relationship with the currently selected request; if a dependency relationship exists, add the request `req` to the current request sequence to expand it into a new request sequence `new_seq`, and add it to `req_seqs`; finally, proceed to step S203 for rendering.

[0071] S203. Render the request template for each request sequence in req_seqs in order, and replace the parameter value placeholders in the request template with the actual values.

[0072] S204: Send the rendered request sequence, i.e. the test cases, to Kubernetes for testing and collect test responses.

[0073] More preferably, the rendering rule in step S203 is as follows: if the parameter value corresponding to the parameter has a default value in the OpenAPI documentation, i.e., the enum field, then the enum field is traversed for rendering; otherwise, the fuzzy dictionary is checked to see if the parameter exists. If it exists, the parameter value corresponding to the parameter is used for rendering; if neither exists, a random value is used for rendering.

[0074] Example 4

[0075] As another preferred embodiment of the present invention, please refer to the appendix to the specification. Figure 1 As shown, dynamic fuzzing for the security of Kubernetes RESTful API designs requires consideration of both Kubernetes itself and user-defined rules—semantic checks. Therefore, the purpose of this invention is to propose a dynamic fuzzing scheme for the security of Kubernetes RESTful API designs. This scheme uses NLP technology to collect semantic information contained in the Kubernetes OpenAPI documentation and test responses, generating semantically consistent parameter values ​​for request sequences, thereby increasing the probability of discovering security issues in the Kubernetes API design.

[0076] Appendix Figure 1 The overall framework diagram of this invention is given. In the semantic information extraction module (1), semantic information is extracted from the responses generated by the OpenAPI specification document and test cases based on NLP technology. This semantic information will be used in the test case generation module (2) to build a new OpenAPI specification document and fuzzy dictionary to generate high-quality request sequence test cases. These test cases are then sent to the Kubernetes API Server component for testing, and the response messages are collected and analyzed. Finally, the detected errors are analyzed for bugs, and 4xx and 5xx responses are filtered out by the response filtering module (3). Responses with 4xx response codes are considered to contain semantic information and are sent to the semantic information extraction module to extract the semantic enhancements contained in the 4xx response messages for repeated use to generate higher-quality test cases; responses with 5xx response codes are considered to have triggered unexpected errors in the Kubernetes API server and are considered bugs for error analysis.

[0077] The specific steps are as follows:

[0078] Step 1: Semantic information extraction based on NLP.

[0079] Semantic information is extracted from the OpenAPI specification document and test case responses using NLP technology. Based on the extracted semantic information, a new OpenAPI specification document and fuzzy test dictionary are constructed. These are used for parameter generation in the test case module.

[0080] The specific execution process is as follows:

[0081] Step 1.1: Parse the Kubernetes OpenAPI specification document and extract the description field corresponding to all parameters in the specification document. The specific steps are as follows:

[0082] 1) Parse the Kubernetes OpenAPI specification file and obtain the key-value pairs under the path field for each API operation in the specification;

[0083] 2) If the key contains a parameters field, iterate through the parameters field to get the parameter values ​​of the name and description fields under the parameters field, and store them in the parameter_list and description_list lists respectively.

[0084] Step 1.2: If the test case response from Step 3 is received, extract the message field from the test case response using the method described in Step 1.1;

[0085] Step 1.3: Use CoreNLP functions to call the word-tokenize model, part-of-speech model, and dependency-parsing model to process the description and message fields, thereby extracting semantic information related to the parameters. The specific steps are as follows:

[0086] 1) Use the parameter_list and description_list generated in step 1.12. Then, iterate through parameter_list and description_list, taking each parameter and description as input.

[0087] 2) The input description is segmented, part-of-speech (POS) tagged, and dependency parsing is performed using the word-tokenize model, part-of-speech model, and dependency parsing model. The results are stored in result_list. Each word is represented as a dictionary containing information such as id, text, pos, head, and deprel.

[0088] 3) Iterate through each word in result_list and attempt to match it with the specified parameter. If a match is found, store its number in the root_id variable.

[0089] 4) Iterate through each word in `result_list` and find all words related to the specified parameter. Specifically, first check if the current word is a punctuation mark; if so, skip it. Otherwise, check if the `head` of the current word equals `root_id`; if so, add the text content of that word to the `example_words` dictionary. Simultaneously, it checks if the `head` of the word corresponding to the `head` of the current word equals `root_id`; if so, add the text content of that word to the `example_words` dictionary. At this point, `example_words` represents the semantic information value corresponding to this parameter.

[0090] Step 1.4: Based on the semantic information extracted in Step 1.3, dynamically update the Kubernetes OpenAPI specification document and fuzzy testing dictionary. The specific steps are as follows:

[0091] 1) Iterate through each API parameter in the original document. Check if an enum field exists for the parameter in the original document. If it does not exist, create an enum field and add the corresponding parameter value from the dictionary `example_words` to the enum field. If the parameter already has an enum key in the original document, compare the corresponding parameter value in the dictionary `example_words` with the enum field value to remove duplicates, and add the deduplicated result to the enum field.

[0092] 2) Save the modified original document as a new OpenAPI specification document.

[0093] 3) Iterate through the `example_words` dictionary and the fuzzy test dictionary, checking if the `example_words` dictionary has the same key value as the fuzzy test dictionary, i.e., the corresponding parameter in the OpenAPI. If it does not exist, it means the fuzzy test dictionary does not contain this parameter and its corresponding value, so add this parameter and its corresponding value to the fuzzy test dictionary. If it exists, update the corresponding parameter value in the fuzzy test dictionary.

[0094] Step 2: Generate test cases based on dependency inference.

[0095] Referring to Restler, the process first involves parsing the OpenAPI specification document to infer the dependencies between API operations. Based on these dependencies, a test request sequence is generated. Finally, the test request sequence is rendered using a fuzzy testing dictionary and parameter information from the OpenAPI specification document, generating test cases and sending them to Kubernetes for testing. The specific steps are as follows:

[0096] 1) Parse the Kubernetes OpenAPI specification document to obtain each API operation request, and create a request template for each operation request, containing the request name and request parameters. These request templates are stored in the `req_list` list for use in step 2). The parameter values ​​are replaced with placeholders, awaiting rendering in step 3).

[0097] 2) Create a list `req_seqs` to store all current request sequences, initially empty. Double-traverse `req_seqs` and `req_list` to retrieve the current request sequence `seq` and all requests in the OpenAPI. Determine if any request in the current request sequence has a producer-consumer dependency relationship with the currently selected request. If a dependency exists, add the request `req` to the current request sequence to expand it into a new request sequence `new_seq`, and add it to `req_seqs`. Finally, proceed to step 3) for rendering.

[0098] 3) Render the request templates for each request sequence in `req_seqs` sequentially, replacing the placeholder parameter values ​​in the request templates with actual values. Rendering follows these rules: If the parameter value has a default value in the OpenAPI documentation (i.e., an `enum` field), iterate through the `enum` field for rendering. Otherwise, check if the parameter exists in the fuzzy dictionary; if it does, use its corresponding value for rendering. If neither exists, use a random value for rendering.

[0099] 4) Send the rendered request sequence, i.e. the test cases, to Kubernetes for testing and collect test responses.

[0100] Step 3: Test response filtering

[0101] First, collect all responses generated by the test cases, then filter out responses with 4xx and 5xx response codes. Responses with 4xx response codes are considered to contain semantic information and will be sent to step 1 for semantic information extraction. Responses with 5xx response codes are considered to have triggered unexpected errors on the Kubernetes API server and will be considered bugs for error analysis.

[0102] Although the inventive concept has been specifically shown and described with reference to exemplary embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the claims.

Claims

1. A dynamic fuzzing method for security design of Kubernetes RESTful APIs, characterized by: Includes the following steps, S1. Extract semantic information from the OpenAPI specification document and test case responses based on NLP technology, and construct a new OpenAPI specification document and fuzzy test dictionary based on the extracted semantic information; S2. By parsing the new OpenAPI specification document built in step S1, the dependencies between API operations are inferred, a test request sequence is generated based on the dependencies, the test request sequence is rendered based on the fuzzy test dictionary built in step S1 and the parameter information in the OpenAPI specification document, test cases are generated and sent to Kubernetes for testing. S3. Collect all responses generated by test cases, and then filter out responses with response codes 4xx and 5xx respectively. Responses with response codes 4xx are considered to contain semantic information and are sent to step S1 for further semantic information extraction. Responses with response codes 5xx are considered to have triggered an unexpected error in the Kubernetes API server and are considered bugs for error analysis.

2. The dynamic fuzzing method for security design of Kubernetes RESTful APIs as described in claim 1, characterized in that: Step S1 specifically includes the following steps: S101. Parse the Kubernetes OpenAPI specification document and extract the description field corresponding to all parameters in the specification document; S102. If the test case response from step S3 is received, extract the message field from the test case response using the method described in step S101. S103. Use CoreNLP functions to call the word-tokenize model, part-of-speech model, and dependency-parsing model to process the description and message fields, and then extract semantic information related to the parameters. S104. Based on the semantic information extracted in step S103, dynamically update the Kubernetes OpenAPI specification document and fuzz test fields.

3. The dynamic fuzzing method for security design of Kubernetes RESTful APIs as described in claim 2, characterized in that: In step S101, the specific process of parsing the Kubernetes OpenAPI specification document is as follows: obtain the key-value pairs under the path field in each API operation of the Kubernetes OpenAPI specification document; if the key contains the parameters field, then iterate through and obtain the parameter values ​​of the name and description fields under the parameters field, and store them in the parameter_list and description_list lists respectively.

4. The dynamic fuzzing method for security design of Kubernetes RESTful APIs as described in claim 3, characterized in that: In step S103, semantic information is extracted from the description, specifically... S1031. Using the parameter_list and description_list lists generated in step S101, iterate through the parameter_list and description_list lists, taking each parameter and description as input; S1032. Use the word-tokenize model, part-of-speech model and dependency-parsing model to perform word segmentation, part-of-speech tagging and dependency parsing on the input description, and store the results in result_list; S1033. Iterate through each word in result_list and try to match it with the specified parameter; S1034. Iterate through each word in result_list and find all words related to the specified parameter.

5. The dynamic fuzzing method for security design of Kubernetes RESTful APIs as described in claim 4, characterized in that: In step S1032, each word is represented as a dictionary containing id, text, pos, head, and deprel information.

6. A dynamic fuzzing method for security design of Kubernetes RESTful APIs as described in claim 4 or 5, characterized in that: In step S1033, if a matching word is found, its number is stored in the root_id variable.

7. A dynamic fuzzing method for security design of Kubernetes RESTful APIs as described in claim 6, characterized in that: In step S1034, it checks whether the current word is a punctuation mark. If it is, it skips the step. Otherwise, it checks whether the head of the current word is equal to the root_id. If it is, it adds the text content of the word to the example_words dictionary. At the same time, it also checks whether the head of the word corresponding to the head of the current word is equal to the root_id. If it is, it adds the text content of the word to the example_words dictionary. At this time, example_words represents the semantic information value corresponding to this parameter.

8. A dynamic fuzzing method for security design of Kubernetes RESTful APIs as described in any one of claims 2-5, characterized in that: In step S104, dynamically updating the Kubernetes OpenAPI specification document specifically refers to... S1041. Iterate through each API parameter in the original document and check if the parameter in the original document has an enum field. If it does not exist, create an enum field and add the parameter value corresponding to the dictionary example_words to the enum field. If the parameter in the original document already has an enum key, compare the parameter value in the dictionary example_words with the enum field value to remove duplicates and add the deduplication result to the enum field. S1042. Save the modified original document as a new OpenAPI specification document; S1043. Traverse the example_words dictionary and the fuzzy test dictionary, and check whether the example_words dictionary has the same key value as the fuzzy test dictionary, i.e., the corresponding parameter in the OpenAPI. If it does not exist, it means that the fuzzy test dictionary does not contain this parameter and the corresponding parameter value. Then add this parameter and the corresponding parameter value to the fuzzy test dictionary. If it exists, update the corresponding parameter value in the fuzzy test dictionary.

9. A dynamic fuzz testing system for security design of Kubernetes RESTful APIs, characterized in that: It includes a semantic information extraction module, a test case generation module, and a response filtering module; The semantic information extraction module extracts semantic information from the OpenAPI specification document and test case responses based on NLP technology, and constructs a new OpenAPI specification document and fuzzy test dictionary based on the extracted semantic information. The test case generation module parses the new OpenAPI specification document constructed by the semantic information extraction module, infers the dependencies between API operations, generates a test request sequence based on the dependencies, renders the test request sequence based on the fuzzy test dictionary constructed by the semantic information extraction module and the parameter information in the OpenAPI specification document, generates test cases, and sends them to the Kubernetes API Server component for testing. The response filtering module collects all responses generated by test cases and then filters out responses with response codes 4xx and 5xx respectively. Responses with response codes 4xx are considered to contain semantic information and are sent to step S1 for further semantic information extraction. Responses with response codes 5xx are considered to have triggered an unexpected error in the Kubernetes API server and are considered bugs for error analysis.

Images