A method, apparatus, device and medium for change control of a resource object

Abstract

The application relates to the computer technical field, in particular to a resource object change control method and device, equipment and medium, which are used for solving the problem that a resource object is easily maliciously changed and runs in an unintended state in related technologies. In the method, the resource information in the received API request is matched with each resource change configuration information, if the matching with any resource change configuration information is successful, it is determined that the API request requests to change the target resource object, the API request is sent to the webhook corresponding to the resource change configuration information, whether the API request is from an authorized change user of the target resource object is determined by the webhook, the API request is processed based on the indication whether the API request is responded by the webhook, it is ensured that only the authorized change user can change the target resource object, the probability that the target resource object is maliciously changed by an unauthorized user is reduced, and the target resource object is prevented from running in an unintended state.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method, apparatus, device, and medium for controlling changes to resource objects. Background Technology

[0002] Helm is a native package management tool for Kubernetes (K8s). Helm allows third parties to provide a package called Chart, which contains related K8s resource templates and other files for creating or maintaining related resource objects.

[0003] In related technologies, Helm adopts an open approach to support the deployment and subsequent modification of third-party applications. This means that a third-party application deployed via a Chart can have its corresponding resource objects in Kubernetes modified in any way. For example, users can update the resource objects of a third-party application in Kubernetes using a Chart, and can also directly manage these resource objects using the kubectl binary tool, such as by using operations like `kubectledit` and `kubectl apply`. However, this open approach makes it easy for the resource objects of third-party applications to be maliciously modified, causing them to operate in unexpected states and leading to various usage problems for the application. Summary of the Invention

[0004] This application provides a method, apparatus, device, and medium for controlling changes to resource objects, which addresses the problem in related technologies that resource objects corresponding to applications in Kubernetes are easily maliciously modified, causing resource objects to run in an unexpected state and posing a risk to the application.

[0005] Firstly, this application provides a method for controlling changes to resource objects, including:

[0006] Receive an application programming interface (API) request, which contains resource information;

[0007] Match the resource information with the configuration change information of each resource;

[0008] If the resource information matches any resource change configuration information, then the API request is determined to be used to request a change to the target resource object corresponding to the resource change configuration information.

[0009] The API request is sent to the webhook corresponding to the resource change configuration information, and the webhook determines whether the API request comes from the authorized user of the target resource object.

[0010] The API request is processed based on the indication sent by the webhook regarding whether to respond to the API request. The indication is sent by the webhook based on the determination result of whether the API request originates from the authorized user of the target resource object.

[0011] In some embodiments, the authorized change user includes an authorized Helm user, and

[0012] The webhook compares the requesting user information of the API request with the user information of the Helm user to determine whether the API request comes from the Helm user.

[0013] If it is determined that the API request originated from the Helm user, an indication to respond to the API request is sent.

[0014] In some embodiments, the user information of the Helm user is the username or user group set by the service account ServiceAccount, and the permissions corresponding to the user information of the Helm user are Kubernetes cluster administrator permissions.

[0015] Before matching the resource information with the configuration change information of each resource, the process also includes:

[0016] It is determined that the user who initiated the API request has the corresponding resource operation permissions for the requested resource object.

[0017] In some embodiments, the Helm user's user information and the cluster administrator permissions are created by the Helm user through a Helm subcommand before the first call to the Kubernetes API to change resources; or, the Helm user's user information and the cluster administrator permissions are created by the Helm user when the first call to the Kubernetes API to change resources is made.

[0018] In some embodiments, the authorized change user includes authorized non-Helm users, and

[0019] The webhook obtains the annotation content corresponding to the target indication resource change permission annotation keyword from the resource information. The annotation content is obtained by encoding the permission description information of this change according to a preset encoding method.

[0020] If the annotation is obtained, it is determined that the API request comes from the non-Helm user;

[0021] The obtained annotation content is decoded according to the preset decoding method corresponding to the preset encoding method to obtain the permission description information and permission information of this change;

[0022] The permission description information is compared with the preset permission range information of the authorized kubectl non-Helm user to determine whether the API request for this change comes from the change permission range of the authorized kubectl non-Helm user.

[0023] If it is determined that the API request for this change originates from the authorized kubectl within the scope of the non-Helm user's change permissions, then an instruction to respond to the API request is sent.

[0024] In some embodiments, the authorized change user includes each of the built-in users of Kubernetes, and

[0025] The webhook compares the requesting user information of the API request with the user information of the built-in users of each system to determine whether the API request comes from any built-in user of the system.

[0026] If it is determined that the API request originated from any built-in user of the system, an indication to respond to the API request is sent.

[0027] In some embodiments, processing the API request based on an indication sent by the webhook regarding whether to respond to the API request includes:

[0028] If the webhook sends an instruction in response to the API request, then the target resource object is modified based on the API request;

[0029] If the webhook sends an indication not to respond to the API request, then the API request is rejected and a reason for rejection is returned.

[0030] Secondly, this application provides a resource object change control device, comprising:

[0031] The receiving module is used to receive application programming interface (API) requests, wherein the API requests contain resource information;

[0032] The matching module is used to match the resource information with the configuration change information of each resource;

[0033] The determination module is used to determine that if the resource information matches any resource change configuration information, the API request is used to request a change to the target resource object corresponding to the resource change configuration information.

[0034] The sending module is used to send the API request to the webhook corresponding to the resource change configuration information, and the webhook determines whether the API request comes from the authorized change user of the target resource object.

[0035] The processing module is used to process the API request based on the indication sent by the webhook regarding whether to respond to the API request. The indication is sent by the webhook based on the determination result of whether the API request comes from the authorized user of the target resource object.

[0036] In some embodiments, the authorized change user includes an authorized Helm user, and

[0037] The webhook compares the requesting user information of the API request with the user information of the Helm user to determine whether the API request comes from the Helm user.

[0038] If it is determined that the API request originated from the Helm user, an indication to respond to the API request is sent.

[0039] In some embodiments, the user information of the Helm user is the username or user group set through the service account ServiceAccount, and the permissions corresponding to the Helm user's user information are Kubernetes cluster administrator permissions; it also includes:

[0040] The permission module is used to determine whether the user who initiated the API request has the corresponding resource operation permission for the requested resource object before matching the resource information with the resource change configuration information.

[0041] In some embodiments, the Helm user's user information and the cluster administrator permissions are created by the Helm user through a Helm subcommand before the first call to the Kubernetes API to change resources; or, the Helm user's user information and the cluster administrator permissions are created by the Helm user when the first call to the Kubernetes API to change resources is made.

[0042] In some embodiments, the authorized change user includes authorized non-Helm users, and

[0043] The webhook obtains the annotation content corresponding to the target indication resource change permission annotation keyword from the resource information. The annotation content is obtained by encoding the permission description information of this change according to a preset encoding method.

[0044] If the annotation is obtained, it is determined that the API request comes from the non-Helm user;

[0045] The obtained annotation content is decoded according to the preset decoding method corresponding to the preset encoding method to obtain the permission description information and permission information of this change;

[0046] The permission description information is compared with the preset permission range information of the authorized kubectl non-Helm user to determine whether the API request for this change comes from the change permission range of the authorized kubectl non-Helm user.

[0047] If it is determined that the API request for this change originates from the authorized kubectl within the scope of the non-Helm user's change permissions, then an instruction to respond to the API request is sent.

[0048] In some embodiments, the authorized change user includes each of the built-in users of Kubernetes, and

[0049] The webhook compares the requesting user information of the API request with the user information of the built-in users of each system to determine whether the API request comes from any built-in user of the system.

[0050] If it is determined that the API request originated from any built-in user of the system, an indication to respond to the API request is sent.

[0051] In some embodiments, the processing module is specifically used for:

[0052] If the webhook sends an instruction in response to the API request, then the target resource object is modified based on the API request;

[0053] If the webhook sends an indication not to respond to the API request, then the API request is rejected and a reason for rejection is returned.

[0054] Thirdly, this application provides an electronic device, comprising:

[0055] Memory, used to store program instructions;

[0056] A processor is configured to invoke program instructions stored in the memory and execute the steps of the method described in any one of the first aspects according to the obtained program instructions.

[0057] Fourthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in any one of the first aspects.

[0058] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects.

[0059] In this embodiment, the resource information in the received API request is matched with each resource change configuration information. If the resource information matches any resource change configuration information, it is determined that the API request is for requesting a change to the target resource object. Then, the API request can be sent to the webhook corresponding to the resource change configuration information. The webhook determines whether the API request comes from an authorized user of the target resource object and processes the API request based on the webhook's indication of whether to respond to the API request. In this way, when an API request to change the target resource object is received, it can be determined whether the API request comes from an authorized user of the target resource object. This ensures that only authorized users can change the target resource object, reducing the probability of the target resource object being maliciously changed by unauthorized users and reducing the probability of the target resource object running in an unexpected state, thereby ensuring the stability of the corresponding application deployed in Kubernetes. Attached Figure Description

[0060] Figure 1 This application provides a possible application scenario diagram for an embodiment of the present application.

[0061] Figure 2 A flowchart illustrating a method for controlling changes to resource objects provided in an embodiment of this application;

[0062] Figure 3 A structural diagram of a resource object change control device provided in an embodiment of this application;

[0063] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0065] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0066] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0067] The acquisition, transmission, storage, and use of data in this application all comply with the requirements of relevant national laws and regulations.

[0068] Before introducing the method for controlling changes to resource objects provided in the embodiments of this application, the technical background of the embodiments of this application will be described in detail below for ease of understanding.

[0069] Helm is a native package management tool for Kubernetes (K8s). Helm allows third parties to provide a package called Chart, which contains related K8s resource templates and other files for creating or maintaining related resource objects.

[0070] In related technologies, Helm adopts an open approach to support the deployment and subsequent modification of third-party applications. This means that a third-party application deployed via a Chart can have its corresponding resource objects in Kubernetes modified in any way. For example, users can update the resource objects of a third-party application in Kubernetes using a Chart, and can also directly manage the resource objects of a third-party application in Kubernetes using kubectl binary tools, such as changing the resource objects of a third-party application in Kubernetes through operations like kubectledit and kubectl apply.

[0071] This open approach places high demands on application operations and maintenance (O&M) personnel, as they need to understand the application's architecture, operational logic, and configuration relationships. O&M personnel also need to be clear about what they are changing, how they are changing it, and what the results will be.

[0072] Furthermore, the open approach fails to provide standardization for the development of application release charts. During the development phase, developers may modify release-related Kubernetes resources or configurations in the development and testing environment using methods such as kubectledit for convenience. Such modifications may easily be overlooked and not merged into the release chart, requiring subsequent developers to investigate the cause, thus reducing development quality and efficiency.

[0073] Furthermore, for already released applications, granting permission to change settings is ineffective in constraining their operation. Any authorized personnel or third-party management system may modify the application's configuration for any purpose or simply due to operational error, causing the application to deviate from its original design.

[0074] To address this, this application provides a scheme for controlling changes to resource objects. In this scheme, upon receiving an API request to modify a target resource object (i.e., a resource object under control), it can determine whether the API request originates from an authorized user of the target resource object. This ensures that only authorized users can modify the target resource object, and other users are not permitted to do so. This reduces the probability of the target resource object being maliciously modified by unauthorized users and reduces the probability of the target resource object operating in an unexpected state, thereby ensuring the stability of the corresponding application deployed in K8S.

[0075] See Figure 1, Figure 1 This application provides a scenario diagram for a method to control changes to resource objects, including Helm and Kubernetes (K8s). Helm is a package manager for K8s, a command-line client tool primarily used for creating, packaging, and publishing K8s application charts, as well as creating and managing local and remote chart repositories. K8s is an open-source container orchestration engine that supports automated deployment, large-scale scalability, and containerized application management. It typically includes Master nodes and Node nodes, which are distributed across multiple services. The Master node contains an Application Programming Interface (APIServer) service and a validation webhook, while the Node nodes deploy resources from third-party applications. The webhook is a type of admission control webhook supported by K8s, typically running as a Pod in a K8s cluster. It can be written, created, updated, and deleted by third parties as needed, performing changes and validation on the content of specific resource objects submitted to the K8s APIServer in specific scenarios.

[0076] It's important to note that Helm charts can be used to deploy applications as well as to make changes (i.e., upgrades) to them. A Helm chart typically contains several Kubernetes resources that make up an application, and updating any one of these Kubernetes resources can be considered an update to the application.

[0077] The following describes the method for controlling changes to resource objects provided by exemplary embodiments of this application, in conjunction with the above application scenarios and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this respect.

[0078] Please refer to Figure 2 The flowchart below shows a method for controlling changes to resource objects provided in an embodiment of this application, which includes the following steps.

[0079] In step 201, the APIServer receives an API request, which contains resource information.

[0080] API requests originate from the client, and resource information includes resource type (such as API group, API version number, resource type name), namespace, resource content, etc. The type of operation to be performed on the resource, such as update or delete, and the corresponding label of the resource can be obtained from the resource content.

[0081] In step 202, the APIServer matches the resource information with the configuration change information of each resource.

[0082] Generally, if a Kubernetes cluster has issued permissions to multiple Helm clusters, meaning that one Kubernetes cluster corresponds to multiple authorized Helm users, then each authorized Helm user corresponds to a resource change configuration information, and each resource change configuration information corresponds to a webhook. The resource change configuration information is used to describe what target resource objects need to be changed and validated, and what API requests need to be sent to the corresponding webhook.

[0083] Furthermore, a resource change configuration information may include at least one of the following: a wildcard matching rule for the resource, an operation type for the resource, a namespace for the resource, and a tag for the resource. The wildcard matching rule for the resource is used to indicate the resource type of the target resource, the operation type for the resource is used to indicate the operation type of the target resource, the namespace for the resource is used to indicate the namespace of the target resource, and the tag for the resource is used to indicate the tag that the target resource has.

[0084] In step 203, if the APIServer determines that the resource information matches any resource change configuration information, it determines that the API request is used to request a change to the target resource object corresponding to the resource change configuration information.

[0085] In step 204, the APIServer sends the API request to the webhook corresponding to the resource change configuration information.

[0086] In step 205, the webhook determines whether the API request originates from an authorized user who has changed their authorization for the target resource object.

[0087] Scenario 1: Authorized user changes may include authorized Helm users. The Webhook can compare the requesting user information of the API request with the user information of the authorized Helm user to determine if the API request originates from an authorized Helm user. If it is determined that the API request originates from an authorized Helm user, an instruction to respond to the API request can be sent. A successful comparison occurs when the requesting user information of the API request matches the user information of the authorized Helm user.

[0088] In practical applications, the user information of authorized Helm users can be the username or user group set through the service account ServiceAccount. The permissions corresponding to the user information of authorized Helm users can be the K8s cluster administrator permissions. Furthermore, before matching the resource information with the configuration information of each resource change, the APIServer can also determine whether the user who initiated the API request has the corresponding resource operation permission for the requested resource object. If not, the API request can be rejected; if so, subsequent steps can be executed.

[0089] Furthermore, the user information and cluster administrator privileges of authorized Helm users can be created either by requesting the creation of the user's information and cluster administrator privileges before the first time the user calls the Kubernetes API to change resources, or by requesting the creation of the user's information and privileges when the user first calls the Kubernetes API to change resources. The former method creates the information in advance through a separate Helm subcommand, and the changes remain unchanged in subsequent changes. The latter method automatically creates the information upon the first resource change, which is imperceptible to the user. Both methods have their advantages, and technical personnel can choose according to their actual needs.

[0090] Scenario 1 above ensures that only authorized Helm users can modify the target resource object. However, considering that in enterprise release processes, if urgent issues arise requiring application fixes, there are often requirements for rapid response to emergency situations. Change management via Helm may not be able to handle these emergencies effectively and promptly. This is because writing new Helm chart packages requires additional time, and the transfer of Helm chart packages from the development environment to the production environment may also encounter typical enterprise release process constraints, leading to prolonged processing times.

[0091] Therefore, this application's embodiments, based on webhook-authorized Helm users, design an emergency handling mechanism for authorization codes. Unlike the Helm client-limited approach in Case 1, the authorization code approach does not limit the client; as long as the API request initiated by the client to modify the target resource object contains specific annotation content, modifications to the target resource object are allowed.

[0092] Specifically, administrators (i.e., users changing the target resource) can use the authorization code issuance tool to encode the permission description information for an emergency change, resulting in a string of characters. The permission description information includes: a) which authorized operator issued the code; b) the encoding date; c) the sequence number of the code within the issuance day; and d) the code obfuscation value and checksum. Then, using kubectl or a client that can directly send API requests, the encoded result is added as a (key, value) to the API request for changing the target resource object. The key is the annotation keyword representing the change permission, which can be pre-specified, and the value is the annotation content, i.e., the encoded result. Since the authorization code issuance tool and the webhook are jointly published, both using the same preset encoding / decoding method and the same preset permission information, the encoded result in the API request can be parsed and recognized by the webhook. This is situation 2 below.

[0093] Scenario 2: Authorized users for permission changes can also include authorized non-Helm users, such as authorized kubectl users or authorized client users who can directly send API requests. The Webhook can also retrieve the annotation content corresponding to the target annotation keyword (i.e., the annotation keyword indicating permission changes) from the resource information. If retrieved, it determines that the API request originates from an authorized non-Helm user. The annotation content can then be decoded according to a preset decoding method to obtain the permission description information for this change. This permission description information is compared with the preset permission range information for authorized non-Helm users to determine whether the change falls within the non-Helm user's permission change range. Once it is determined that the change falls within the non-Helm user's permission change range, an instruction to respond to the API request can be sent.

[0094] For example, authorized non-Helm users can only modify target resource objects a maximum of 3 times per day. If this is the second modification made by a non-Helm user to the target resource object, then this modification is within the non-Helm user's modification permission scope. If this is the fourth modification made by a non-Helm user to the target resource object, then this modification is not within the non-Helm user's modification permission scope. Another example: if the code validity period is one day, and the permission description information indicates that the coding date of the coding result is July 1, 2024, then if the current date is July 1, 2024, then this modification is within the non-Helm user's modification permission scope. If the current date is July 2, 2024, then this modification is not within the non-Helm user's modification permission scope.

[0095] In this way, when authorized non-Helm users change the target resource object, they can encode the permission description information of this change according to the preset encoding method agreed with Webhook, and add the encoding result to the API request for changing the target resource object as an annotation. Subsequently, the target resource object can be quickly changed and the application can be repaired through the permission verification of Webhook.

[0096] In addition, in practical applications, some API requests that match resource configuration change information may come from built-in Kubernetes users. These users are typically used to maintain the logical state of resources and are robot users that run the internal Kubernetes logic. To ensure that the relevant resources can be processed normally by Kubernetes, these usernames need to be allowed. This is situation 3 below.

[0097] Scenario 3: Authorized user changes may also include built-in users of various Kubernetes systems. Webhook can also compare the requesting user information of API requests with the user information of each built-in user to determine if the API request originates from any built-in user. If it is determined that the API request originates from any built-in user, an instruction to respond to the API request can be sent. A successful comparison occurs if the requesting user information of the API request conforms to the user naming rules of any built-in user.

[0098] In step 206, the webhook sends an indication of whether to respond to the API request based on the determination result of whether the API request comes from an authorized user who has changed their identity in the target resource object.

[0099] In practical applications, situations 1-3 above can be combined in any way. If the Webhook determines that the API request comes from an authorized Helm user, an authorized non-Helm user, or any system-built-in user, it can send an instruction to respond to the API request. If it determines that the API request does not come from an authorized Helm user, an authorized non-Helm user, or any system-built-in user, it can send an instruction to reject the API request. At this time, the reason for rejection can also be included, such as "You are not an authorized Helm user," "You are not an authorized kubectl user," or "The number of changes has exceeded the daily limit."

[0100] In step 207, the APIServer processes the API request based on the instructions sent by the webhook.

[0101] If the instruction is to respond to an API request, subsequent processing can be performed to modify the target resource object, thereby upgrading the corresponding application. If the instruction is to reject an API request, the API request can be rejected directly.

[0102] In this way, API requests that modify the target resource object can be determined to be from an authorized user of the target resource object. This ensures that only authorized users can modify the target resource object, reducing the probability of errors during resource changes and the probability of application problems.

[0103] The solutions of the embodiments of this application will be described below with reference to specific examples.

[0104] In this embodiment, the main advantage lies in Helm's ability to specify a username when submitting resources to Kubernetes, and the established practice of labeling resource objects in the Helm Chart with Helm-related tags. By embedding a specific username into the secondary Helm, users of the secondary Helm are considered authorized Helm users. Subsequently, each time a release is made through the secondary Helm, the resource change request submitted to Kubernetes will include the specific username. Then, combined with a corresponding validation webhook, the resource change request with the relevant tags is validated. The validation primarily checks whether the username issuing the request is the specific username, thereby distinguishing whether the resource change request originates from the secondary Helm and allowing resource change requests from the secondary Helm.

[0105] First, we will explain how to create a specific username and the permissions that a specific username should have.

[0106] Helm provides a parameter `--kube-as-user` to specify the username used when submitting application releases. This parameter falls under the category of global flags, therefore, all Helm subcommands inherit this parameter, including `helm install`, `helm upgrade`, etc.

[0107] To make specific usernames more universal and not bound to specific users, the specific username can be a Kubernetes service account (ServiceAccount class username) to serve as a bot user. Considering that HelmChart may create resources in arbitrary namespaces or cluster-level resources, the specific username of the ServiceAccount class can also have cluster administrator privileges.

[0108] Next, we will introduce how to embed a specific username into a secondary Helm application.

[0109] There are several ways to embed a specific username into a secondary Helm application. One method provided in this application is as follows:

[0110] After the parameters are collected by the Helm command line, before further registration and calling subcommands, the specified username parameter is checked;

[0111] If the username for the `--kube-as-user` parameter is already provided by the parameter, no action is taken; otherwise, the specific username of the ServiceAccount class is set to the username for the `--kube-as-user` parameter.

[0112] This logic allows users to still use the `--kube-as-user` parameter originally provided by Helm when using a secondary Helm application, thus supporting compatibility with the traditional Helm Chart usage.

[0113] In addition to the `--kube-as-user` parameter, Helm also provides the `--kube-as-group` parameter, which can also be used to provide user information when submitting a Kubernetes API request, i.e., the group the user belongs to. Furthermore, the user's group information can be extracted in a validation webhook to verify which user group the request originated from. That is, the specific username can also be a specific user group name. And when a specific username is replaced with a specific user group name, the other processing procedures are similar.

[0114] Next, bind the specific username and the permissions that the specific username has in Kubernetes.

[0115] Here, a specific username is a ServiceAccount, and the permissions of that username can be granted through ClusterRoleBinding. To ensure that the specific username is known to as few technical or administrative personnel as possible, the creation of the ServiceAccount and ClusterRoleBinding can be included in a subcommand of the secondary development Helm. That is, using the Helm subcommand, Helm requests the creation of the ServiceAccount and the corresponding ClusterRoleBinding from Kubernetes. This subcommand always attempts to create the ServiceAccount and ClusterRoleBinding resources and ignores errors indicating that they already exist until creation is successful.

[0116] Unlike the aforementioned approach of specifying a built-in username for scenarios where no username is specified, when creating ServiceAccount and ClusterRoleBinding, the cluster administrator user, Kubernetes-admin, is typically required. This username is usually read by Helm based on the environment information if no username is specified via parameters or environment variables. To ensure that the Kubernetes-admin user can be correctly retrieved, the subcommands used to create ServiceAccount and ClusterRoleBinding can leave the username empty.

[0117] To reduce complexity, the ServiceAccount and ClusterRoleBinding to be created can be composed of byte arrays in Golang language. In the next step, they will be organized in the form of Chart Template and then used as parameters for the helminstall subcommand for creation.

[0118] Additionally, wrapping the creation of ServiceAccount and ClusterRoleBinding using a secondary Helm subcommand is just one feasible method. Similar approaches exist, such as preprocessing to check the existence of ServiceAccount and ClusterRoleBinding when a specific username is detected for resource modification via the Kubernetes API Servicer; if they don't exist, they are created. In other words, ServiceAccount and ClusterRoleBinding are not created in advance, but only when a specific username is needed.

[0119] Finally, we will introduce validation webhooks.

[0120] After implementing the aforementioned secondary development of Helm, a corresponding validation webhook is also needed for webbook:

[0121] Because it is impossible to predict what types of resources might be included in the Helm Chart, for each webhook, the APIServer will match resources using wildcard rules allowed by Kubernetes ValidatingWebhookConfiguration, including specifying the apiGroups, apiVersions, and resources of the resources in a wildcard manner, which describes what kind of resource objects need to be matched.

[0122] Since the creation, deletion, and modification of related resources are all done through Helm, the APIServer will configure CREATE, UPDATE, and DELETE as matching rules for operations for each webhook, that is, describe which operations on the resource object need to be matched.

[0123] To match all possible API requests for creating, modifying, or deleting Helm Charts, the webhook's namespace filter can be set to empty to match requests occurring in all namespaces, i.e., describing which namespaces' resource objects need to be matched.

[0124] To distinguish which Helm Charts are expected to be entirely handled by Helm for subsequent changes and releases, and which Helm Charts allow changes and releases in a non-Helm manner, the webhook will be configured with an object filter to filter resources with specific labels. Resources with these labels are considered to be those that are expected to be entirely handled by Helm for subsequent changes and releases.

[0125] The information mentioned above can be configured in `ValidatingWebhookConfiguration`, which, once configured, forms resource change configuration information. `ValidatingWebhookConfiguration` describes which API requests, meeting certain conditions, can be forwarded to the webhook for filtering by the K8sAPIServer. The object filter `objectSelector` in `ValidatingWebhookConfiguration` lists label matching rules. For example, the "managed-by" rule is inherent to Helm conventions, and its specific value in Helm V3 is "Helm"; the "all-in-helm" rule is a label rule required in this embodiment to distinguish Charts that are expected to undergo subsequent release changes via Helm. Here, it is only necessary to declare that such labels are required for distinguishing and matching; the specific key-value pair content of the labels can be set according to actual needs and will not be elaborated here.

[0126] In typical enterprise release processes, if an urgent issue arises requiring application fixes, there are often requirements for rapid response to emergency situations. Release process control solely through Helm may not be able to handle emergencies effectively and promptly. This is because writing new Helm chart packages requires additional time, and the transition of Helm chart packages from the development environment to the production environment may encounter constraints inherent in typical enterprise release processes, leading to prolonged processing times.

[0127] Therefore, this application's embodiment designs an emergency handling mechanism for authorization codes based on webhook and secondary development of Helm. Its design logic is as follows:

[0128] This allows application administrators or system administrators to add specific annotations to Kubernetes resource objects that have been committed via Helm chat. For example, users can add annotations via kubectl or a client (annotations are part of the metadata of Kubernetes resource objects; all resources can have annotations added to their metadata).

[0129] An annotation is essentially a string key-value pair. The key can be hardcoded by the developer during webhook compilation via static encoding, or allowed to be injected externally via environment variables, startup parameters, etc. The value of the annotation can be encoded. The encoded information is generated by grouping through a sufficiently long random seed. The encoded information (i.e., the aforementioned permission description information) includes at least: a) which specific authorized operator issued the code; b) the encoding date; c) the serial number of the code within the day of issuance; and d) the code obfuscation value and checksum.

[0130] The encoded information can be generated using a specific command-line signing tool (i.e., the aforementioned authorization encoding signing tool). Different signing tools can be distributed to different authorized operators. The signing tool and the webhook use the same random seed, allowing the encoding issued by the signing tool to be decoded and verified by the webhook, from which the portion contained in the aforementioned encoded information can be parsed.

[0131] After decoding the encoded information, the webhook uses operator information such as ID for authentication, checking if the operator is registered and has permission to access the current resource. The encoding date and sequence number are used to check the validity of the encoding. For example, an encoding for June 18th is invalid on June 19th. And if a sequence number of 3 has already been used on June 19th, then any encoding with a sequence number less than 3 is invalid. If the webhook successfully parses and verifies the information, it allows the relevant operator to process the current resource; otherwise, it considers the modification illegal and rejects the request.

[0132] Furthermore, because webhooks only validate annotation information in the resource object's metadata and do not erase the encoding after validation, different administrators with operational permissions can view previous annotations added to resource objects for emergency handling before performing new emergency actions. By decoding the annotations using a command-line signing tool, they can identify which authorized user performed the previous emergency action. This facilitates communication between different operators and allows for the recording and review of handled emergencies.

[0133] In addition to the specific usernames built into the secondary development Helm and the authorized user information injected into annotations through encoding, usernames prefixed with "system:serviceaccount:kube-system:" are also allowed. This is because such requests come from ServiceAccount users of relevant K8s components under the kube-system namespace. These requests are usually used to maintain the logical state of resources and belong to robot users of K8s internal running logic. In order for the relevant resources to be processed normally by K8s, API requests from such usernames are allowed to pass.

[0134] Based on the same inventive concept, embodiments of this application provide a resource object change control device, please refer to... Figure 3 The device includes:

[0135] The receiving module 301 is used to receive an application programming interface (API) request, wherein the API request contains resource information;

[0136] The matching module 302 is used to match the resource information with the configuration change information of each resource;

[0137] The determination module 303 is used to determine that if the resource information matches any resource change configuration information, the API request is used to request a change to the target resource object corresponding to the resource change configuration information;

[0138] Sending module 304 is used to send the API request to the webhook corresponding to the resource change configuration information, and the webhook determines whether the API request comes from the authorized change user of the target resource object;

[0139] The processing module 305 is used to process the API request based on the indication sent by the webhook regarding whether to respond to the API request, wherein the indication is sent by the webhook based on the determination result of whether the API request originates from the authorized user of the target resource object.

[0140] In some embodiments, the authorized change user includes an authorized Helm user, and

[0141] The webhook compares the requesting user information of the API request with the user information of the Helm user to determine whether the API request comes from the Helm user.

[0142] If it is determined that the API request originated from the Helm user, an indication to respond to the API request is sent.

[0143] In some embodiments, the user information of the Helm user is the username or user group set through the service account ServiceAccount, and the permissions corresponding to the Helm user's user information are Kubernetes cluster administrator permissions; it also includes:

[0144] The permission module 306 is used to determine, before matching the resource information with the resource change configuration information, that the user who initiated the API request has the corresponding resource operation permission for the requested resource object.

[0145] In some embodiments, the Helm user's user information and the cluster administrator permissions are created by the Helm user through a Helm subcommand before the first call to the Kubernetes API to change resources; or, the Helm user's user information and the cluster administrator permissions are created by the Helm user when the first call to the Kubernetes API to change resources is made.

[0146] In some embodiments, the authorized change user includes authorized non-Helm users, and

[0147] The webhook obtains the annotation content corresponding to the target annotation keyword from the resource information. The annotation content is obtained by encoding the permission description information of this change according to a preset encoding method.

[0148] If obtained, it is determined that the API request originated from the non-Helm user;

[0149] The obtained annotation content is decoded according to the preset decoding method corresponding to the preset encoding method to obtain the permission description information of this change;

[0150] The permission description information is compared with the preset permission range information of the non-Helm user to determine whether the change is within the change permission range of the non-Helm user;

[0151] If it is determined that the change is within the change permissions of the non-Helm user, then an instruction to respond to the API request is sent.

[0152] In some embodiments, the authorized change user includes each of the built-in users of Kubernetes, and

[0153] The webhook compares the requesting user information of the API request with the user information of the built-in users of each system to determine whether the API request comes from any built-in user of the system.

[0154] If it is determined that the API request originated from any built-in user of the system, an indication to respond to the API request is sent.

[0155] In some embodiments, the processing module 305 is specifically used for:

[0156] If the webhook sends an instruction in response to the API request, then the target resource object is modified based on the API request;

[0157] If the webhook sends an indication not to respond to the API request, then the API request is rejected and a reason for rejection is returned.

[0158] Based on the same inventive concept, this application provides an electronic device that can realize the function of the resource object change control device described above. Please refer to... Figure 4 The device includes a memory 401, one or more processors 402, and a bus 403.

[0159] The memory 401 is used to store computer programs executed by the processor 402. The memory 401 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0160] Memory 401 may be volatile memory, such as random-access memory (RAM); memory 401 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 401 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 401 may be a combination of the above-described memories.

[0161] Processor 402 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 402 is used to implement the resource object change control method in the above embodiments when calling the computer program stored in memory 401.

[0162] This application embodiment does not limit the specific connection medium between the memory 401 and the processor 402 described above. This application embodiment... Figure 4 The memory 401 and the processor 402 are connected via a bus 403, and the bus 403 is in Figure 4 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. Bus 403 can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0163] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the resource object change control methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the resource object change control method, the implementation of the above-described computer-readable storage medium can be found in the implementation of the method; repeated details will not be elaborated further.

[0164] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the resource object change control methods discussed above. Since the principle by which the above-described computer program product solves the problem is similar to that of the resource object change control method, the implementation of the above-described computer program product can refer to the implementation of the method, and repeated details will not be elaborated further.

[0165] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0166] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0167] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0168] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of user-operated steps to be executed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0169] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A change control method of a resource object, characterized by, The method comprises the following steps: receiving an application program interface (API) request, wherein the API request comprises resource information; matching the resource information with each resource change configuration information; if the resource information matches any resource change configuration information, determining that the API request is used to request a change to a target resource object corresponding to the resource change configuration information; sending the API request to a network hook (webhook) corresponding to the resource change configuration information, and determining, by the webhook, whether the API request is from an authorized change user of the target resource object; processing the API request based on an indication of whether to respond to the API request sent by the webhook, wherein the indication is sent by the webhook based on the determination of whether the API request is from the authorized change user of the target resource object; the authorized change user comprises an authorized non-Helm user, and the webhook obtains annotation content corresponding to a target annotation keyword from the resource information, wherein the annotation content is obtained by encoding permission description information of the current change in a preset encoding manner; if the annotation content is obtained, it is determined that the API request is from the non-Helm user; decoding the obtained annotation content in a preset decoding manner corresponding to the preset encoding manner to obtain the permission description information of the current change; comparing the permission description information with preset permission range information of the non-Helm user to determine whether the current change is within the change permission range of the non-Helm user; if it is determined that the current change is within the change permission range of the non-Helm user, an indication of responding to the API request is sent.

2. The method of claim 1, wherein, the authorized change user comprises an authorized Helm user, and the webhook compares request user information of the API request with user information of the Helm user to determine whether the API request is from the Helm user; if it is determined that the API request is from the Helm user, an indication of responding to the API request is sent.

3. The method of claim 2, wherein, The user information of the Helm user is a username or a user group set through a service account (ServiceAccount), and the permission corresponding to the user information of the Helm user is a cluster administrator permission of Kubernetes; before matching the resource information with each resource change configuration information, the method further comprises: determining that a user initiating the API request has corresponding resource operation permissions on the requested resource object.

4. The method of claim 3, wherein, The user information of the Helm user and the cluster administrator permission are created by the Helm user through a Helm subcommand before the Helm user first calls a Kubernetes API to change a resource, or the user information of the Helm user and the cluster administrator permission are created by the Helm user when the Helm user first calls a Kubernetes API to change a resource.

5. The method according to any one of claims 1 to 4, characterized in that, the authorized change user comprises each system built-in user of Kubernetes, and The webhook compares request user information of the API request with user information of the in-system users to determine whether the API request is from any in-system user; If it is determined that the API request is from any in-system user, an indication of responding to the API request is sent.

6. The method of claim 1, wherein, Based on the indication of whether to respond to the API request sent by the webhook, the API request is processed, including: If the indication of responding to the API request is sent by the webhook, the target resource object is changed based on the API request; If the indication of not responding to the API request is sent by the webhook, the API request is rejected, and a rejection reason is returned.

7. An apparatus for change control of a resource object, characterized by Comprise: A receiving module is configured to receive an application program interface (API) request, wherein the API request contains resource information; A matching module is configured to match the resource information with resource change configuration information; A determining module is configured to determine that the API request is used to request a change to a target resource object corresponding to the resource change configuration information if the resource information matches any resource change configuration information successfully; A sending module is configured to send the API request to a network hook (webhook) corresponding to the resource change configuration information, and determine whether the API request is from an authorized change user of the target resource object by the webhook; A processing module is configured to process the API request based on an indication of whether to respond to the API request sent by the webhook, wherein the indication is sent by the webhook according to a determination result of whether the API request is from the authorized change user of the target resource object; The authorized change user comprises an authorized non-Helm user, and The webhook obtains annotation content corresponding to a target annotation keyword from the resource information, wherein the annotation content is obtained by encoding permission description information of the current change in a preset encoding manner; If the annotation content is obtained, it is determined that the API request is from the non-Helm user; The obtained annotation content is decoded in a preset decoding manner corresponding to the preset encoding manner to obtain the permission description information of the current change; The permission description information and preset permission range information of the non-Helm user are compared to determine whether the current change is within the change permission range of the non-Helm user; If it is determined that the current change is within the change permission range of the non-Helm user, an indication of responding to the API request is sent.

8. The apparatus of claim 7, wherein, The authorized change user comprises an authorized Helm user, and The webhook compares request user information of the API request with user information of the Helm user to determine whether the API request is from the Helm user; If it is determined that the API request is from the Helm user, an indication of responding to the API request is sent.

9. The apparatus of claim 8, wherein, The user information of the Helm user is a username or a user group set by a service account ServiceAccount, and the permission corresponding to the user information of the Helm user is a cluster administrator permission of Kubernetes; and the method further comprises: The permission module is configured to determine whether a user initiating the API request has a corresponding resource operation permission on a requested resource object before matching the resource information with each resource change configuration information.

10. The apparatus of claim 9, wherein, The user information of the Helm user and the cluster administrator permission are created by the Helm user through a Helm subcommand before the Helm user first calls a Kubernetes API to change a resource, or the user information of the Helm user and the cluster administrator permission are created by the Helm user when the Helm user first calls the Kubernetes API to change the resource.

11. The apparatus of any of claims 7-10, wherein, The authorized change users include each system built-in user of Kubernetes, and The webhook compares the request user information of the API request with the user information of each system built-in user to determine whether the API request is from any system built-in user. If it is determined that the API request is from any system built-in user, an instruction of responding to the API request is sent.

12. The apparatus of claim 7, wherein, The processing module is specifically configured to: If the webhook sends the instruction of responding to the API request, the target resource object is changed based on the API request. If the webhook sends the instruction of not responding to the API request, the API request is rejected, and a rejection reason is returned.

13. An electronic device, comprising: comprise: a memory configured to store program instructions; a processor configured to invoke the program instructions stored in the memory and execute the steps of the method according to any one of claims 1-6.

14. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program comprises program instructions, which, when executed by a computer, cause the computer to execute the method according to any one of claims 1-6.

15. A computer program product, characterised in that, The computer program product comprises computer program code, which, when executed on a computer, causes the computer to execute the method according to any one of claims 1-6.

Images