A method and apparatus for special permission management in Kubernetes clusters

Abstract

This specification discloses a method and apparatus for managing special permissions in a Kubernetes cluster. The method deploys and runs a special permission controller in the Kubernetes cluster to dynamically monitor special permission request objects and generate PSP objects containing special permissions. The method includes: acquiring special permissions and initializing a special permission request object containing those permissions; when the special permission controller detects a special permission request object, calculating a first PSP object containing special permissions by combining the user's basic PSP object with the special permission request object; and authorizing the first PSP object to the user through a role-based permission controller and updating the user's basic PSP object, so that the user can create and start a Pod corresponding to the special permissions contained in the first PSP object. This invention achieves effective management of the authorization and usage process of special permissions in the cluster by calculating a special permission set by the special permission controller using special permission requests and existing special permissions.

Description

Technical Field

[0001] This specification relates to the field of computer software technology, and in particular to a method, apparatus, electronic device, and storage medium for special permission management of Kubernetes clusters. Background Technology

[0002] In Kubernetes clusters, besides general resource authorization, there are also special permissions. These special permissions are not directly related to general Kubernetes resources and are not managed by independent Kubernetes objects. They can only be defined in Kubernetes Pods through certain fields, and these special permissions take effect after being validated by various relevant fields of the Pod. Typically, Kubernetes abstracts these special permissions into Pod Security Policy objects (PSP objects) and uses Role-Based Access Control (RBAC) to manage PSP objects. However, in practice, Kubernetes may require different special permissions with each iteration, and the PSP object management mechanism and RBAC mechanism can cause problems: when authorizing a special permission, it must be defined in a single PSP object; if multiple PSP objects are needed, they must be defined separately and then authorized to the same user through RBAC. From the perspective of RBAC execution, the user has multiple special permissions, but from the perspective of the PSP objects, the user's final special permissions are not the union of the special permissions defined by multiple PSPs, but rather are independent and cannot simultaneously possess two or more special permissions. Therefore, how to handle the authorization of multiple special permissions, while also being able to revoke and update these special permissions in a timely manner, is a technical problem that urgently needs to be solved. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to address the above-mentioned problems by providing a method, apparatus, electronic device, and storage medium for special permission management of Kubernetes clusters.

[0004] To solve the above-mentioned technical problems, the embodiments in this specification are implemented as follows:

[0005] Firstly, a method for managing special permissions in a Kubernetes cluster is proposed. This method involves deploying and running a special permission controller within the Kubernetes cluster. The special permission controller dynamically monitors special permission request objects and generates PSP objects containing special permissions. This includes:

[0006] Acquire special permissions and initialize a special permission request object containing the special permissions;

[0007] When the special permission controller detects the special permission request object, it merges the user's basic PSP object with the special permission request object to generate a first PSP object containing the special permission.

[0008] The role-based access control instruction authorizes the first PSP object to the user and updates the user's basic PSP object, so that the user can create and start a Pod corresponding to the special permissions contained in the first PSP object.

[0009] Furthermore, the special permission request object is in the administrator approval status; and before calculating the user's basic PSP object with the special permission request object to obtain the first PSP object corresponding to the special permission, the status of the special permission request object is "approved by the administrator".

[0010] Further, authorizing the first PSP object to the user through the role and permission controller and updating the user's basic PSP object includes:

[0011] The role-based access controller defines a Role / ClusterRole to map the special permissions contained in the first PSP object;

[0012] The RoleBinding / ClsuterRoleBinding instruction is executed to grant the user the special permissions contained in the first PSP object.

[0013] Furthermore, the special permission request object also includes a special permission validity period; and the method further includes:

[0014] When the special permission expires, the special permission is revoked and the special permission controller recalculates to obtain the second PSP object; and the second PSP object is updated to the user's basic PSP object.

[0015] Furthermore, the special permission request object also includes an expiration threshold; and the method further includes:

[0016] The special permission controller issues a prompt message including the expiration threshold to prompt the user to stop the Pod that is in a running state; and / or, when the expiration threshold is exceeded, the Kubernetes cluster forcibly stops the Pod.

[0017] Secondly, a special permission management device for Kubernetes clusters is proposed, which deploys and runs a special permission controller in the Kubernetes cluster. The special permission controller is used to dynamically monitor special permission request objects and generate PSP objects containing special permissions; including:

[0018] The first module is capable of acquiring special permissions and initializing a special permission request object containing the special permissions;

[0019] The second module is capable of merging the user's basic PSP object and the special permission request object to generate a first PSP object containing the special permission when the special permission controller monitors the special permission request object;

[0020] The third module is capable of executing role-based access control instructions to authorize the first PSP object to the user and update the user's basic PSP object, so that the user can create and start a Pod corresponding to the special permissions contained in the first PSP object.

[0021] Furthermore, the special permission request object also includes a special permission validity period; and the device further includes:

[0022] The fourth module is capable of revoking the special permission and having the special permission controller recalculate and obtain a second PSP object when the special permission expires; and updating the second PSP object to the user's basic PSP object.

[0023] Furthermore, the special permission request object also includes an expiration threshold; and the device further includes:

[0024] The fifth module is capable of issuing a prompt message, including the expiration threshold, from the special permission controller to prompt the user to stop the Pod that is in a running state; and / or, when the expiration threshold is exceeded, the Kubernetes cluster forcibly stops the Pod.

[0025] Thirdly, an electronic device is proposed, characterized in that it comprises:

[0026] Processor; and

[0027] A memory is configured to store computer-executable instructions, which, when executed, cause the processor to perform the Kubernetes cluster special permission management method described in the first aspect.

[0028] Fourthly, a computer-readable storage medium is proposed, characterized in that the computer-readable storage medium stores one or more programs, which, when executed by an electronic device including multiple applications, cause the electronic device to perform the Kubernetes cluster special permission management method described in the first aspect.

[0029] This manual can achieve at least the following technical effects:

[0030] The present invention deploys and runs a special permission controller to listen to special permission request objects and synthesizes the special permission request objects with existing PSP objects to obtain a set of special permissions. At the same time, by configuring attributes such as validity period for special permissions, it realizes effective management of the process of granting, revoking and updating special permissions. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is one of the schematic diagrams illustrating a special permission management method for a Kubernetes cluster provided in the embodiments of this specification.

[0033] Figure 2 This is the second schematic diagram of a special permission management method for a Kubernetes cluster provided in the embodiments of this specification.

[0034] Figure 3 This is the third schematic diagram of a special permission management method for a Kubernetes cluster provided in the embodiments of this specification.

[0035] Figure 4 This is the fourth illustration of a special permission management method for a Kubernetes cluster provided in the embodiments of this specification.

[0036] Figure 5 This is one of the schematic diagrams of a special permission management device for a Kubernetes cluster provided in the embodiments of this specification.

[0037] Figure 6 This is the second schematic diagram of a special permission management device for a Kubernetes cluster provided in the embodiments of this specification.

[0038] Figure 7This is the third schematic diagram of a special permission management device for a Kubernetes cluster provided in the embodiments of this specification.

[0039] Figure 8 This is a schematic diagram of the structure of an electronic device provided as an embodiment of this specification. Detailed Implementation

[0040] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0041] Key terms

[0042] Pod Security Policy (PSP) objects are used to control security-sensitive Pod specifications, such as root privileges. By default, Kubernetes allows the creation of Pod containers with special privileges, which could potentially compromise system security. PSPs protect the cluster from these specially privileged Pods by ensuring that requesters have the necessary permissions to create Pods according to their configurations.

[0043] Custom CRDs for Kubernetes User Resources: In Kubernetes, everything can be considered a resource. It provides many default resource types, such as Pods, Deployments, Services, and Volumes, which can meet most daily system deployment and management needs. However, in some special scenarios, these existing resource types cannot meet the requirements. These can be abstracted into custom Kubernetes resources. By extending the Kubernetes API through secondary development capabilities that customize user resources, new resource types can be added to the Kubernetes API without modifying the Kubernetes source code or creating a custom API server. This feature greatly improves the scalability of Kubernetes.

[0044] Role-Based Access Control (RBAC): Permissions are associated with roles, and users gain the permissions of those roles by becoming members of the appropriate roles. This greatly simplifies permission management. In an organization, roles are created to accomplish various tasks, and users are assigned corresponding roles based on their responsibilities and qualifications. Users can easily be assigned from one role to another. Roles can be granted new permissions based on new requirements and system integration, and permissions can be revoked from a role as needed. Relationships between roles can be established to encompass a wider range of objective situations. The RBAC model supports the principles of data abstraction and inheritance. Since most mainstream programming languages ​​support object-oriented technology, this feature of RBAC facilitates its application and implementation in real-world systems. The concepts in the model closely correspond to actual systems. The concepts of roles, users, and permissions in the RBAC model are real entities that exist in the actual system, making it easy for designers to build RBAC models for existing or planned systems.

[0045] The following section provides a detailed explanation of a special permission management scheme for Kubernetes clusters, as described in this manual, through specific examples.

[0046] Example 1

[0047] This invention focuses on how to solve the problem of granting multiple special permissions while simultaneously enabling timely revocation and updating of these permissions. Typically, in Kubernetes, besides the general authorization of Kubernetes resources, there is a special type of permission. This type of permission is not directly related to general Kubernetes resources and is not managed by a separate Kubernetes object. These permissions can only be defined in Pods through certain fields. For example, `hostNetwork` is a configuration in a Pod used to define whether to use the host machine's network environment. These special permissions do not take effect during the authorization verification process, but rather after the relevant fields of the Pod are verified during the Admission phase. Kubernetes abstracts these special permissions into PSP objects and uses RBAC to manage them. Specific permissions are defined by defining a Role / ClusterRole bound to a specific PSP, and then the special permission is granted to the target user. Often, an application needs different special permissions at different times during iterations, and the PSP management mechanism and RBAC can cause problems. When authorizing a PSP, the required special permissions must be defined within that PSP. If different permissions are defined across multiple PSPs and then granted to a user via RBAC, from the RBAC's perspective, the user already possesses the required special permissions. However, this is not actually the case. From the PSP's perspective, the special permissions the user ultimately possesses are not the union of the permissions defined across multiple PSPs, but rather independent of each other. Suppose a Pod requires two special permissions, such as `hostNetwork` and `hostPath`. These two special permissions are defined in two separate PSP objects, such as `PSP1` and `PSP2`. Then, RBAC is used to grant both `PSP1` and `PSP2` to user A. However, user A will fail to start the Pod, but a Pod started by user A that only requires one of the two special permissions will start successfully.

[0048] The technical approach of the Kubernetes cluster special permission management scheme in this invention is to use a layered approach to stack special permissions, ultimately obtaining a union of special permissions and granting it to the user. Specifically, a dedicated PSP object is generated for each user in the cluster. This dedicated PSP object can simultaneously bind multiple special permissions through the special permission stacking mechanism. Then, this dedicated PSP is authorized to the user via RBACP, allowing the user to start a Pod with two special permissions. However, considering the need to track and update special permissions after granting them multiple permissions, the special permission management scheme in Kubernetes requires not only reviewing and authorizing each request but also setting a validity period for the special permissions and a handling policy for expired permissions. Therefore, as... Figure 1 This illustration shows a method for managing special permissions in a Kubernetes cluster according to an embodiment of the present invention. A special permission controller is deployed and run in the Kubernetes cluster. This controller dynamically monitors special permission request objects and generates PSP objects containing special permissions. It should be noted that the special permission controller is a custom mode of the Kubernetes permission control mechanism. Typically, Kubernetes permission control includes Role scope, ClusterRole scope, RoleBinding, and ClusterRoleBinding. To adapt to the needs of special permission control, a custom special permission controller and its functions are defined based on a custom CRD of Kubernetes user resources. The method includes:

[0049] S1: Obtain special permissions and initialize a special permission request object containing the special permissions.

[0050] Specifically, the special permission request object includes the requesting account and the special permission request statement. The requesting account is used to declare the specific user who needs authorization; the special permission request statement is used to declare the specific special permission definition.

[0051] S2: When the special permission controller detects the special permission request object, it merges the user basic PSP object with the special permission request object to generate a first PSP object containing the special permission.

[0052] Optionally, the special permission request object includes an administrator approval status; the administrator approval status indicates that the request should be approved by the Kubernetes administrator before the first special permission request object is submitted to the special permission controller for synthesis calculation with the basic PSP object. Before the user's basic PSP object and the special permission request object are calculated to obtain the first PSP object corresponding to the special permission, the status of the special permission request object is "approved by administrator".

[0053] S3: Execute the role-based access control instruction to authorize the first PSP object to the user and update the user's basic PSP object, so that the user can create and start a Pod corresponding to the special permissions contained in the first PSP object.

[0054] Optionally, such as Figure 2 As shown, executing the role-based access control command to authorize the first PSP object to the user and update the user's basic PSP object includes:

[0055] The role-based access controller defines a Role / ClusterRole to map the special permissions contained in the first PSP object;

[0056] The RoleBinding / ClsuterRoleBinding instruction is executed to grant the user the special permissions contained in the first PSP object.

[0057] like Figure 3 The illustration shows another implementation of a Kubernetes cluster special permission management method according to an embodiment of the present invention. The special permission request object also includes a special permission validity period. The special permission validity period is used to declare the duration of special permission usage; if the validity period expires, the user should be prompted to take the Pod offline. The method further includes:

[0058] S4: When the special permission expires, the special permission is revoked and the special permission controller recalculates and obtains the second PSP object; and the second PSP object is updated to the user basic PSP object.

[0059] like Figure 4 The image shows a third implementation of a Kubernetes cluster special permission management method according to an embodiment of the present invention. The special permission request object further includes a validity period expiration threshold, which is used to declare a controllable time range for processing the Pod when its validity period has expired. The method further includes:

[0060] S5: Based on the prompt information issued by the special permission controller, including the expiration threshold, the user stops the Pod that is in a running state; and / or, when the expiration threshold is exceeded, the Kubernetes cluster forcibly stops the Pod.

[0061] This embodiment monitors special permission request objects by deploying and running a special permission controller, and performs a composite calculation on the special permission request objects and existing PSP objects to obtain a set of special permissions. At the same time, by configuring attributes such as validity period for special permissions, it realizes effective management of the authorization, revocation and update of special permissions.

[0062] Example 2

[0063] Figure 5 This is a schematic diagram of the structure of a Kubernetes cluster special permission management device 500 provided as an embodiment of this specification. Please refer to... Figure 5 In one embodiment, a Kubernetes cluster special permission management device 500 deploys and runs a special permission controller in the Kubernetes cluster. The special permission controller is used to dynamically monitor special permission request objects and generate PSP objects containing special permissions; including:

[0064] The first module 501 is capable of acquiring special permissions and initializing a special permission request object containing the special permissions;

[0065] The second module 502 is capable of merging the user's basic PSP object and the special permission request object to generate a first PSP object containing the special permission when the special permission controller monitors the special permission request object;

[0066] The third module 503 is capable of executing role-based access control instructions to authorize the first PSP object to the user and update the user's basic PSP object, so that the user can create and start a Pod corresponding to the special permissions contained in the first PSP object.

[0067] like Figure 6 The diagram illustrates another implementation of the Kubernetes cluster special permission management device 500 according to an embodiment of the present invention. The special permission request object further includes a special permission validity period; and the device further includes:

[0068] The fourth module 504 is capable of revoking the special permission and having the special permission controller recalculate and obtain a second PSP object when the special permission expires; and updating the second PSP object to the user's basic PSP object.

[0069] like Figure 7 The image shows a third implementation of the Kubernetes cluster special permission management device 500 according to an embodiment of the present invention. Further, the special permission request object also includes a validity period expiration threshold; and the device further includes:

[0070] The fifth module 505 is capable of issuing a prompt message, including the expiration threshold, from the special permission controller to prompt the user to stop the Pod that is in a running state; and / or, when the expiration threshold is exceeded, the Kubernetes cluster forcibly stops the Pod.

[0071] It should be understood that the Kubernetes cluster special permission management device 500 in the embodiments of this specification can also perform... Figures 1 to 4 This describes the method executed by the Kubernetes cluster special permission management device (or device), and how to implement the Kubernetes cluster special permission management device (or device) in... Figures 1 to 4 The functionality of the example shown will not be elaborated upon here.

[0072] Example 3

[0073] Figure 8This is a schematic diagram of the structure of an electronic device according to one embodiment of this specification. Please refer to it. Figure 8 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0074] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0075] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0076] The processor reads the corresponding computer program from non-volatile memory into main memory and then executes it, forming a shared resource access control mechanism at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0077] Deploying and running a special permission controller in a Kubernetes cluster, the special permission controller is used to dynamically monitor special permission request objects and generate PSP objects containing special permissions; including:

[0078] Acquire special permissions and initialize a special permission request object containing the special permissions;

[0079] When the special permission controller detects the special permission request object, it merges the user's basic PSP object with the special permission request object to generate a first PSP object containing the special permission.

[0080] The role-based access control instruction authorizes the first PSP object to the user and updates the user's basic PSP object, so that the user can create and start a Pod corresponding to the special permissions contained in the first PSP object.

[0081] The above is as described in this instruction manual. Figures 1 to 4 The Kubernetes cluster special permission management method disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this specification. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this specification can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0082] Of course, in addition to the software implementation, the electronic devices in the embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0083] Example 4

[0084] This specification also provides an embodiment of a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform... Figures 1 to 4The illustrated embodiment provides a method for managing special permissions in a Kubernetes cluster, specifically used to execute the following methods:

[0085] Deploying and running a special permission controller in a Kubernetes cluster, the special permission controller is used to dynamically monitor special permission request objects and generate PSP objects containing special permissions; including:

[0086] Acquire special permissions and initialize a special permission request object containing the special permissions;

[0087] When the special permission controller detects the special permission request object, it merges the user's basic PSP object with the special permission request object to generate a first PSP object containing the special permission.

[0088] The role-based access control instruction authorizes the first PSP object to the user and updates the user's basic PSP object, so that the user can create and start a Pod corresponding to the special permissions contained in the first PSP object.

[0089] In summary, the above description is merely a preferred embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

[0090] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0091] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0092] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A Kubernetes cluster special permission management method, characterized in that, Deploying a special permission controller in a Kubernetes cluster, the special permission controller is used to dynamically monitor a special permission request object and generate a PSP object containing a special permission; comprising: Obtain a special permission and initialize a special permission request object containing the special permission; When the special permission controller monitors the special permission request object, merge the user basic PSP object with the special permission request object to generate a first PSP object containing the special permission; Execute role permission control instructions to authorize the first PSP object to the user and update the user basic PSP object, so that the user creates and starts a Pod corresponding to the special permission contained in the first PSP object; The special permission request object further includes a special permission validity period; and the method further comprises: when the special permission exceeds the special permission validity period, revoke the special permission and recalculate a second PSP object by the special permission controller; and update the second PSP object as the user basic PSP object.

2. The Kubernetes cluster special permission management method of claim 1, wherein, The special permission request object administrator approval state; and before the state of the special permission request object is approved by the administrator, the user basic PSP object and the special permission request object are calculated to obtain a first PSP object corresponding to the special permission.

3. The Kubernetes cluster special permission management method of claim 1, wherein, Authorize the first PSP object to the user through the role permission controller and update the user basic PSP object, comprising: The role permission controller defines Role / ClusterRole for mapping the special permission contained in the first PSP object; Execute RoleBinding / ClsuterRoleBinding instructions to authorize the special permission contained in the first PSP object to the user.

4. The Kubernetes cluster special permission management method of claim 1, wherein, The special permission request object further includes an expiration threshold; and the method further comprises: Send a prompt message including the expiration threshold by the special permission controller to prompt the user to stop the Pod in a running state; and / or, when the expiration threshold is exceeded, forcibly stop the Pod by the Kubernetes cluster. 5.A Kubernetes cluster special permission management apparatus, characterized in that, Deploying a special permission controller in a Kubernetes cluster, the special permission controller is used to dynamically monitor a special permission request object and generate a PSP object containing a special permission; comprising: A first module capable of obtaining a special permission and initializing a special permission request object containing the special permission; A second module capable of merging a user basic PSP object with the special permission request object to generate a first PSP object containing the special permission when the special permission controller monitors the special permission request object; A third module capable of executing role permission control instructions to authorize the first PSP object to the user and update the user basic PSP object, so that the user creates and starts a Pod corresponding to the special permission contained in the first PSP object; A fourth module capable of revoking the special permission and recalculating a second PSP object by the special permission controller when the special permission exceeds the special permission validity period; and updating the second PSP object as the user basic PSP object. The special permission request object further comprises a special permission validity period; and the device further comprises: A fourth module capable of revoking the special permission and recalculating a second PSP object by the special permission controller when the special permission exceeds the special permission validity period; and updating the second PSP object as the user basic PSP object.

6. The Kubernetes cluster special permission management apparatus according to claim 5, wherein The special permission request object further comprises a validity period expiration threshold; And the device further comprises: A fifth module capable of issuing prompt information comprising the validity period expiration threshold by the special permission controller to prompt the user to stop the Pod in a running state; And / or, forcibly stopping the Pod by the Kubernetes cluster when the validity period expiration threshold is exceeded.

7. An electronic device, comprising: Comprise: A processor; And A memory arranged to store computer executable instructions that, when executed, cause the processor to perform the Kubernetes cluster special permission management method of any one of claims 1 to 4.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores one or more programs, which when executed by an electronic device comprising a plurality of applications, cause the electronic device to perform the Kubernetes cluster special permission management method of any one of claims 1 to 4.

Images