Cloud native security configuration system and method based on container analysis and LLM

Abstract

The invention discloses a cloud native security configuration system and method based on container analysis and LLM, and the system comprises a mirror image static analysis module which is used for compiling a Linux kernel and a standard library source code to extract intermediate representation, and tracking and constructing a double-layer mapping relation library from the system call to the container capability; the dynamic binary extraction module is used for executing the container mirror image and extracting a binary file of a core function; the mirror image static and dynamic association module is used for executing two-stage static binary file analysis and extracting function requirements required by system calling and mirror image for loading during container running; and the cue word construction and model fine adjustment module is used for constructing cue words, performing fine adjustment on the LLM model and generating a minimum privilege function limitation configuration file of the container. According to the method, static analysis and runtime analysis are combined, the container mirror image is thoroughly checked, the function, which is specified by a user and exceeds the original definition of the mirror image, of the LLM model is finely adjusted through the cue word, and privileged function security configuration is generated according to specific requirements.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer operation and maintenance, and particularly relates to a cloud native security configuration system and method based on container analysis and LLM. BACKGROUND

[0002] Over the past decade, cloud native applications have experienced steady and significant growth, becoming a key method for software delivery and operation. These applications are usually deployed in containers, which help to create computing infrastructure with well-defined life cycles, including deployment, scaling, and updating. Despite quality control, running third-party container images poses a significant security risk. According to AquaSecurity, the number of cloud native attacks has been increasing dramatically, and the corresponding system deployment cost has also increased significantly. Containers share the host operating system kernel, making them vulnerable to the same kernel-level vulnerability attacks. Issues such as unrestricted resource access, container separation technology, data separation challenges, and sharing management API with containers further exacerbate security problems, making containerized environments more vulnerable to attacks. Therefore, limiting the behavior of containers carefully designed by unknown parties has become a key but challenging requirement.

[0003] Currently, DevOps engineers may use third-party Docker images as monitoring tools. When the container fails to initialize the network interface, they search online and encounter suggestions to use a unique flag. Although these suggestions are usually well-intentioned, they grant full access to host resources, including mounting file systems and modifying kernel parameters, which completely destroys container isolation. Although this can restore functionality, it exposes the host to serious privilege escalation risks in the event of a compromised container. In order to ensure the successful execution of containers, more and more people tend to grant privileges to containers, which is evident in forum documents and responses on popular platforms such as Stackoverflow.com, where incorrect solutions are often mistaken for best practices. Therefore, the automation of privilege configuration to ensure secure and accurate privilege allocation has become a problem to be solved.

[0004] Code-based static analysis tools and test-based dynamic analysis tools are recognized tools for assessing the privileged functions of containers. For example, Docker container security in cloud computing proposes a continuous integration and continuous deployment (CI / CD) system that verifies the security of Docker images throughout the software development life cycle. This approach emphasizes the development specifications of developers and emphasizes container security during the development code cycle, but if the image base used for code development itself has security risks, it is obviously impossible to detect. For another example, A fine-grained and path-sensitive linux capability analysis framework proposes a fine-grained and path-sensitive code flow analysis based on the underlying virtual machine (LLVM) to build an accurate mapping between system calls and their functions. In particular, it solves the constraint equations on each path from a given system call to a single capability and strategically overcomes the path explosion problem. Although using LLVM-based code flow analysis to statically infer functions, it is difficult to deal with operational complexity in cloud-native systems and cannot find problems with the image itself. The above methods only emphasize that the user writes code and restricts system calls, obviously ignoring the complexity of the image itself.

[0005] Based on this problem, Decap: Deprivileging Programs by Reducing Their Capabilities proposes a binary code analysis tool that automatically deprives programs by identifying the subset of functions required by the program according to the system calls that the program can call. It is more complete at the analysis level, but ignores dynamic workflows and auxiliary needs, and not all privileged needs can be directly derived from container images, and users may need functions beyond the scope of image support.

[0006] Therefore, considering the limitations of existing code and test-based methods, how to automate the privilege configuration based on Linux functions and improve the identification of container privileged functions is a problem that needs to be solved in cloud-native security configuration. SUMMARY

[0007] To solve the above technical problems, the present application provides a cloud-native security configuration system and method based on container analysis and LLM, which completely checks the container image by combining static analysis and runtime analysis. When the function beyond the original design of the image is needed, LLM is used to identify the necessary functions specified by the user, and the privilege configuration based on Linux functions is automated.

[0008] To achieve the above object, the embodiment provides a cloud-native security configuration system based on container analysis and LLM, which comprises: An image static analysis module is configured to compile Linux kernel and standard library source code and extract intermediate representation, and track mapping relationship between system calls and container functions through the intermediate representation. A dynamic binary extraction module is configured to execute the container image and extract binary files involved in the execution of the container image. An image static and dynamic association module is configured to perform two-stage static binary file analysis based on the mapping relationship between system calls and container functions, extract system calls in the extracted binary files in the first stage, and extract container function requirements required by the image based on the flag of the system calls for the container runtime to load in the second stage. A prompt word construction and model fine-tuning module is configured to crawl container capability configuration documents from a cloud-native security configuration file website and filter them, use prompt word engineering to optimize container function prediction tasks required by the image to construct a fine-tuning model, and generate a minimum privilege function restriction configuration file of the container.

[0009] In one embodiment, the image static analysis module specifically comprises: compiling Linux kernel and glibc function source code and extracting intermediate representation, tracking and establishing a first mapping relationship between glibc functions and system calls, and a second mapping relationship between system calls and container functions through the intermediate representation.

[0010] In one embodiment, the execution of the container image and the extraction of the binary files involved in the execution of the container image comprise: executing the container image and monitoring the runtime process, verifying that the runtime process is free of errors, and extracting core binary files for I / O and process control performed in the execution of the container image.

[0011] In one embodiment, the dynamic binary extraction module further comprises: a script file in a non-ELF format is converted into a relocatable binary file using a compiling tool and extracted.

[0012] In one embodiment, the first stage based on the extraction of system calls in the extracted binary files comprises: A privileged function list is constructed based on glibc functions used by the binary file, the privileged functions of the system calls in the privileged function list are checked and marked as non-privileged calls, non-privileged mapping items are filtered out, the complete functions of the binary file that can be used are obtained, the final system call set used in the binary file is inferred using the first mapping relationship between glibc functions and system calls, and standard library function analysis is completed.

[0013] In one embodiment, the second stage extracts the Linux capability requirements required by the image based on the flags of the system call, including: extracting the hexadecimal value of the flag in the binary file, determining the system call corresponding to the hexadecimal value and the container function required when using the flag, disassembling the binary file, checking the parameters passed to the system call, and extracting the container function requirements required by the image for the container runtime to load.

[0014] In one embodiment, the container capability configuration document is crawled from the cloud native security profile website and filtered, including: crawling the container capability configuration document from the cloud native security profile website StackOverflow, StackExchange and ServerFault, the answer of the container capability configuration document relates to a specific Linux function, collecting documents related to the container Docker problem, filtering each collected document according to the filtering standard, and building a dataset; The filtering standard includes: excluding documents related to the relevant function in the answer with low ranking or not accepted; Excluding recommended configurations including multiple functions, documents containing unique keyword content not suitable for isolating the function of interest; Excluding documents that mention the function of interest.

[0015] In one embodiment, the function prediction task required by the image is optimized using the prompt engineering, including: using the prompt engineering to model the relevance of the problem to the function configuration problem in the Linux container, guiding the Linux function prediction model to narrow down the analysis range to the Linux function field, and the problem result is to avoid the security risk of enabling all functions by only specifying the required function, and to realize the optimization of the function prediction task required by the image.

[0016] In one embodiment, the fine-tuning model is built, including: building a dynamic training set containing container capability configuration documents and filtered question and answer samples, using a ternary structure of system role fixation, user question input and assistant capability label for LLM model training, injecting a ternary structure in the training stage to establish accurate mapping, and stripping the assistant capability label in the prediction stage to enable the LLM model to output the capability label autonomously, and completing the fine-tuning model construction.

[0017] In another aspect, the application also provides a cloud native security configuration method based on container analysis and LLM, which adopts the cloud native security configuration system based on container analysis and LLM, and includes the following steps: Compiling the Linux kernel and standard library source code and extracting the intermediate representation, tracking the mapping relationship between system calls and container functions through the intermediate representation; Execute the container image, verify that the runtime process is error-free, and extract the core binary involved in executing the container image; Perform two-stage static binary file analysis based on the mapping relationship between system calls and container functions, the first stage extracts system calls from the extracted binary file, and the second stage extracts the required container function requirements of the image based on the flags of the system calls for container runtime loading; Crawl the container capability configuration document from the cloud native security configuration file website and filter it, use the prompt word engineering to optimize the fine-tuning model for the container function prediction task required by the image, and generate the minimum privilege function restriction configuration file of the container.

[0018] Compared with the prior art, the present application has at least the following beneficial effects: (1) By analyzing the Linux kernel and standard library function source code and binary extraction analysis, the complete system call view of the container can be obtained.

[0019] (2) Through system call analysis and flag analysis passed to the system call, the accurate prediction of the container function privilege is realized.

[0020] (3) Use the prompt word engineering to optimize the fine-tuning model for the function prediction task required by the image, combine with the LLM model, identify the privileged functions required by the user beyond the original definition of the image, realize the minimum privilege configuration of the container in the cloud native environment, and improve the security; (4) The static analysis of the container image shows that the accuracy of assigning correct functions without excessive privileges is 93.3%, and the fine-tuning method based on the LLM model realizes the accuracy of GPT86.7% and Command-R 85.6% in the prediction ability. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows.

[0022] Figure 1 is the structure diagram of the cloud native security configuration system based on container analysis and LLM provided by the present application.

[0023] Figure 2 is the Linux kernel and standard library function source code analysis flowchart provided by the present application.

[0024] Figure 3 is the first stage flowchart of static binary file analysis.

[0025] Figure 4 is the second stage flowchart of static binary file analysis. is the second stage flowchart of static binary file analysis.

[0026] Figure 5 A specific flowchart of the cloud-native security configuration method based on container analysis and LLM provided by the present application is provided.

[0027] Figure 6 A specific flowchart of the cloud-native security configuration method based on container analysis and LLM provided by the present application is provided. DETAILED DESCRIPTION

[0028] In order to make the objects, technical solutions and advantages of the present application clearer, the following further describes the present application in detail with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and do not limit the protection scope of the present application.

[0029] In order to automate the privilege configuration based on Linux functions, the present solution combines static and runtime analysis to thoroughly examine the container image. In addition, when the functions beyond the original design of the image are needed, the LLM model is used to identify the necessary functions specified by the user.

[0030] As Figure 1 shown is a structural schematic diagram of the cloud-native security configuration system based on container analysis and LLM provided by the present application, which comprises an image static analysis module, a dynamic binary extraction module, an image static and dynamic correlation module, and a prompt word construction and model fine-tuning module.

[0031] Image static analysis module: Since the implementation of function calls occurs in the Linux kernel, accurate configuration requires precise analysis of the implementation location of functions in the Linux kernel. Containers make requests to the Linux kernel through system calls to demonstrate their behavior, and system calls are usually implemented in standard library glibc functions. By analyzing the Linux kernel source code, the mapping between system calls and functions is extracted. For glibc functions, analyze the function calls that lead to system calls.

[0032] Specifically, as Figure 2 shown, the Linux kernel and glibc function source code are compiled, the intermediate representation (IR) is extracted from the Linux kernel source code for analysis, and the first mapping relationship between system calls (syscalls) and container privileged functions is obtained through intermediate representation analysis and code analysis. The IR is extracted from the glibc function source code, and the second mapping relationship between glibc functions and system calls is generated through IR analysis.

[0033] Dynamic binary extraction module: Using runtime analysis of binary extraction, runtime analysis is crucial to determine the specific binaries involved when executing the container image. Many binaries packaged in the container image (e.g. standard operating system tools) do not play a role in the main functionality of the container, so they do not need to be analyzed to extract functionality. To narrow the scope and only target responsible binaries, the container image is launched, verified that the runtime processes are error-free, and only those binaries actively involved in implementing the application functionality are extracted. Meanwhile, the container image can contain components that run differently, so an AoT compilation tool like GraalVM is used to convert applications (like Java, Python, JavaScript, and Ruby) into ELF executable files as just-in-time binaries and extract them.

[0034] Image static and dynamic association module: Next, binary analysis is performed, after extracting the mapping through the above two ways, static analysis is performed. The first stage focuses on extracting system calls from the extracted binaries, and the second stage extracts the functions required by the image, according to the flags passed to the system call to determine whether to include certain functions.

[0035] Specifically, as Figure 3 The first stage of static binary analysis is shown in the flowchart, the first stage focuses on extracting system calls from the extracted binaries, and the binary files need system calls to interact with the operating system and perform I / O, memory management, and process control operations, which are usually subject to access restrictions for security and stability. The use of a symbol resolver is used to obtain calls to glibc functions from the binary file, combined with the mapping of glibc functions to system calls, to obtain the system calls used by the binary file.

[0036] A privileged function list is built from the glibc functions used in the binary, which is able to check if the function is using a privileged functionality of the system call. For example, the getrlimit library call maps to the prlimit64 system call, according to the documentation, getlimit is only used to retrieve the current limit of various resources. Although it is associated with a seemingly privileged system call (mapped to the CAP_SYS_RESOURCE capability), it does not usually involve privileged functionality that would affect the system in a standard scenario. The privileged function list is built by analyzing the documentation of the glibc functions, assuming there are 13,634 mapping items between glibc functions and system calls, it is impractical to perform code analysis on each item as in the previous step. Therefore, focus is on building the privileged function list directly from the glibc functions. Among the 1,702 functions that map to system calls, their corresponding documentation is viewed and the relevant functions are added to the privileged function list accordingly, and the marking of privileged functionality and non-privileged calls in the privileged function list is completed. Then, the final set of system calls used in the binary is inferred using the mapping of glibc functions to system calls, and the standard library function analysis is completed.

[0037] As shown in Figure 4 is a flowchart of the second phase of static binary analysis, which will extract the required capabilities for the image. Some capabilities are included or excluded depending on the flags passed to the system calls. For example, in the Linux source code, the CAP_NET_ADMIN capability is required if the SO_DEBUG flag is passed to the setsockopt system call. It is simple to extract the constant value of this flag, as it is defined in the Linux kernel. Specifically, the hexadecimal value of the flag is extracted, it is determined which system call the hexadecimal value of the flag corresponds to, and it is determined whether a capability is required when the flag is used. Then, the binary is disassembled to obtain the parameters of the system call, which are filtered by flag analysis, combined with the mapping of system calls to capability privileges, and the parameters passed to the system call are checked to obtain the privileged capabilities of the binary, which are finally summarized in the configuration file of the container to which the binary belongs, and the required capabilities for the image are extracted for the container runtime to load.

[0038] Prompt word construction and model fine-tuning module: First, build a dataset, specifically by collecting container capability configuration documents from cloud native security configuration file websites StackOverflow, StackExchange, and ServerFault, in which the answers mention specific Linux capabilities, and then query documents specifically related to container Docker issues. The capabilities mentioned in the answers of each container capability configuration document are used as the label of that sample in the dataset. Each container capability configuration document collected will be further evaluated according to specific exclusion criteria to ensure that only the most trusted and accurate answers from cloud native security configuration file websites are included. The filtering criteria are as follows: (a) Excluded are those documents that only mention the relevant capabilities in lower-ranked, non-accepted answers, as these documents lack sufficient crowd-sourced support. Similarly, if a document has only one answer with a score lower than 1, the document will be discarded due to uncertainty about the reliability of the answer.

[0039] (2) If the recommended configuration includes multiple features, the document may contain content that is not suitable for isolating the unique keyword of the feature of interest.

[0040] (3) If the question already mentions the feature of interest, the document will be excluded, as this indicates that the question may not be related to the missing feature. In this case, the user has specified the relevant feature, which indicates that the problem lies elsewhere.

[0041] Next, use prompt engineering to explicitly emphasize that the question is related to the configuration of the feature in Linux containers, guiding the Linux feature prediction model to narrow its analysis range to the Linux feature field. The result of the question is to avoid the security risk of enabling all features by only specifying the required features, achieving the optimization of the required feature prediction task of the image. The range of prompt words may range from the general "I have a computer problem: <problem description>" to the more specific "I have a Docker problem: <problem description>". In the embodiment, it is necessary to specifically guide the LLM to handle the capability problem. The prompt word works as an assistant for the LLM model to predict Linux capabilities.

[0042] Next, build a fine-tuned model, which divides the built dataset into two different parts: one for fine-tuning and the other for evaluating the performance of the fine-tuned model.

[0043] All relevant capability documents are included in the training set, and filtered data samples are randomly selected to fill the capability documents. This method allows the model to learn from documents and some question-answer pairs, thereby enhancing its ability to effectively handle frequent scenarios. To fine-tune, the API of the LLM model is utilized and each training message is modeled as a three-part role. In GPT, these roles are: system, user, and assistant. The "system" role defines the overall purpose of the interaction, and the system role remains unchanged in all training examples, with a value of: "You are an assistant to predict Linux capabilities." This will guide the LLM model to focus on the specific task of capability prediction, thereby expanding its scope. The "user" role represents the input, corresponding to the actual user query, which is usually extracted from the document or actual tutorial document. These inputs include the title and body of the article, simulating the natural interaction of the user when configuring container capabilities. The "assistant" role is the expected output, representing the precise Linux capability required for a given user prompt (such as CAP_NET_ADMIN). During the training phase, the injection of the three-part structure establishes a precise mapping to provide reference answers to the model, guiding the expected behavior of the LLM model. The assistant role serves as the ground truth during fine-tuning, allowing the model to learn the correct association between user queries and their corresponding capabilities. Once the model is trained, the "assistant" role is removed from the test dataset. In the testing phase, the fine-tuned model predicts the appropriate privilege capabilities based solely on the user-provided input, generating a minimum privilege capability restriction configuration file for the container, avoiding the risk of container overreach.

[0044] In another aspect, the embodiment also provides a container analysis and LLM-based cloud-native security configuration method, as shown in Figure 6 The container analysis and LLM-based cloud-native security configuration method employs the container analysis and LLM-based cloud-native security configuration system, including the following steps: Compiling the Linux kernel and standard library function source code and extracting the intermediate representation, tracking the mapping relationship between system calls and container capabilities through the intermediate representation; Executing the container image, verifying that there are no errors in the runtime process, and extracting the core binary files involved in executing the container image; Performing two-stage static binary file analysis based on the first mapping relationship and the second mapping relationship, the first stage extracting system calls from the extracted binary files, and the second stage extracting the required functionality of the image based on the flags of the system calls for container runtime loading; Crawling container capability configuration documents from a cloud-native security configuration file website and filtering them, using prompt word engineering to optimize the functionality prediction task required by the image, building a fine-tuning model for optimizing functionality prediction, and generating a minimum privilege capability restriction configuration file for the container.

[0045] The above detailed description of the specific embodiments of the present application has described the technical solutions and beneficial effects of the present application, and it should be understood that the above description is only the most preferred embodiment of the present application and is not intended to limit the present application. Any modifications, supplements and equivalent replacements made within the principle range of the present application shall be included in the protection range of the present application.

Claims

1. A cloud native security configuration system based on container analysis and LLM, characterized by: include: Image static analysis module, used to compile the Linux kernel and standard library source code and extract intermediate representations, and use the intermediate representations to track the mapping between system calls and container functions; Dynamic binary extraction module, used to execute container images and extract the binary files involved in executing container images; The image static and dynamic association module is used to perform a two-stage static binary file analysis based on the mapping relationship between system calls and container functions. The first stage extracts the system calls based on the extracted binary files. The second stage extracts the container function requirements required by the image based on the system call flags for loading at the container runtime. The prompt word building and model fine-tuning module is used to crawl and filter container capability configuration documents from the cloud native security profile website, use prompt word engineering to optimize the container function prediction tasks required for the image, build a fine-tuning model, and generate a minimum privilege function restriction profile for the container.

2. The cloud native security configuration system according to claim 1, characterized in that: The image static analysis module specifically includes: compiling the Linux kernel and glibc function source code and extracting the intermediate representation, and establishing a first mapping relationship from glibc functions to system calls and a second mapping relationship from system calls to container functions through intermediate representation tracking.

3. The cloud native security configuration system according to claim 1, characterized in that: The executing container image and extracting the binary files involved in executing the container image include: executing the container image and monitoring the runtime process, verifying that there are no errors in the runtime process, and extracting the core binary files of I / O and process control performed when executing the container image.

4. The cloud native security configuration system according to claim 1, characterized in that: The dynamic binary extraction module further comprises: for converting a script file in a non-ELF format into an adjustable binary file using a compilation tool and extracting the script file.

5. The cloud native security configuration system according to claim 2, characterized in that: The first stage extracts system calls based on the extracted binary files, including: Based on the glibc functions used by the binary file, a privileged function list is built. The privileged functions of the system calls in the privileged function list are checked and non-privileged calls are marked. The non-privileged mapping items are filtered out to obtain all the privileged functions that the binary file may use. The first mapping relationship from glibc functions to system calls is used to infer the final system call set used in the binary file, completing the standard library function analysis.

6. The cloud native security configuration system according to claim 5, characterized in that: The second stage extracts the Linux capability requirements required for the image based on the system call flag, including: extracting the hexadecimal value of the flag in the binary file, determining the system call corresponding to the hexadecimal value and the container function required when using the flag, then disassembling the binary file, checking the parameters passed to the system call, and extracting the container function requirements required by the image for loading when the container is running.

7. The cloud native security configuration system according to claim 1, wherein the step of crawling and filtering container capability configuration documents from a cloud native security configuration file website comprises: We collected container capability configuration documents from cloud native security profile websites such as StackOverflow, StackExchange, and ServerFault. The answers to these documents involved specific Linux functions. We then collected documents related to container Docker issues and filtered each collected document according to the filtering criteria to construct a dataset. The filtering criteria include: excluding documents involving related functions in answers with lower rankings or unaccepted answers; Excluding recommended configurations includes multiple features, documents containing unique keyword content that is not suitable for isolating the features of interest; Troubleshooting issues already mentioned in the documentation for the function of interest.

8. The cloud native security configuration system according to claim 1, characterized in that: The use of prompt word engineering to optimize the function prediction task required for the image includes: using the prompt word engineering modeling problem and the correlation between the function configuration problem in the Linux container to guide the Linux function prediction model to narrow the analysis scope to the Linux function field. The problem result is to avoid the security risk of enabling all functions by specifying only the required functions, thereby achieving the optimization of the function prediction task required for the image.

9. The cloud native security configuration system according to claim 1, characterized in that: The construction of the fine-tuning model includes: constructing a dynamic training set including container capability configuration documents and filtered question and answer samples, adopting a ternary structure of fixed system role, user question input, and assistant capability label to train the LLM model, injecting the ternary structure to establish precise mapping during the training phase, stripping the assistant capability label during the prediction phase so that the LLM model can autonomously output the capability label, and completing the construction of the fine-tuning model.

10. A cloud native security configuration method based on container analysis and LLM, characterized in that: The cloud native security configuration method adopts the cloud native security configuration system based on container analysis and LLM according to any one of claims 1 to 9, comprising the following steps: Compile the Linux kernel and standard library function source code and extract the intermediate representation. Use the intermediate representation to track the mapping between system calls and container functions. Execute the container image, verify that the runtime process is error-free, and extract the core binaries involved in executing the container image; Based on the first mapping relationship and the second mapping relationship, a two-stage static binary file analysis is performed. In the first stage, system calls are extracted from the extracted binary files. In the second stage, functional requirements of the image are extracted based on the flags of the system calls for loading at the container runtime. We crawled and filtered container capability configuration documents from the cloud-native security profile website, optimized the function prediction tasks required for the image using prompt word engineering, built a fine-tuning model to optimize function prediction, and generated a minimum privilege function restriction profile for the container.

Images