Kubernetes privilege extraction attack method, system and device based on implicit privilege analysis and utilization and medium

Abstract

The invention relates to a Kubernetes privilege extraction attack method, system, equipment and medium based on implicit privilege analysis and utilization, and the method comprises the following steps: statically analyzing and identifying various resources supported in a Kubernetes cluster through a resource identification module based on resource registration and collection, which comprise a main resource and sub-resources associated with the main resource; static analysis of resource performance functions is carried out on the obtained main resources and sub-resources, and various explicit permissions supported by the Kubernetes resources are obtained; implicit permission mappings implicit under various explicit permissions are obtained through semantic analysis, so that all final implicit permission mappings in the explicit permissions are obtained; based on the method, the system, the device and the medium analyze the security of the Kubernetes from multiple angles to more comprehensively understand and enhance the protection capability of the Kubernetes cluster, so that the security of the cloud native application is improved, potential threats are resisted, and potential attack risks are reduced.

Description

Technical Field

[0001] The present invention belongs to the technical field of network attack protection, and specifically relates to a Kubernetes privilege escalation attack method, system, device and medium based on implicit permission analysis and utilization. Background Art

[0002] Kubernetes is an open-source container orchestration platform for automating the deployment, scaling, and management of containerized applications. A Kubernetes cluster consists of a control plane and a data plane [KubernetesAuthors.2023.Control Plane.https: / / kubernetes.io / docs / reference / glossary / ? all=true#term-control-plane.]. The control plane is responsible for managing the entire cluster lifecycle, scheduling workloads, and ensuring the cluster's state meets user expectations. It runs on the Master node (also known as the control node). Its primary tasks include receiving user requests, scheduling pods to specific nodes, monitoring cluster status, and coordinating resource allocation. The control plane consists of four core components: the API Server, etcd, the Scheduler, and the Controller Manager. The data plane, the part of Kubernetes responsible for actual execution, directly runs user containerized applications and handles application-related network and storage operations. The data plane primarily consists of components on the Worker nodes, including the kubelet, kube-proxy, and the container runtime.

[0003] In Kubernetes, resources are the core concept used to describe and manage various objects in the cluster, representing all operational entities in the Kubernetes system. Resources can be physical or logical objects in the cluster, such as nodes, containers, network configurations, and storage volumes, or they can be abstract runtime logic, such as workloads and service discovery configurations. Through resources, Kubernetes implements declarative management, allowing users to define the desired state, and Kubernetes automatically adjusts the actual state to the desired state through controllers. Resources essentially exist in the form of API objects, and all resources are exposed and managed through the Kubernetes API Server. Each resource has its own specific purpose and function, and is defined and configured through YAML / JSON files. Common resource types include workload resources such as Pod, Deployment, and StatefulSet for running applications; configuration resources such as Node, Namespace, and ConfigMap for system management; and Service and Ingress for service discovery.

[0004] The management and operation permissions of resources require refined control to ensure the security of the cluster and isolation in a multi-user environment. This permission management mechanism is implemented by Kubernetes' RBAC. RBAC is the core mechanism for controlling resource access in Kubernetes. By assigning roles to users, groups or service accounts, the scope and type of their operations on resources are limited. The core idea of ​​RBAC is role-based permission management. Specifically, users cannot directly operate resources in Kubernetes, but obtain permissions indirectly through roles (Role or ClusterRole). Roles define which operations (such as read, write, and delete) can be performed on which resources (such as Pod, Deployment, and Service). These permissions are associated with specific users or service accounts through binding (RoleBinding or ClusterRoleBinding), thereby achieving precise access control. Therefore, by creating resources related to RBAC, corresponding permissions can be assigned to target accounts and components, that is, the target is authorized to access the corresponding resources. In the present invention, the permission that RBAC directly grants to different accounts and application components to perform specified operations on resources is called explicit permissions. Furthermore, due to the complex interdependencies between resources and operations within a Kubernetes cluster, these permissions can indirectly affect the state of other resources. This effect can be equated to granting permissions for specific operations on other resources, which we refer to as implicit permissions. Implicit permissions allow operations on resources without explicit authorization. Therefore, implicit permissions can introduce potential security risks to Kubernetes clusters.

[0005] Existing technical solutions: Various attack surfaces have been proposed to address security threats in Kubernetes clusters. Previously, Sushring et al. proposed an attack method that attempted to launch a co-residency attack by running malicious containers on the same physical machine in a Kubernetes cluster [Sushrut Shringarputale, Patrick McDaniel, Kevin Butler, and Thomas La Porta. 2020. Co-residency attacks on containers are real. In Proceedings of the 2020 ACM SIGSAC Conference on Cloud Computing Security Workshop. 53–66.]. This method aims to exploit the kernel and resources of shared physical machines to steal sensitive information from other containers or disrupt their normal operation. Ronen et al. proposed a DoS attack in a Kubernetes cluster. [Ronen Ben David and Anat Bremler Barr. 2021. Kubernetes Autoscaling: YoYoAttack Vulnerability and Mitigation. arXiv e-prints (2021), arXiv–2105.], a new type of denial-of-service attack that exploits the Kubernetes autoscaling mechanism through periodic, sudden overloads. However, most of these attacks are of the denial-of-service type, resulting in limited impact and a relatively narrow attack surface. However, the fundamental and crucial issue of permissions in Kubernetes clusters has not been systematically studied. Existing attack techniques targeting Kubernetes have not systematically explored the risks posed by the complex dependencies between resources and operations underlying explicitly granted permissions, nor have they addressed the attack surface presented by these dependencies between resources and permissions. Summary of the Invention

[0006] In order to overcome the problems existing in the above-mentioned prior art, the purpose of the present invention is to disclose a Kubernetes privilege escalation attack method, system, device and medium based on implicit permission analysis and utilization. Aiming at the implicit permission problem behind the explicit permissions in the Kubernetes cluster, an innovative attack method is introduced. By analyzing the implicit permission mapping in the Kubernetes cluster, the security of Kubernetes is analyzed from multiple angles to more comprehensively understand and enhance the protection capabilities of the Kubernetes cluster, thereby improving the security of cloud-native applications and resisting potential threats, reducing potential attack risks.

[0007] In order to achieve the above object, the present invention adopts the following technical solutions:

[0008] A Kubernetes privilege escalation attack method based on implicit permission analysis and exploitation. The specific steps are as follows:

[0009] Step 1: Use the static analysis of the resource identification module based on resource registration to identify the various resources supported in the Kubernetes cluster, including both primary resources and sub-resources associated with the primary resources.

[0010] Step 2: Perform static analysis of resource functions on the main resources and sub-resources obtained in Step 1 to obtain the various explicit permissions supported by each Kubernetes resource.

[0011] Step 3: Through semantic analysis of the implicit permission mappings implied under the various explicit permissions obtained in step 2, the final implicit permission mappings in the explicit permissions are obtained.

[0012] The specific method of step 1 is: statically analyze the resource registration process in the Kubernetes source code through the abstract syntax tree (AST), extract all resource objects registered in the process, and finally obtain a complete resource list in the corresponding cluster;

[0013] 1.1 Identify the primary resource:

[0014] Locate the resource registration logic in the Kubernetes source code. When registering resources, Kubernetes first checks resource availability. For each resource, a conditional IF code block is assigned. Static analysis of the Abstract Syntax Tree (AST) locates these IF code blocks in the source code, extracts the various resource objects registered by Kubernetes, collects the names of the primary resources, and ultimately obtains a list of Kubernetes primary resources.

[0015] 1.2 Identifying sub-resources: Sub-resources are functional interfaces attached to primary resources. After the primary resource is registered, Kubernetes registers the sub-resources it contains for the primary resource in the same IF code block, that is, adds the sub-resources to the resource storage mapping object. By tracking and recording the same IF code block, all sub-resources provided by each primary resource can be collected, thereby effectively identifying all sub-resources and ultimately obtaining a list of Kubernetes sub-resources, ensuring comprehensive collection of all Kubernetes resources.

[0016] The specific method of step 2 is: statically analyzing the function definition of the resource storage object in the Kubernetes source code through the abstract syntax tree (AST), and statically analyzing the corresponding resource explicit permissions through the function function;

[0017] 2.1 Analysis of explicit permissions for primary resources:

[0018] For each primary resource, the abstract syntax tree (AST) is used to extract the functions defined by the primary resource storage object, and then the functions are associated with explicit permissions. Specifically, the explicit permissions supported by Kubernetes resources include Create, Get, Delete, DeleteCollection, Update, Patch, Watch, and List. The explicit permission Patch corresponds to the Get and Update functions. As long as both the Get and Update functions exist, the explicit permission Patch exists. Explicit permissions other than the explicit permission Patch directly correspond to a function with the same name. That is, when a primary resource supports a certain explicit permission, Kubernetes defines a corresponding function for the primary resource. By statically analyzing the specific functions defined by each resource, the explicit permissions supported by each primary resource can be obtained. Collect a list of explicit permissions for Kubernetes primary resources.

[0019] 2.2 Analysis of explicit permissions for sub-resources:

[0020] 2.2.1 Like main resources, most subresources have function definitions associated with explicit permissions. For these subresources, the explicit permission list for the Kubernetes subresource can be obtained by collecting the function definitions of the subresource storage objects through the abstract syntax tree (AST) and associating them with the explicit permissions.

[0021] 2.2.2 The remaining few special sub-resources have a CONNECT identifier, indicating that this type of special sub-resource provides a service related to the request proxy function; for this type of special sub-resource, there is no function definition associated with explicit permissions, but there is a special function definition called ConnectMethods. The return value of the ConnectMethods function directly indicates the explicit permissions supported by this type of special sub-resource; that is, by statically analyzing the ConnectMethods function of this type of special sub-resource through the abstract syntax tree AST, the return value of the ConnectMethods function is obtained, and the Kubernetes explicit permission list of this type of sub-resource is obtained.

[0022] The specific method of step 3 is: customize the AI ​​prompt word Prompt, input the static analysis results of the first two steps, and use LLM semantic analysis to find the implicit permissions corresponding to the explicit permissions of each resource;

[0023] 3.1 For primary resources, the final implicit permission mapping is obtained through a two-step semantic analysis of resource mapping and permission mapping.

[0024] 3.1.1 Given the definition of resource mapping semantic analysis: Resource mapping refers to establishing a mapping relationship between two resources through the functional connection between the resources. When one resource A functionally references or affects another resource B, there is a resource mapping from resource A to resource B.

[0025] 3.1.2 Definition of semantic analysis for a given permission mapping: Permission mapping refers to analyzing the functional connections between resources based on resource mapping, i.e., how a function of resource A affects resource B.

[0026] 3.1.3 Use known implicit permission analysis cases as training sets to train the Large Language Model (LLM) to ensure the semantic analysis effect and answer quality of the Large Language Model (LLM);

[0027] 3.1.4 Based on the Kubernetes main resource list and Kubernetes main resource explicit permission list collected in steps 1 and 2, input each Kubernetes resource name into the large language model LLM respectively, require the large language model LLM to perform resource mapping semantic analysis, and output the result of resource mapping semantic analysis. Based on the result of resource mapping analysis and the Kubernetes main resource explicit permission list, input the Kubernetes main resource explicit permission list supported by each resource into the large language model LLM, require the large language model LLM to perform permission mapping semantic analysis based on the Kubernetes main resource explicit permission list supported by the resource and the result of resource mapping semantic analysis, and output the result of main resource permission mapping semantic analysis.

[0028] 3.2 For sub-resources, directly perform permission mapping semantic analysis;

[0029] 3.2.1 Given the definition of sub-resource permission mapping semantic analysis: a sub-resource is an HTTPHandler associated with a main resource, providing an API interface for the corresponding main resource. The semantic analysis of the sub-resource mapping is to obtain the functional impact of the sub-resource on the corresponding main resource through the functions provided by each API interface of the sub-resource; on this basis, the training set is determined to ensure the semantic analysis effect and answer quality of the large language model LLM; then, according to the Kubernetes sub-resource list and the Kubernetes sub-resource explicit permission list statically analyzed in step 2, the Kubernetes sub-resource explicit permission list supported by each sub-resource is input into the large language model LLM, and it is required to analyze the API functions actually provided by the Kubernetes sub-resource explicit permission list according to the corresponding Kubernetes sub-resource explicit permission list, and obtain the final impact on the resource; finally, the implicit permission analysis result of the sub-resource is obtained.

[0030] A Kubernetes privilege escalation attack system based on implicit permission analysis and exploitation, including:

[0031] The resource identification module, based on resource registration collection, is used in step 1 to automatically identify all resources provided by Kubernetes, including primary resources and sub-resources. Based on the resource registration feature of Kubernetes, all API resources must be registered with a corresponding storage object before use. This module automatically identifies all Kubernetes resources and uses the identification results as input data for the next module.

[0032] An explicit permission analysis module based on storage object identification is used in step 2 to associate various functions defined by Kubernetes resource storage objects based on the Kubernetes resource identification results collected by the resource registration module. By statically analyzing the functions provided by each function for the Kubernetes resource storage object, including creation, deletion, modification, and query, the explicit permissions corresponding to each Kubernetes resource are obtained based on the specific functional functions provided by Kubernetes for each Kubernetes resource storage object.

[0033] An implicit permission analysis module based on the Large Language Model (LLM); used in step 3, the LLM is used to identify the explicit permissions associated with each Kubernetes resource, and the implicit permission mappings implied by these explicit permissions are analyzed through semantic analysis; after completing the analysis of the implicit permission mapping, the attack can be exploited based on the analyzed implicit permission results and the actual Kubernetes resource scenario.

[0034] A Kubernetes privilege escalation attack device based on implicit permission analysis and exploitation, including:

[0035] Memory for storing computer programs;

[0036] A processor is configured to implement a Kubernetes privilege escalation attack based on implicit permission analysis and utilization according to the Kubernetes privilege escalation attack method based on implicit permission analysis and utilization described in steps 1 to 3 when executing the computer program.

[0037] A computer-readable storage medium storing a computer program. When executed by a processor, the computer program can attack and exploit the implicit permission analysis results and actual Kubernetes resource scenarios based on the Kubernetes privilege escalation attack method based on implicit permission analysis and utilization described in steps 1 to 3.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] ① Steps 1 and 2 of this invention systematically analyze the various API resources provided by Kubernetes through static analysis based on resource registration. Furthermore, static analysis based on resource function analysis analyzes the various explicit permissions supported by each Kubernetes resource, providing a new research method for systematically understanding the various functions provided by Kubernetes. This method is adaptable to different Kubernetes versions, providing a new and groundbreaking approach for systematically analyzing Kubernetes.

[0040] ② Step 3 of the present invention derives and analyzes the implicit permission mapping in Kubernetes from explicit permissions through a Kubernetes implicit permission analysis method based on the large language model (LLM), which helps cloud computing vendors and users understand the security impact of implicit permissions, thereby providing new standards and ideas for permission configuration strategies, which has pioneering advantages.

[0041] ③ Step 3 of the present invention proposes a new attack surface, namely the implicit permission problem caused by the complex dependencies of resources and operations in Kubernetes. Existing security research on Kubernetes has focused on functions such as Kubernetes scheduling management. Starting from permission management, the present invention expands the attack surface of existing Kubernetes security research, demonstrates the vulnerability of Kubernetes' permission management mechanism, provides new ideas for attack and defense, solves new challenges, and has pioneering advantages.

[0042] In summary, compared to existing attack techniques that focus solely on exploiting explicit permissions or vulnerabilities in other Kubernetes management mechanisms (such as Sushring's co-residence attack and Ronen's DoS attack), this paper systematically reveals a new attack surface, implicit permissions, for the first time. The results have been verified to have a 67.8% implicit permission trigger rate. Through a structured chain-of-thought process and small-sample learning, LLM accurately analyzes the permission mapping relationship between resources, and the versatility of the method has been verified on multiple models, including GPT-4.5, DeepSeek-R1, and Gemini-2.0-Pro. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a diagram of the Kubernetes architecture.

[0044] Figure 2 Analyze the structure diagram for implicit permissions.

[0045] Figure 3 Flowchart for object registration for primary resource storage.

[0046] Figure 4 Stores object registration flow chart for sub-resources.

[0047] Figure 5 Explicit permission association diagram for primary resources.

[0048] Figure 6 Explicit permission graph for subresources.

[0049] Figure 7 This is the analysis flow chart for the main resource permission mapping.

[0050] Figure 8 Analyze the flow chart for sub-resource permission mapping. DETAILED DESCRIPTION

[0051] The present invention will be described in further detail below with reference to the accompanying drawings.

[0052] See also Figure 1 Kubernetes uses role-based access control (RBAC) by default. We refer to permissions directly granted to application components as explicit permissions, which allow components to perform clearly defined operations on specific resources. At the same time, we refer to indirect permissions arising from complex interdependencies between resources and operations as implicit permissions, which allow application components to affect or operate other resources without direct authorization. Explicit permissions are intuitive, so excessively high explicit permissions often attract attention. However, due to complex dependencies between resources, lower explicit permissions may imply higher implicit permissions, making some seemingly lower explicit permissions not only more hidden but also potentially more dangerous.

[0053] To systematically analyze the implicit permission dependencies of resources in Kubernetes, this solution is divided into three steps.

[0054] A Kubernetes privilege escalation attack system based on implicit permission analysis and exploitation, including:

[0055] The resource identification module, based on resource registration collection, is used in step 1 to automatically identify all resources provided by Kubernetes, including primary resources and sub-resources. Based on the resource registration feature of Kubernetes, all API resources must be registered with a corresponding storage object before use. This module automatically identifies all Kubernetes resources and uses the identification results as input data for the next module.

[0056] An explicit permission analysis module based on storage object identification is used in step 2 to associate various functions defined by Kubernetes resource storage objects based on the Kubernetes resource identification results collected by the resource registration module. By statically analyzing the functions provided by each function for the Kubernetes resource storage object, including creation, deletion, modification, and query, the explicit permissions corresponding to each Kubernetes resource are obtained based on the specific functional functions provided by Kubernetes for each Kubernetes resource storage object.

[0057] An implicit permission analysis module based on a large language model (LLM); used in step 3, using a large language model (LLM) (e.g., GPT-4) to identify explicit permissions associated with each Kubernetes resource, and semantically analyzing the implicit permission mappings implied under these explicit permissions; after completing the analysis of the implicit permission mappings, attacks can be exploited based on the analyzed implicit permission results and the actual Kubernetes resource scenarios.

[0058] A Kubernetes privilege escalation attack method based on implicit permission analysis and exploitation. The specific steps are as follows:

[0059] Step 1: Use the resource identification module collected through resource registration to fully identify all types of resources supported in the Kubernetes cluster, including both primary resources and sub-resources associated with the primary resources. The specific method is to analyze the resource registration process in the Kubernetes source code through AST, extract all resource objects registered in the process, and finally obtain a complete list of resources in the corresponding cluster.

[0060] 1.1 Identify the primary resource:

[0061] First, locate the location of the resource registration logic in the Kubernetes source code; when registering resources, Kubernetes first checks the resource availability, that is, for each resource, there is a corresponding conditional judgment IF code block. These IF code blocks in the source code are located through abstract syntax tree AST analysis, and the various resource objects registered by Kubernetes are extracted from them; specifically, during the resource registration process, Kubernetes will create a storage mapping object for the resource. The key of this mapping will be used to store the resource name of the resource to be registered, and the value will be used to store the storage object of the resource to be registered. After that, a local variable will be declared and initialized for the resource to be registered to identify the resource name of the resource. Subsequently, Kubernetes uses the IF statement to check whether the resource to be registered is enabled. If enabled, the storage object of the resource is constructed, and the resource name and storage object are filled into the previously created storage mapping object. Therefore, by identifying this special IF conditional statement, the resource name of the main resource is collected, and finally the Kubernetes main resource list is obtained;

[0062] 1.2 Identifying Subresources: Subresources are functional interfaces attached to primary resources. After registering a primary resource, Kubernetes will also register its subresources within the same IF code block. This means adding the subresources to the resource storage mapping object. Specifically, the key of this mapping is the combination of the primary resource name and the subresource identifier, and the value is the resource storage object for the subresource. Therefore, by tracking and recording the same IF code block, all subresources provided by each primary resource can be collected, effectively identifying all subresources and ultimately obtaining a list of Kubernetes subresources, ensuring comprehensive collection of all Kubernetes resources.

[0063] Step 2: Based on the main resources and sub-resources obtained in step 1, analyze the various explicit permissions supported by each Kubernetes resource through static analysis based on resource function functions, that is, analyze the effective permissions supported by Kubernetes resources respectively; the specific method is: analyze the function definition of the resource storage object in the Kubernetes source code through the abstract syntax tree AST, and analyze the corresponding resource explicit permissions through the function function.

[0064] 2.1 Analysis of explicit permissions for primary resources:

[0065] For each primary resource, the abstract syntax tree (AST) is used to extract the functions defined by the primary resource storage object, and then the functions are associated with explicit permissions. Specifically, Kubernetes resources may support eight explicit permissions: Create, Get, Delete, DeleteCollection, Update, Patch, Watch, and List. Except for Patch, these explicit permissions directly correspond to a function with the same name. That is, when a primary resource supports a certain explicit permission, the primary resource will implement a corresponding function. Therefore, by analyzing the specific functions implemented by each resource, the explicit permissions supported by each primary resource can be analyzed. A list of explicit permissions for Kubernetes primary resources is collected. For the Patch permission, it can be understood as a combination of Get and Update. As long as Get and Update exist at the same time, the Patch permission exists.

[0066] 2.2 Analysis of explicit permissions for sub-resources:

[0067] 2.2.1 For subresources, most subresources, like main resources, have function definitions associated with explicit permissions. Therefore, following the analysis strategy for main resources, we collect the function definitions of subresource storage objects through the abstract syntax tree (AST) and associate them with explicit permissions to obtain the explicit permission list of these Kubernetes subresources.

[0068] 2.2.2 For the remaining small number of special sub-resources, these sub-resources will have a CONNECT identifier, indicating that they provide a special service. Although there is no function definition associated with explicit permissions for these special sub-resources, there is a special function definition called ConnectMethods. The return value of the ConnectMethods function directly indicates the explicit permissions supported by this type of special sub-resource. That is, by collecting the ConnectMethods functions of this type of special sub-resource through the abstract syntax tree AST and obtaining the return value of the ConnectMethods function, you can get the Kubernetes explicit permission list for this type of sub-resource.

[0069] Step 3. Finally, the Kubernetes implicit permission analysis method based on the Large Language Model (LLM) is used to derive the final implicit permission mapping from the explicit permissions obtained in Step 2. The specific method is to customize the AI ​​prompt word Prompt, input the static analysis results of the first two steps, and use LLM to analyze the implicit permissions corresponding to the explicit permissions of each resource.

[0070] 3.1 For primary resources, through the two steps of resource mapping analysis and permission mapping analysis, the final implicit permission mapping is analyzed in a progressive and guided manner;

[0071] 3.1.1 Given the definition of resource mapping analysis: Resource mapping refers to establishing a mapping relationship between two resources through the functional connection between the resources. When one resource A functionally references or affects another resource B, there is a resource mapping from resource A to resource B.

[0072] 3.1.2 Definition of a given permission mapping analysis: Permission mapping refers to analyzing the specific functional connections between resources based on resource mapping, that is, the impact that a certain function of resource A can have on resource B. For example, if the create function of resource A can trigger the creation effect of resource B, then there is a permission mapping from create resource A to create resource B.

[0073] 3.1.3 Use known implicit permission analysis cases as training sets to ensure that the LLM's analysis effect and answer quality are within the expected range;

[0074] 3.1.4 After giving the definition and training set, according to the Kubernetes main resource list and Kubernetes main resource explicit permission list collected in steps 1 and 2, the name of each Kubernetes resource is input into the large language model LLM respectively, and the large language model LLM is required to perform resource mapping analysis and output the result of resource mapping analysis. According to the result of resource mapping analysis and the Kubernetes main resource explicit permission list, the Kubernetes main resource explicit permission list supported by each resource is input into the large language model LLM. The large language model LLM is required to perform permission mapping analysis based on the Kubernetes main resource explicit permission list supported by the resource and the result of resource mapping analysis, and output the result of main resource permission mapping analysis.

[0075] 3.2 For sub-resources, since sub-resources do not have specific data structures and are strongly associated with actual functions, permission mapping analysis can be performed directly;

[0076] 3.2.1 Given the definition of sub-resource permission mapping analysis: A sub-resource is an HTTP Handler associated with a primary resource, providing the API interface of the corresponding primary resource. Sub-resource mapping analysis is to determine the functional impact of the sub-resource on the corresponding primary resource through the functions provided by each sub-resource API interface. On this basis, a known analysis case is given as a training set to ensure the analysis effect and answer quality of the large language model (LLM); within the expected range. Then, based on the Kubernetes sub-resource list and Kubernetes sub-resource explicit permission list analyzed in step 2, the Kubernetes sub-resource explicit permission list supported by each sub-resource is input into the large language model (LLM). It is required to analyze the API functions actually provided by the Kubernetes sub-resource explicit permission list based on the corresponding Kubernetes sub-resource explicit permission list, and determine which resources can be affected by what impact. Finally, the implicit permission analysis results of the sub-resource are obtained.

[0077] Example:

[0078] First, you need to fully identify all types of resources supported by the Kubernetes cluster, including both primary resources and sub-resources associated with them. Then, based on the first step, you need to analyze the various explicit permissions supported by each resource, that is, analyze the effective permissions supported by each resource. Finally, derive all the final implicit permission mappings from these explicit permissions.

[0079] To identify a complete list of Kubernetes cluster resources, a static analysis strategy was designed based on Kubernetes' implementation principles. Through static analysis of the Kubernetes source code, a complete list of resources in the corresponding cluster was obtained. This strategy is organized around two key techniques: primary resource identification and subresource identification. Primary resources are the main objects managed by Kubernetes (e.g., Pods, Deployments, Jobs, etc.). In contrast, subresources are elements associated with primary resources (e.g., pod / exec, deployment / status, etc.), which are associated with the primary resource but managed independently. Analysis of the Kubernetes implementation revealed that each primary resource must register a storage object before use. Therefore, this approach can identify all primary resources by focusing on the initialization and registration patterns of each resource. Meanwhile, for subresources, their registration is inherently tied to their corresponding primary resource. Specifically, for primary resources, the focus is on conditional statements that check resource availability, typically structured as ifresource:="resourcename" . This type of code is a key indicator of the start of resource configuration. Subsequent initialization and registration steps, such as storage[resource]=NewStorage(...) , are part of the overall setup process. By locating these conditional check statements, this method can effectively collect the names of all primary resources. Figure 3 The func storage() function shown creates a storage mapping object containing ClusterRole and ClusterRoleBinding resources. Initially, it declares and initializes a local variable named resource (i.e., lines 4 and 9). Subsequently, it checks whether the resource is enabled. If so, it sets a new storage object for the resource key in the storage mapping (i.e., lines 6 and 11). This approach allows the present invention to recognize ifresource:= "clusterroles" and ifresource:=

[0080] The instance of "clusterrolebindings" is used to effectively collect the name of the main resource. For sub-resources, the registration process of the sub-resource is associated with its corresponding main resource. This association can track and record all related sub-resources after the main resource is registered. After the main resource is registered, the registration code related to the sub-resource uses the combination of the main resource name and the sub-resource identifier to register the sub-resource, such as subResourceStorage[resource+" / subresourcename"]=NewSubResourceStorage(...), as shown in the attached file. Figure 4 This enables the present invention to effectively identify all related sub-resources and ensure comprehensive collection of all Kubernetes resources.

[0081] In order to systematically analyze the explicit permissions associated with each resource, the present invention divides the analysis of explicit permissions into explicit permission analysis of main resources and explicit permission analysis of sub-resources based on the list of main resources and sub-resources obtained above. For main resources, the core of the present invention is that in Kubernetes, all explicit permissions of main resources are closely related to the method set of the storage objects of the corresponding resources. The methods defined by these storage objects reflect the operations supported by the main resources, that is, the explicit permissions they support. Specifically, for each main resource, the present invention extracts the implementation of each method corresponding to the storage object through static analysis, and directly maps the method to the corresponding API action, that is, the explicit permission action. Figure 5 For example, the storage object PodStorage.Pod of Pod is registered through the NewRESTStorage method. This storage object is a subclass of the general storage object registry.Store object, so it inherits the methods of the Store object. Analysis shows that the Pod storage object defines the Create method shown in the figure, which can be directly mapped to the explicit permission Create, that is, Pod supports the explicit permission Create. Through the above analysis, the explicit permissions corresponding to all main resources can be analyzed. For the explicit permission analysis of sub-resources, the present invention divides it into two steps. First, for some sub-resources, which have the same characteristics as the above-mentioned main resources, a similar method can be used to analyze the method set of the sub-resource storage object to obtain the corresponding explicit permissions. However, not all sub-resources maintain this rule. For these special sub-resources, their explicit permissions are strongly associated with the HTTP method defined in their ConnectMethods method. Through this relationship, the remaining explicit permissions can be analyzed. In the attached figure Figure 6 For example, for the pods / exec subresource, its ConnectMethods method reflects the supported HTTP methods ("GET" and "POST"), which can be mapped to standard Kubernetes explicit permissions ("get" and "create"). Therefore, through the above method, the explicit permissions corresponding to each resource can be systematically analyzed.

[0082] In order to systematically analyze the implicit permissions implied by the explicit permissions of resources, the present invention adopts permission mapping analysis based on the large language model LLM. The implicit permission mapping analysis of the main resources includes resource mapping analysis and permission mapping analysis. Specifically, since Kubernetes will define the corresponding structure for the main resources, the resources may be associated through the structure, so the possible dependencies between the main resources are analyzed first, and then the explicit permission verbs are added based on this to complete the complete permission mapping analysis. As shown in the attached figure Figure 7 As shown, the present invention employs a structured chain of thought process to ensure that the large language model (LLM) can effectively perform resource mapping analysis. First, the basic concepts of primary resource mapping are explained to the large language model (LLM), supplemented by practical examples based on professional knowledge. During this stage, the large language model (LLM) uses small-sample learning to quickly adapt and absorb new concepts and data, enhancing its ability to conduct further analysis. Secondly, the present invention inputs the specific resource identified through primary resource identification technology and instructs the LLM to enumerate all fields of this resource. This step involves the large language model (LLM)'s knowledge retrieval technology, which comprehensively extracts all relevant fields of the resource from a large pre-trained Kubernetes domain knowledge database to ensure comprehensiveness and accuracy. The present invention has the large language model (LLM) perform a thorough resource mapping analysis on all retrieved fields. During this stage, the large language model (LLM) applies knowledge reasoning to explore the relationships between various fields and associate specific fields with other related resources. Next, permission mapping analysis continues, adding permission mapping examples as a basic training set. The explicit resource permissions obtained from the previous analysis and the resource mapping results are then input, and the large language model (LLM) finally analyzes the corresponding permission mapping results. For implicit permissions of sub-resources, since sub-resources lack corresponding structural information, we consider leveraging the pre-trained knowledge and logical reasoning capabilities of the large language model (LLM). By learning from a small number of samples, the large language model can deeply understand the Kubernetes architecture and its permission management. This enables it to effectively identify the security impact of explicit permissions related to sub-resources on other resources and build implicit permission mappings. Figure 8 As shown, first, based on domain knowledge, the basic concepts and cases of sub-resource permission mapping are provided to the large language model LLM. Secondly, a specific sub-resource is input, and the explicit permissions corresponding to the resource are input. Third, for each explicit permission of the sub-resource, the large language model LLM is requested to perform permission mapping analysis. Therefore, the present invention completes the implicit permission mapping analysis of the resource in the above manner.

[0083] After analyzing the implicit permission mapping, you can manually exploit the attack based on the mapping results and the specific Kubernetes environment. For example, consider the following implicit permission mapping: create clusterrolebinding + bindclusterrole -> *.*. This specific explicit permission will cause the implicit permission to be extended to any permission. For example, consider Kubecost, a cluster-level application that provides real-time cost visualization for Kubernetes clusters. This application can be quickly deployed to Google GKE through the Google Marketplace.

[0084] Kubecost has multiple components. One of these components, kubecost-deployer, runs as a KubernetesJob, which is a set of pods that are randomly run on worker nodes. The application has two explicit permissions, createclusterrolebinding and bindclusterrole. Once an attacker controls the application, they can use the implicit permissions implied by these two explicit permissions to escalate permissions. Specifically, an attacker can create new ClusterRoleBindings and bind existing ClusterRoles to any service account. By leveraging these permissions, an attacker can create a new ClusterRoleBinding and bind their own service account to the default administrator ClusterRole, cluster-admin. cluster-admin has the ability to execute all verbs on all resources. Therefore, this grants the attacker's service account implicit permission to control all resources in the cluster. This implicit permission makes the attacker a cluster administrator, giving them the ability to control all other nodes in the entire cluster.

[0085] Simulation experiment

[0086] First, during the static analysis phase, we conducted an in-depth analysis of the source code for Kubernetes v1.30.10, successfully identifying all 116 API resources (70 main resources and 46 sub-resources) and further extracting 635 explicit permissions. Based on this, we constructed a hybrid analysis architecture that combines large language models (such as GPT-4.5) with static analysis, systematically mining 453 implicit permission reference paths, 307 of which were successfully triggered in real environments, significantly revealing permission propagation paths that are not explicitly defined in the current permission model but actually exist. We fully verified the accuracy, practicality, and versatility of the proposed implicit permission analysis method, and systematically demonstrated its practical value and technological innovation in Kubernetes security analysis.

[0087] The innovation of this invention is mainly reflected in three aspects. First, this invention proposes and systematically defines a new attack surface called "implicit permissions", breaking through the traditional research paradigm of "explicit permissions" and "redundant permissions", and filling the gaps in existing permission analysis in dynamic behavior and semantic dependencies between resources. Secondly, a set of analysis frameworks that integrate the semantic reasoning capabilities of the large language model (LLM) are designed. The large language model (LLM) has demonstrated strong generalization capabilities in understanding the complex interactions, resource dependencies, and contextual relationships between Kubernetes control plane components, and has successfully identified a large number of loosely structured but highly dangerous permission transmission paths. The system achieved an implicit permission trigger rate of 67.8%.

[0088] In addition, the system of the present invention also shows strong adaptability in terms of versatility. The present invention not only achieves the best recognition effect on GPT-4.5, but also tests on DeepSeek-R1 and Gemini-2.0-Pro, verifying that the method of the present invention can be migrated and applied between different models. At the same time, the analysis process was reused on multiple versions of Kubernetes (including v1.29.2, v1.30.2 and v1.31.2), and the implicit permission path was successfully identified, proving that the method does not depend on a specific version or model and has strong scalability.

[0089] Overall, this paper expands permission analysis from a static perspective to a dynamic behavioral level for the first time, proposing "implicit permissions" as a structural attack vector. By combining semantic and structural analysis in a hybrid architecture, it achieves breakthroughs in accuracy, trigger rate, and adaptability. This approach not only enables the discovery of deeper permission risks but also provides a systematic research foundation and practical guidance for future Kubernetes permission design and protection mechanisms.

Claims

1. A Kubernetes privilege escalation attack method based on implicit permission analysis and utilization, characterized by: The specific steps are as follows: Step 1: Use the static analysis of the resource identification module based on resource registration to identify the various resources supported in the Kubernetes cluster, including both primary resources and sub-resources associated with the primary resources. Step 2: Perform static analysis of resource functions on the main resources and sub-resources obtained in Step 1 to obtain the various explicit permissions supported by each Kubernetes resource. Step 3: Through semantic analysis of the implicit permission mappings implied under the various explicit permissions obtained in step 2, the final implicit permission mappings in the explicit permissions are obtained.

2. The Kubernetes privilege escalation attack method based on implicit permission analysis and utilization according to claim 1 is characterized in that: The specific method of step 1 is: statically analyze the resource registration process in the Kubernetes source code through the abstract syntax tree (AST), extract all resource objects registered in the process, and finally obtain a complete resource list in the corresponding cluster; 1.1 Identify the primary resource: Locate the resource registration logic in the Kubernetes source code. When registering resources, Kubernetes first checks resource availability. For each resource, a conditional IF code block is assigned. Static analysis of the Abstract Syntax Tree (AST) locates these IF code blocks in the source code, extracts the various resource objects registered by Kubernetes, collects the names of the primary resources, and ultimately obtains a list of Kubernetes primary resources. 1.2 Identifying sub-resources: Sub-resources are functional interfaces attached to primary resources. After the primary resource is registered, Kubernetes registers the sub-resources it contains for the primary resource in the same IF code block, that is, adds the sub-resources to the resource storage mapping object. By tracking and recording the same IF code block, all sub-resources provided by each primary resource can be collected, thereby effectively identifying all sub-resources and ultimately obtaining a list of Kubernetes sub-resources, ensuring comprehensive collection of all Kubernetes resources.

3. The Kubernetes privilege escalation attack method based on implicit permission analysis and utilization according to claim 1 is characterized in that: The specific method of step 2 is: statically analyzing the function definition of the resource storage object in the Kubernetes source code through the abstract syntax tree (AST), and statically analyzing the corresponding resource explicit permissions through the function function; 2.1 Analysis of explicit permissions for primary resources: For each primary resource, the abstract syntax tree (AST) is used to extract the functions defined by the primary resource storage object, and then the functions are associated with explicit permissions. Specifically, the explicit permissions supported by Kubernetes resources include Create, Get, Delete, DeleteCollection, Update, Patch, Watch, and List. The explicit permission Patch corresponds to the Get and Update functions. As long as both the Get and Update functions exist, the explicit permission Patch exists. Explicit permissions other than the explicit permission Patch directly correspond to a function with the same name. That is, when a primary resource supports a certain explicit permission, Kubernetes defines a corresponding function for the primary resource. By statically analyzing the specific functions defined by each resource, the explicit permissions supported by each primary resource can be obtained. Collect a list of explicit permissions for Kubernetes primary resources. 2.2 Analysis of explicit permissions for sub-resources: 2.2.1 Like main resources, most subresources have function definitions associated with explicit permissions. For these subresources, the explicit permission list for the Kubernetes subresource can be obtained by collecting the function definitions of the subresource storage objects through the abstract syntax tree (AST) and associating them with the explicit permissions. 2.2.2 The remaining few special sub-resources have a CONNECT identifier, indicating that this type of special sub-resource provides a service related to the request proxy function; for this type of special sub-resource, there is no function definition associated with explicit permissions, but there is a special function definition called ConnectMethods. The return value of the ConnectMethods function directly indicates the explicit permissions supported by this type of special sub-resource; that is, by statically analyzing the ConnectMethods function of this type of special sub-resource through the abstract syntax tree AST, the return value of the ConnectMethods function is obtained, and the Kubernetes explicit permission list of this type of sub-resource is obtained.

4. The Kubernetes privilege escalation attack method based on implicit permission analysis and utilization according to claim 1 is characterized in that: The specific method of step 3 is: customize the AI ​​prompt word Prompt, input the static analysis results of the first two steps, and use LLM semantic analysis to find the implicit permissions corresponding to the explicit permissions of each resource; 3.1 For primary resources, the final implicit permission mapping is obtained through a two-step semantic analysis of resource mapping and permission mapping. 3.1.1 Given the definition of resource mapping semantic analysis: Resource mapping refers to establishing a mapping relationship between two resources through the functional connection between the resources. When one resource A functionally references or affects another resource B, there is a resource mapping from resource A to resource B. 3.1.2 Definition of semantic analysis for a given permission mapping: Permission mapping refers to analyzing the functional connections between resources based on resource mapping, i.e., how a function of resource A affects resource B. 3.1.3 Use known implicit permission analysis cases as training sets to train the Large Language Model (LLM) to ensure the semantic analysis effect and answer quality of the Large Language Model (LLM); 3.1.4 Based on the Kubernetes main resource list and Kubernetes main resource explicit permission list collected in steps 1 and 2, input each Kubernetes resource name into the large language model LLM respectively, require the large language model LLM to perform resource mapping semantic analysis, and output the result of resource mapping semantic analysis. Based on the result of resource mapping analysis and the Kubernetes main resource explicit permission list, input the Kubernetes main resource explicit permission list supported by each resource into the large language model LLM, require the large language model LLM to perform permission mapping semantic analysis based on the Kubernetes main resource explicit permission list supported by the resource and the result of resource mapping semantic analysis, and output the result of main resource permission mapping semantic analysis. 3.2 For sub-resources, directly perform permission mapping semantic analysis; 3.2.1 Given the definition of sub-resource permission mapping semantic analysis: a sub-resource is an HTTP Handler associated with a main resource, providing an API interface for the corresponding main resource. The semantic analysis of sub-resource mapping is to obtain the functional impact of the sub-resource on the corresponding main resource through the functions provided by each API interface of the sub-resource; on this basis, the training set is determined to ensure the semantic analysis effect and answer quality of the large language model LLM; then, according to the Kubernetes sub-resource list and Kubernetes sub-resource explicit permission list statically analyzed in step 2, the Kubernetes sub-resource explicit permission list supported by each sub-resource is input into the large language model LLM, and it is required to analyze the API functions actually provided by the Kubernetes sub-resource explicit permission list based on the corresponding Kubernetes sub-resource explicit permission list, and obtain the final impact on the resource; finally, the implicit permission analysis result of the sub-resource is obtained.

5. A system for analyzing and exploiting implicit permissions in Kubernetes, including: Resource identification module based on resource registration collection; In step 1, all resources provided by Kubernetes are automatically identified, including primary resources and sub-resources. Based on the resource registration feature of Kubernetes, all API resources must be registered with a corresponding storage object before use. This allows for automatic identification of all Kubernetes resources, and the identification results are used as input data for the next module. Explicit permission analysis module based on storage object identification; For step 2, based on the Kubernetes resource results identified by the resource identification module collected by resource registration, various functions defined by the Kubernetes resource storage object are associated. The functions provided by each function for the Kubernetes resource storage object, including creation, deletion, modification, and query, are statically analyzed. Thus, the explicit permissions corresponding to each Kubernetes resource are obtained based on the specific functional functions provided by Kubernetes for each Kubernetes resource storage object. Implicit permission analysis module based on large language model (LLM); In step 3, the large language model (LLM) is used to identify the explicit permissions associated with each Kubernetes resource, and the implicit permission mappings implied by these explicit permissions are analyzed through semantics. After completing the analysis of the implicit permission mapping, the attack can be exploited based on the analyzed implicit permission results and the actual Kubernetes resource scenario.

6. Devices that exploit Kubernetes privilege escalation attacks based on implicit permission analysis and exploitation, including: memory for storing computer programs; A processor, configured to implement a Kubernetes privilege escalation attack based on implicit permission analysis and utilization according to the Kubernetes privilege escalation attack method based on implicit permission analysis and utilization according to any one of claims 1 to 5 when executing the computer program.

7. A computer-readable storage medium storing a computer program, which, when executed by a processor, can attack and exploit the implicit permission analysis results and actual Kubernetes resource scenarios based on the Kubernetes privilege escalation attack method based on implicit permission analysis and utilization as described in any one of claims 1 to 5.

Images