Method, apparatus, and computer program product for preventing unauthorized capsule deployment in a cluster

Abstract

A method for checking integrity of an object to be deployed to a cluster is provided. The method detects a resource creation request. The method, in response to the request being an initial resource creation request for the object, verifies integrity of the object based on attributes in the request to create a release secret in the cluster for a positive integrity verification result of the object. A release secret represents a particular deployment configuration of an object on a cluster. The method, in response to the request being different from the initial resource request, checks whether the request corresponds to the particular deployment configuration of the object by checking against the release secret in the cluster. The method, in response to the request corresponding to a deployment of the object and the release secret existing in the cluster, creates a resource requested by the request in the cluster.

Description

Technical Field

[0001] This invention relates generally to information processing, and more specifically to preventing unauthorized Helm-based application package deployments and resource changes in a cluster. Background Technology

[0002] Kubernetes (also known as "k8s") is an open-source container orchestration system for automating application deployment, scaling, and management. Kubernetes is designed to provide a platform for automatically deploying, scaling, and operating application containers across host clusters.

[0003] The goal of cluster-side integrity is to verify the following: (a) that the encapsulated content is signed with the key of an authorized signer; and (b) that all permitted requests do not alter (tamper with) the resource creation request originating from the signed encapsulated content.

[0004] Existing methods for cluster-side integrity rely on client-side verification (e.g., Helm verification), but are vulnerable to attacks from malicious clients. Cluster-side verification is not easy because it is difficult to (a) identify the encapsulated content from individual permission requests on the cluster side, (b) distinguish the encapsulated permission request from all other permission requests, and (c) verify the integrity of permission requests because it requires resource creation requests that only the client can find. Summary of the Invention

[0005] According to an aspect of the present invention, a computer-implemented method is provided, executed by a server in a cluster, for checking the integrity of an object to be deployed to the cluster. The method includes detecting a resource creation request from a client. The method further includes: in response to the resource creation request being an initial resource creation request for the object, verifying the integrity of the object based on attributes in the resource creation request to create a release secret in the cluster for a positive integrity verification result of the object. The release secret represents a specific deployment configuration of the object on the cluster. The method further includes: in response to the resource creation request not being an initial resource request, checking whether the resource creation request corresponds to a specific deployment configuration of the object by comparing it with the release secret in the cluster. The method further includes: in response to the resource creation request corresponding to a deployment of the object and the existence of the release secret in the cluster, creating the resource requested by the resource creation request in the cluster.

[0006] According to another aspect of the present invention, a computer program product is provided. The computer program product includes a non-transitory computer-readable storage medium having program instructions embodied therein, which are executable by a computer to cause the computer to perform a method executed by a server in a cluster for checking the integrity of an object to be deployed to the cluster. The method includes detecting a resource creation request from a client. The method further includes: in response to the resource creation request being an initial resource creation request for the object, verifying the integrity of the object based on attributes in the resource creation request to create a release secret in the cluster for a positive integrity verification result of the object. The release secret represents a specific deployment configuration encapsulated on the cluster. The method further includes: in response to the resource creation request not being an initial resource request, checking whether the resource creation request corresponds to a specific deployment configuration of the object by checking against the release secret in the cluster. The method further includes: in response to the resource creation request corresponding to a deployment of the object and the existence of the release secret in the cluster, creating the resource requested by the resource creation request in the cluster.

[0007] According to another aspect of the invention, a server in a cluster is provided for checking the integrity of objects to be deployed to the cluster. The server includes a memory configured to store program code. The server further includes a hardware processor configured to run the program code to detect resource creation requests from clients. The hardware processor also runs the program code to, in response to the resource creation request being an initial resource creation request for the object, verify the integrity of the encapsulation based on attributes in the resource creation request to create a release secret in the cluster for a positive integrity verification result of the object, the release secret representing a specific deployment configuration of the object on the cluster. The hardware processor also runs the program code to, in response to the resource creation request being different from the initial resource request, check whether the resource creation request corresponds to the specific deployment configuration of the object by comparing it with the release secret in the cluster. The hardware processor also runs the program code to, in response to the resource creation request corresponding to the deployment of the encapsulation and the existence of the release secret in the cluster, create the resource requested by the resource creation request in the cluster.

[0008] These and other features and advantages will become apparent from the following detailed description of illustrative embodiments thereof, which will be read in conjunction with the accompanying drawings. Attached Figure Description

[0009] The following description will provide details of preferred embodiments with reference to the following figures, in which:

[0010] Figure 1 This is a block diagram illustrating an exemplary computing device according to an embodiment of the present invention;

[0011] Figure 2 This is a block diagram illustrating an exemplary Kubernetes architecture to which the invention can be applied, according to an embodiment of the invention;

[0012] Figure 3 This is a block diagram illustrating an exemplary computing environment according to an embodiment of the present invention;

[0013] Figure 4 This is a block diagram illustrating an exemplary Helm application encapsulation and deployment scenario according to an embodiment of the present invention;

[0014] Figure 5 This is a flowchart illustrating an exemplary method for preventing unauthorized Helm-based application encapsulation deployment and resource changes in a Kubernetes cluster according to an embodiment of the present invention;

[0015] Figure 6 This illustrates a method, according to an embodiment of the present invention, for preventing unauthorized Helm-based application encapsulation, deployment, and resource modifications in a Kubernetes cluster (e.g., Figure 7-8 A high-level block diagram of an exemplary system / method (shown);

[0016] Figure 7-8 An exemplary method for preventing unauthorized Helm-based application encapsulation deployment and resource changes in a Kubernetes cluster is illustrated according to an embodiment of the present invention.

[0017] Figure 9 This is a diagram illustrating exemplary pseudocode for releasing a secret according to an embodiment of the present invention;

[0018] Figure 10 This is a diagram illustrating exemplary pseudocode for data release during decoding according to an embodiment of the present invention;

[0019] Figure 11 This is a diagram illustrating the steps for implementing cluster-side integrity according to an embodiment of the present invention;

[0020] Figure 12 This is a diagram illustrating the cluster-side integrity implementation function according to an embodiment of the present invention;

[0021] Figure 13 This is a block diagram illustrating an illustrative cloud computing environment according to an embodiment of the present invention, having one or more cloud computing nodes communicating with a local computing device used by a cloud consumer; and

[0022] Figure 14This is a block diagram illustrating a set of functional abstraction layers provided by a cloud computing environment according to an embodiment of the present invention. Detailed Implementation

[0023] Embodiments of the present invention relate to preventing unauthorized Helm-based application encapsulation deployment and resource changes in a Kubernetes cluster.

[0024] Embodiments of the present invention provide a cluster-side integrity verification mechanism to satisfy the following conditions: (a) identifying any permission requests originating from a Helm installation; (b) identifying the encapsulated content from each individual permission request; and (c) detecting any unauthorized changes to permission requests without relying on client-side verification.

[0025] One or more embodiments of the present invention may involve identifying application package content from individual permission requests by detecting an initial permission request with a release secret and associating it with other permission requests corresponding to a specific package deployment to create individual resources included in the package. Attributes of the request may include, for example, a Helm release name and owner reference.

[0026] One or more embodiments of the present invention may use attributes in the request to distinguish permission requests corresponding to a specific encapsulation deployment from a large number of permission requests received at the cluster.

[0027] One or more embodiments of the present invention may use an integrity chain to verify the integrity of an application encapsulation deployment. For example, for each resource creation request, using a signed Helm encapsulation (template) and a signed deployment configuration, (a) the desired resource definition is created and (b) it is compared with the resource definition entering the permission request.

[0028] One or more embodiments of the present invention: (a) provide cluster-side integrity implementation on application packaging without relying on any client-side verification; (b) handle changes to application packaging and deployment; and (c) prevent unauthorized resource configuration changes to the application packaging throughout its lifetime. Furthermore, embodiments of the present invention perform integrity without altering the application bundle or packaging tools.

[0029] Figure 1 This is a block diagram illustrating an exemplary computing device 100 according to an embodiment of the present invention. The computing device 100 represents... Figure 2 The devices / nodes in the Kubernetes cluster 210 within the environment 200 shown. Computing device 100 is configured to prevent unauthorized Helm-based application encapsulation deployments and resource changes within the Kubernetes cluster.

[0030] Computing device 100 can be implemented as any type of computing or computer device capable of performing the functions described herein, including but not limited to computers, servers, rack-based servers, blade servers, workstations, desktop computers, laptop computers, notebook computers, tablet computers, mobile computing devices, wearable computing devices, network devices, web devices, distributed computing systems, processor-based systems, and / or consumer electronics devices. Alternatively or additionally, computing device 100 can be implemented as one or more computing racks, memory racks, or other racks, chassis, or other components that are physically separated from the computing device. Figure 1 As shown, computing device 100 illustratively includes processor 110, input / output subsystem 120, memory 130, data storage device 140, and communication subsystem 150, and / or other components and devices typically found in servers or similar computing devices. Of course, in other embodiments, computing device 100 may include other or additional components, such as those typically found in server computers (e.g., different input / output devices). Additionally, in some embodiments, one or more of the illustrative components may be incorporated into another component or otherwise formed part of another component. For example, in some embodiments, memory 130 or a portion thereof may be incorporated into processor 110.

[0031] Processor 110 may be implemented as any type of processor capable of performing the functions described herein. Processor 110 may be implemented as a single processor, multiple processors, one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more single-core or multi-core processors, one or more digital signal processors, one or more microcontrollers, or one or more other processors or one or more processing / control circuits.

[0032] Memory 130 may be embodied as any type of volatile or non-volatile memory or data storage device capable of performing the functions described herein. In operation, memory 130 may store various data and software used during the operation of computing device 100, such as operating systems, applications, programs, libraries, and drivers. Memory 130 is communicatively coupled to processor 110 via I / O subsystem 120, which may be embodied as circuitry and / or components facilitating input / output operations with processor 110, memory 130, and other components of computing device 100. For example, I / O subsystem 120 may be embodied as or otherwise include a memory controller hub, input / output control hub, platform controller hub, integrated control circuitry, firmware devices, communication links (e.g., point-to-point links, bus links, wires, cables, optical fibers, printed circuit board traces, etc.) and / or other components and subsystems to facilitate input / output operations. In some embodiments, the I / O subsystem 120 may be part of a system-on-a-chip (SOC) and may be integrated on a single integrated circuit chip along with the processor 110, memory 130 and other components of the computing device 100.

[0033] Data storage device 140 can be embodied as one or more devices of any type configured for short-term or long-term data storage, such as, for example, memory devices and circuitry, memory cards, hard disk drives, solid-state drives, or other data storage devices. Data storage device 140 can store program code to prevent unauthorized Helm-based application encapsulation deployment and resource changes within a Kubernetes cluster. The communication subsystem 150 of computing device 100 can be embodied as any network interface controller or other communication circuitry, device, or combination thereof capable of enabling communication between computing device 100 and other remote devices via a network. Communication subsystem 150 can be configured to implement such communication using any one or more communication technologies (e.g., wired or wireless communication) and associated protocols (e.g., Ethernet, InfiniBand®, Bluetooth®, Wi-Fi®, WiMAX, etc.).

[0034] As shown in the figure, the computing device 100 may also include one or more peripheral devices 160. Peripheral devices 160 may include any number of additional input / output devices, interface devices, and / or other peripheral devices. For example, in some embodiments, peripheral devices 160 may include a display, touchscreen, graphics circuitry, keyboard, mouse, speaker system, microphone, network interface, and / or other input / output devices, interface devices, and / or peripheral devices.

[0035] Of course, computing device 100 may also include other components (not shown), as readily expected by those skilled in the art, and certain components may be omitted. For example, different other input and / or output devices may be included in computing device 100, depending on the specific implementation of computing device 100, as readily understood by those skilled in the art. For example, different types of wireless and / or wired input and / or output devices may be used. Furthermore, additional processors, controllers, memories, etc., in different configurations may be utilized. Further, in another embodiment, a cloud configuration may be used. Given the teachings of the invention provided herein, those skilled in the art will readily conceive of these and other variations of system 100.

[0036] As used herein, the terms "hardware processor subsystem" or "hardware processor" can refer to a processor, memory (including RAM, cache, etc.), software (including memory management software), or a combination thereof that cooperate to perform one or more specific tasks. In useful embodiments, a hardware processor subsystem may include one or more data processing elements (e.g., logic circuitry, processing circuitry, instruction execution devices, etc.). These one or more data processing elements may be included in a central processing unit, a graphics processing unit, and / or a separate processor- or computing element-based controller (e.g., logic gates, etc.). A hardware processor subsystem may include one or more on-board memories (e.g., cache, dedicated memory array, read-only memory, etc.). In some embodiments, a hardware processor subsystem may include one or more memories (e.g., ROM, RAM, basic input / output system (BIOS), etc.) that may be on-board or off-board, or may be dedicated to use by the hardware processor subsystem.

[0037] In some embodiments, the hardware processor subsystem may include and execute one or more software elements. The one or more software elements may include an operating system and / or one or more applications and / or specific code for implementing a specified result.

[0038] In other embodiments, the hardware processor subsystem may include dedicated, specific circuitry that performs one or more electronic processing functions to achieve a specified result. Such circuitry may include one or more application-specific integrated circuits (ASICs), FPGAs, and / or PLAs.

[0039] Hardware processors can achieve Figure 2 and Figure 3 One or more elements in the cluster shown.

[0040] According to embodiments of the present invention, these and other variations of the hardware processor subsystem are also contemplated.

[0041] Figure 2This is a block diagram illustrating an exemplary Kubernetes architecture 200 to which the invention can be applied according to an embodiment of the invention.

[0042] The Kubernetes architecture 200 includes a Kubernetes master device 210. The Kubernetes master device 210 includes a controller 211, an ETCD 212, a scheduler 213, and a Kubernetes API server 214. The Kubernetes API server 214 includes an authentication phase 214A, an authorization phase 214B, and an authorization phase / (one or more) controllers 214C.

[0043] Users can initiate requests to create, update, or delete Kubernetes resources using client tools (kubect1, Helm, etc.). When a request reaches the Kubernetes API server 214, it goes through several stages: authentication 214A, authorization 214B, and permission control 214C. After the authentication and authorization steps, and before the persistence of the object specified in the request, the permission controller 214C intercepts the request. The permission controller 214C can modify or reject the request. The different components of these elements will be described in further detail below.

[0044] Along with the permission controller 214C, permission hooks can be used as part of the permission chain. Kubernetes defines permission hooks as HTTP callbacks and registers them based on resource type and request method. Custom permission hooks can handle incoming requests sent by the Kubernetes API server 214 and return their decision (allow or deny, etc.) to the Kubernetes API based on their logic. Furthermore, among the two types of permission hooks, the transformation permission hook can modify the approval request based on custom logic. An example would be that annotations can be added to resources that are being created or updated via an incoming request.

[0045] Figure 3 This is a block diagram illustrating an exemplary computing environment 300 according to an embodiment of the present invention.

[0046] Environment 300 includes multiple Kubernetes clusters (represented by reference numeral 310 in the figure) and multiple Helm client devices (represented by reference numeral 320 in the figure).

[0047] Communication between entities in environment 300 can be performed via one or more networks 330. For illustration, a wireless network 330 is shown. In other embodiments, any wired, wireless, and / or combination thereof can be used to facilitate communication between entities.

[0048] The Kubernetes cluster 310 can observe all incoming requests (permitted requests).

[0049] Helm client device 310 includes a package installer 310A, which includes: (a) a template engine 310A1 for creating resource creation requests from packaged content; and (b) a k8s API call handler 310A2 for processing k8s API calls to send resource creation requests to the k8s cluster.

[0050] Helm client device 310 can perform the following operations: (a) install Helm package; (b) upgrade Helm package.

[0051] Helm client device 310 provides the aforementioned functionality through the following components: (a) a command-line tool, Helm, which provides a user interface for all Helm functions; (b) a Helm encapsulation format, called a graph; and (c) an organized graph repository with pre-packaged graphs for popular open-source software projects.

[0052] Helm wrappers are called charts, and they consist of several YAML configuration files and some templates that are rendered into Kubernetes manifest files. Charts can include the following directories and / or files:

[0053] - charts: Manually managed chart dependencies can be placed in this directory, although it is generally better to use .yaml to dynamically link dependencies.

[0054] - templates / : This directory contains template files that are combined with configuration values ​​(from values.yam1 and command lines) and rendered into the Kubernetes manifest.

[0055] - Chart.yaml: A YAML file containing metadata about the chart, such as the chart name and version, maintainer information, related websites, and search keywords.

[0056] Helm customer tools enable us to verify the integrity and origin of a chart by comparing it to the corresponding origin record prior to deployment. The origin file includes (a) the chart's YAML content and the necessary information for verification, such as the chart's signature and the signature content.

[0057] In a Kubernetes cluster, a node (also called a worker or mini-company) is a machine in which containers (workloads) are deployed. Each node in the cluster runs a container runtime (such as Docker) and other components that communicate with the main components for network configuration of these containers.

[0058] Figure 4This is a block diagram illustrating an exemplary Helm application packaging and deployment scenario 400 according to an embodiment of the present invention.

[0059] Scenario 400 involves client 401 and Kubernetes cluster 440.

[0060] Client 401 includes encapsulation (Helm diagram) 410, deployment configuration (values.yaml) 420, and template engine / application installer (Helm) 430.

[0061] The Kubernetes cluster 440 includes ETCD 441, Kubernetes Application Programming Interface (API) 442, permission controller 443, and artifact (signature) repository 450.

[0062] The Helm-based encapsulation deployment creates a series of resource creation requests to the Kubernetes cluster 440.

[0063] Provide K8s resource definitions (YAML) 477 from template engine / installer 430 to Kubernetes API 442.

[0064] ETCD 441 is a persistent, lightweight, distributed key-value store that reliably stores cluster configuration data, representing the overall state of the cluster at any given point in time. Configuration data is available from ETCD 441 via API 442.

[0065] For example, API 442 can use JSON over HTTP, providing an interface to both internal and external Kubernetes. API 442 processes and validates REST requests and updates the state of API objects in ETCD 441, allowing clients to configure workloads and containers across worker nodes. In one or more embodiments, the invention intercepts incoming create requests to the Kubernetes API server. The invention then enforces integrity on the resources in the request by allowing or denying their creation.

[0066] The permission controller 443 enforces integrity. The permission controller 443 (a) checks whether the application encapsulation originates from a trusted source, i.e., whose owner identity can be verified and trusted using its signature, and (b) enforces its integrity by ensuring that the content has not been altered during transmission since it was encapsulated and signed. Additionally, after initial deployment, the permission controller 443 enforces the integrity of any configuration changes to the deployed application encapsulation or individual resources.

[0067] In the event of an integrity breach, permission controller 443 prevents the deployment of unauthorized workloads and changes to resources. Furthermore, permission controller 443 logs all enforcement actions for auditing purposes.

[0068] Controller Manager (in) Figure 2 The element shown as component 211 is essentially a coordination loop that drives the actual cluster state toward the desired cluster state, communicating with the API server to create, update, and delete the resources it manages (containers, server endpoints, etc.). The controller manager manages a set of core Kubernetes controllers. For example, one type of controller is the permission controller 443.

[0069] A description of Helm-based application deployment according to an embodiment of the present invention will now be given.

[0070] During the deployment of the application encapsulation, Helm renders a combination of the graph's template and deployment configuration into a Kubernetes manifest. Helm then deploys it via the Kubernetes API. This creates a release object (a "release secret" in Kubernetes) as a first step, representing the graph's specific configuration and deployment on the cluster.

[0071] A description of specific features of the invention will now be given.

[0072] In Kubernetes, a secret is an object that contains a small amount of sensitive data, such as passwords, tokens, or keys. This information can be placed separately in the Pod specification or image. Users can create secrets, and the system also creates some secrets.

[0073] A Helm "release secret" is a specific type of secret according to the invention, used to facilitate the release of a Helm package deployment in response to one or more verified release secrets. In embodiments of the invention, a release manifest is encoded and included as a release secret (see, for example...). Figure 6 Element 607).

[0074] Figure 5 This is a flowchart of an exemplary method 500 for preventing unauthorized Helm-based application encapsulation deployments and resource changes in a Kubernetes cluster, according to an embodiment of the present invention. The method is executed by an permission control hook within the cluster. While the method is described in relation to a Helm application for illustration and specificity, those skilled in the art will readily apply these teachings to other objects, such as, for example, deployments based on a single YAML and / or application bundles based on Kubernetes operators. For example, such as with... Figure 11 and Figure 12 The following description addresses these other object types in more detail.

[0075] At box 505, a resource creation request from the client is detected.

[0076] At box 510, in response to a resource creation request—an initial resource creation request for an object (continuing for this example, a wrapper, but which could be a single YAML-based deployment and / or a bundle of Kubernetes-based operators)—the integrity of the wrapper is verified based on attributes in the resource creation request, so that a release secret is created in the cluster for the positive integrity verification result of that wrapper. The release secret represents the specific configuration and deployment of the wrapper on the cluster. Box 510 corresponds to... Figure 7 Boxes 710-714, and processing Figure 6 Request 1 in the middle).

[0077] At box 515, in response to a resource creation request that is not an initial resource request, a check is performed against the release secret in the cluster to determine if the resource creation request corresponds to a specific deployment configuration. Box 515 corresponds to... Figure 7 Boxes 720-723, and processing Figure 6 Requests 2-4 in the document.

[0078] At box 520, in response to a resource creation request corresponding to a specific deployment configuration and the existence of a release secret in the cluster, the resource requested by the resource creation request is created in the cluster. Box 520 corresponds to... Figure 7 Boxes 720-723, and processing Figure 6 Requests 2-4 in the document.

[0079] In box 525, group content is identified and integrity is verified by examining owner references within the cluster. Box 525 corresponds to... Figure 7 The boxes 730-732, and processing Figure 6 Requests 5-6 in the document.

[0080] The following Figure 6-8 Method 500 is described in more detail.

[0081] Figure 6 This illustrates a method according to embodiments of the present invention for preventing unauthorized Helm-based application encapsulation deployment and resource changes in a Kubernetes cluster (e.g., Figure 7-8 A high-level block diagram of an exemplary system / method 600 (shown). Figure 6 It can even be an environment in which one or more embodiments of the invention can be implemented.

[0082] System / method 600 includes Helm wrapper 601 (e.g., Helm graph), deployment configuration (values.yaml) 602, graph repository 603, Helm client 604, k8s cluster 606, k8s API 605, wrapper release (manifest) 607, custom resource definition 608, and artifact repository 609.

[0083] Helm package 601 is signed by the package owner's key (or, for example, a notary service) to obtain signed package content 601A.

[0084] Deployment configuration 602 is signed by a signing authority to obtain signed deployment configuration 602A.

[0085] The Helm client publishes a 604 release (manifestation), from which the Helm client generates the following request:

[0086] Request 1 (Req.1): Create secret release

[0087] Request 2 (Req.2) Create a service account

[0088] Request 3 (Req.3) to create a deployment

[0089] The Kubernetes API 605 receives the aforementioned three requests and generates the following request:

[0090] Request 5: Create a replica set

[0091] Request 6: Create PoD

[0092] The resources are not limited to those described above, but are shown for illustrative purposes. In other embodiments, resources may include, for example, a ConfigMap.

[0093] The following request is generated due to owner dependency.

[0094] Owner -> Dependency (Creating an owner results in the creation of its dependencies)

[0095] Deployment -> Replica Set

[0096] Replica set -> Pod

[0097] Again, this is an internal mechanism of Kubernetes.

[0098] Figure 7-8 An exemplary method 700 for preventing unauthorized Helm-based application encapsulation deployment and resource changes in a Kubernetes cluster is shown according to an embodiment of the present invention.

[0099] At box 701, a Helm package 601 is provided.

[0100] In box 702, the Helm package 601 is signed with the package owner's key, and the Helm package 601 and the signature (i.e., the signed package 601A) are stored in the graph store 603.

[0101] At box 703, the signing authority signs the deployment configuration 602 to obtain the signed deployment configuration 602A and saves the signature as a CRD in cluster 606.

[0102] In block 710, in response to receiving request 1, an initial permission request with the release secret is detected and its integrity is verified.

[0103] In one embodiment, block 710 includes one or more of blocks 711-714.

[0104] In box 711, check the name of the resource in the permission request (e.g., sh.helm.release.v1.ac-test-app1.v1s).

[0105] In box 712, the signature on the package content retrieved from the graph store 603 is checked and matched with the Helm template definition in the signed Helm package 601A stored in the graph store 603.

[0106] In box 713, match the content between the signed deployment configuration and the deployment configuration in the request.

[0107] At box 714, create a release secret in the cluster.

[0108] At box 720, in response to receiving all requests 2-4, the encapsulated content is identified and its integrity is verified by matching the encapsulated content against existing release secrets in the cluster.

[0109] In one embodiment, block 720 includes one or more of blocks 721-723.

[0110] In box 721, check whether requests 2-4 all correspond to specific application package deployments by comparing them with the release secret in cluster 606.

[0111] In box 722, integrity is verified using the signed Helm wrapper 601A (template) and the signed deployment configuration by (a) creating the expected resource definition from the signed Helm wrapper (template) 601A and the signed deployment configuration 602A and (b) comparing the expected resource definition with the resource definition in the incoming permission request.

[0112] At box 723, create a resource with a special annotation in cluster 606. The special annotation indicates a positive integrity verification result.

[0113] In box 730, in response to receiving all requests 5-6, the group content is identified and its integrity is verified by checking the ownerReference in cluster 606.

[0114] In one embodiment, block 730 includes one or more of blocks 731-734.

[0115] At box 731, the request is checked to see if it corresponds to a specific application package deployment by examining the owner reference.

[0116] In box 732, in response to the owner being discoverable in cluster 606 and the integrity of the request being verified (by acknowledgment including special annotations), a signed Helm wrapper 601A is deployed in cluster 606 and all wrapper resources (secrets, services, deployments, etc.) are created. Box 732 handles requests for creating internal resources, such as replica sets and Pods for each of requests 5 and 6. Secrets and service accounts are handled through the steps described above.

[0117] In box 740, obtain the resource signature and verify the integrity of the updated resource in the request.

[0118] Figure 9 This is a diagram illustrating exemplary pseudocode 900 for releasing a secret according to an embodiment of the present invention.

[0119] Pseudocode 900 includes a "data.release" section 910, which contains an encoded release manifest 607, such as... Figure 10 As shown, the encoded release list is decoded.

[0120] Figure 10 This is a diagram illustrating exemplary pseudocode 1000 for data release during decoding according to an embodiment of the present invention.

[0121] Therefore, according to the present invention, by decoding the "data.release" portion 910 that releases the secret, as follows: Figure 10 The pseudocode 1000 shown can use data to identify subsequent requests. For example, in pseudocode 1000, in Figure 6 Request #4 in the document will use "templates / deployment.yaml".

[0122] In this article, relative to the following three cases (such as Figure 11 and Figure 12 (As shown in the image) describes the enforcement of integrity:

[0123] (1) Deployment based on a single YAML

[0124] (2) Application encapsulation based on Helm

[0125] (3) K8s operator-based application bundle - (This is similar to case #1, since deploying a K8s operator-based application bundle to a cluster involves creating a string of K8s manifests in YAML)

[0126] For the sake of illustration, the detailed description focuses on case #2. However, given the teachings of the invention provided herein, those skilled in the art can readily apply the invention to cases #1 and #3.

[0127] According to an embodiment of the present invention, a description of the K8s operator will now be given.

[0128] Kubernetes operators are the way to encapsulate, deploy, and automatically manage Kubernetes applications throughout their lifecycle. The operator SDK generates a bundle that includes several manifest files for deploying operators on a Kubernetes cluster.

[0129] One of the manifest files includes Custom Resources (CRs), which are Kubernetes endpoints added by operators. Custom Resource Definitions (CRDs) model the underlying business logic of the application. A CRD is a description of what constitutes a CR. Deploying operator bundles involves creating resources in the manifest file within the cluster.

[0130] According to embodiments of the present invention, an overview of cluster-side integrity enforcement will now be given.

[0131] This invention is configured to (a) provide cluster-side integrity enforcement of application wrappers without relying on any client-side verification, (b) handle changes to application wrappers and deployments, and (c) prevent unauthorized resource configuration changes to application wrappers throughout their lifetime. Furthermore, our method aims to enforce integrity without altering the application bundle or wrapper tools.

[0132] Figure 6 This illustrates the overall architecture for establishing integrity on application workloads deployed on a cluster (plaintext listings in YAML or Helm diagrams or k8s operators).

[0133] First, one or more embodiments of the present invention may require (a) a plaintext Kubernetes manifest in YAML format, (b) a Helm diagram, and (c) digital signatures of Kubernetes operators using certificates that can be recognized and approved by an authority. However, the present invention does not rely on whether client tools verify its integrity.

[0134] Secondly, on the cluster side, this invention enforces integrity on variations of application encapsulation deployed on the cluster. This invention (a) checks whether the application encapsulation originates from a trusted source, i.e., the owner's identity can be verified and trusted using their signature, and (b) enforces its integrity by ensuring that the content has not been altered during transmission since it was encapsulated and signed. Furthermore, after initial deployment, this mechanism enforces integrity on configuration changes to deployed application encapsulations or individual resources.

[0135] In the event of an integrity breach, this invention prevents the deployment of unauthorized workloads and changes to resources. Furthermore, this invention logs all enforcement actions for auditing purposes.

[0136] A description of the integrity enforcement of the use of the change hook permission controller will now be given.

[0137] One or more embodiments of the present invention encapsulate the core idea that enforces integrity on the cluster side and implements it as custom logic in a transformation permission hook in Kubernetes, such as... Figure 6 As seen in the image. This is because the deployment of all variants of the application encapsulation must go through a common gate at the cluster-k8s API server, such as... Figure 2 As shown, the cluster-k8s API server includes a hook in its permission control chain.

[0138] During deployment of a plaintext manifest in YAML, application wrappers, or Kubernetes operators, a built-in cluster-side enforcement mechanism encapsulated in the transformation permission hook intercepts requests received by the Kubernetes API server to impose integrity on them. It processes each incoming request and, based on... Figure 11 and 12 The logic provided in the code determines its decision (allow or deny). Furthermore, if the resource establishes its integrity, our method annotates the resource in the incoming request by adding the flag "IntegrityVerified=true".

[0139] The following describes three types of digital signatures for workloads: (a) plaintext Kubernetes manifests in YAML format; (b) Helm graphs; and (c) Kubernetes operators. These three cases are identified as Case A, Case B, and Case C, respectively.

[0140] According to an embodiment of the invention, a description of signing individual resources on the client side (Case A) will now be given.

[0141] Assume that a single resource inventory is intended to be created in YAML format on a cluster protected by the integrity enforcement mechanisms of this invention. For this purpose, this invention requires that the resource inventory be digitally signed and that the signature be available on the cluster. Similar to creation, updating existing resources also requires signing.

[0142] According to the implementation, signing resources (new resources or updates to existing resources) in a plaintext Kubernetes inventory requires the authorized owner to create a "ResourceSignature" on the cluster. A "ResourceSignature" is a special resource type. This stores the resource's signature in the cluster. Our cluster-side enforcement mechanism uses the "ResourceSignature" to verify the integrity of the resource.

[0143] To create a "ResourceSignature", our method provides a template. The resource signature template includes several key fields: "MESSAGE", "SIGNATURE", and "RSIG_SIGNATURE".

[0144] Authorizing entities need to populate the "ResourceSignature" template with the values ​​(name, API version, type, etc.) of the target resource they want to sign. A "MESSAGE" is generated by creating the encoded (base64) content of the target resource. They can use standard tools such as PKI and GnuPG to create a signature for the "SIGNATURE" field.

[0145] In addition, "ResourceSignature" includes another field called "RSIG_SIGNATURE," which refers to the signature of the "ResourceSignature" itself. This is necessary because the "ResourceSignature" is also a Kubernetes resource that needs to be created on the cluster, and its integrity must be enforced. To generate "RSIG_SIGNATURE," standard tools such as PKI, GnuPGk, etc., can be used. After completion, the authorizing entity must generate a signature for the canonical portion of the "ResourceSignature."

[0146] A description of signing the application package on the client side (Scenario B) according to an embodiment of the present invention will now be given.

[0147] The general structure of an application encapsulation includes: (a) a Kubernetes resource template; and (b) a deployment configuration.

[0148] Application package installers (e.g., Helm) render a combination of Kubernetes resource templates and deployment configurations into a YAML-formatted Kubernetes manifest. They then deploy these to the cluster by sending separate create requests to the Kubernetes API server. Therefore, signing the application package requires signing each manifest in the rendered Kubernetes manifest (i.e., creating a "resource signature") so that when it arrives at the Kubernetes API server as a request, cluster-side mechanisms can use its signature to enforce integrity. This approach requires modifications to the application package installer because the rendered Kubernetes manifest is an internal representation of the installer.

[0149] Our approach aims to avoid altering the application package installer or bundle. Therefore, we devise a method to sign the application package as a single artifact. For a specific instance, in the case of Helm, our approach uses an origin record that includes a signature for enforcing integrity (Case B).

[0150] According to an embodiment of the invention, a description of signing Kubernetes operators on the client side (Case C) will now be given.

[0151] Deploying a bundle of Kubernetes operators on a cluster involves creating resources (i.e., the "deployment" directory for the operator bundle) within the bundle, as specified in the Kubernetes manifest file. Therefore, this invention requires these manifest files to be digitally signed. Because these are plaintext Kubernetes statements in YAML format, the authorizing entity needs to generate a "ResourceSignature" using a template for each of them. Once the "ResourceSignature" manifest is generated, it needs to be created in the cluster where the operator is deployed.

[0152] Cluster-side integrity enforcement according to embodiments of the present invention will now be described in more detail.

[0153] Figure 11 and Figure 12 The pseudocode steps that may be involved in different embodiments of the cluster-side enforcement mechanism according to the present invention are illustrated. This mechanism handles different workloads, such as plaintext Kubernetes manifests in YAML format (Case A), Helm graphs (Case B), or Kubernetes operators (Case C). How the invention handles each case will now be described below.

[0154] (1) Input: Figure 11 The input shown is a request received by the Kubernetes API. The request carries information about the resource to be created, updated, or deleted (name, type, kind, namespace, etc.).

[0155] (2) Output: Figure 12This indicates whether the output is a "allow" or "deny" decision. In the "allow" case, the method can annotate the resource with tags to indicate that its integrity has been verified. Figure 12 Part R6 in the response. For rejection, it will include the reason in the response ( Figure 12 Part of R7).

[0156] (3) Internal requests of Kubernetes: such as Figure 11 As shown, the first step of the enforcement mechanism is to check whether the incoming request was generated by an internal Kubernetes component. This type of request can be identified based on request attributes such as the user or service account within Kubernetes, which is assumed to be trustworthy.

[0157] Next, for other requests, our method checks whether the operation is of type: create or update.

[0158] (4) Creation Request: For cases A, B, or C, the "HandleCreationRequest" ("Handle Creation Request") includes steps that enforce integrity on top of the creation request. We describe... Figure 12 The steps in parts R1, R2, R3, and R4.

[0159] (a) Handling the initial creation request ( Figure 12 R1 in the context: For case B, "HandleCreationRequest" first checks if the request indicates that the deployment should be started ( Figure 10 (Part R1 in the diagram). For example, during graph deployment, Helm sends a request to create a resource called "Release Secret". This is always the first request sent by the Helm installer to the Kubernetes API, thus marking the start of graph deployment. Furthermore, the first request carries information about the bundle (e.g., the resources within it). For example, a Helm Release Secret storage release—a running instance of the graph in the cluster.

[0160] The next step in part R1 enforces resource integrity in the initial request. More specifically, in the Helm case, the enforcer obtains the release name from the request. It then uses the release name to retrieve the corresponding graph and its origin record from the artifact repository. The mechanism enforces resource integrity in the initial request by using the signature in the origin record. Specifically, it checks (1) that the authorized owner has signed the graph found in the repository and (2) that its content has not been tampered with due to its binding. For (2), it compares the content of the released resource from the request with the expected content of the graph found in the repository to check for any tampering that has occurred during transport. If successful integrity enforcement is achieved, a release object is created in the cluster, and the installer then sends the remaining requests to the k8s API server. If the initial request fails the integrity check, the encapsulation installation terminates.

[0161] (b) Processing subsequent requests ( Figure 12 (R2 in the original text): In case B, after the initial object is created, there will be a set of subsequent requests for creating resources within the wrapper. For such resources, our method attempts to associate them with verified resource objects that indicate the wrapper installation was initiated (e.g., a "release secret" in the Helm case). Assume the graph includes a "ConfigMap" ("configuration graph") resource and Helm sends a request to the Kubernetes API to create it. This invention checks whether the "ConfigMap" can be associated with any verified "release secret" object in the cluster. Because a "release secret" includes all resources in the graph, it can be checked whether it includes a specific resource by matching its characteristics (such as name, type, API version, etc.).

[0162] (c) Handling requests using dependent resources ( Figure 12 R3 in part: Steps in part R3 involve the creation of resources that depend on other resources. Kubernetes maintains owner dependencies between some of its resources. For example, a "ReplicaSet" is owned by a collection of "Pods," and a "ReplicaSet" is owned by a "Deployment." Each dependent object has "ownerReferences" metadata that refers to the owning object. For dependent resources in cases A, B, or C, the present invention verifies their integrity if an owner with integrity verification can be found in the ownership hierarchy.

[0163] (d) Utilize other resources to process the request ( Figure 12(R4 in the original text): For other resource creation requests not partially covered by R1, R2, or R3, our method requires that the "ResourceSignature" be available in the cluster before creating the resource. If the "ResourceSignature" can be found (by matching resource attributes such as name, type, API version, etc.), it specifies the resource's integrity in the request. The "ResourceSignature" includes a "MESSAGE" field, which contains the encoded content of the resource manifest. This invention compares the content of the resource manifest in the request with the "MESSAGE" field in the corresponding "ResourceSignature". If a successful match is achieved, the method of this invention verifies the integrity of the resource in the request.

[0164] (5) Update request ( Figure 12 (R5 in the original text) For resource updates, one or more embodiments of the present invention may require a "ResourceSignature" to exist in the cluster before updating the cluster. For a resource update request, the present invention locates the corresponding "ResourceSignature". If a resource signature exists, it is matched against the contents of the changed resource list in the request and the "MESSAGE" field in the corresponding "ResourceSignature". If successful, it confirms the integrity of the changed resource and allows the changes to be retained. If not, the present invention rejects the resource update on the grounds of "no valid signature found".

[0165] It should be understood that while this disclosure includes a detailed description of cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0166] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services), which can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0167] The features are as follows:

[0168] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0169] Extensive network access: Capabilities are available through networks and accessed via standard mechanisms that facilitate the use of heterogeneous thin client platforms or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0170] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. Location independence exists because consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0171] Rapid flexibility: The ability to provide capacity quickly and flexibly, automatically scaling down and up rapidly in some situations to scale up rapidly. For consumers, the available supply capacity often appears unlimited and can be purchased in any quantity at any time.

[0172] Measuring services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the providers and consumers of the services being utilized.

[0173] The service model is as follows:

[0174] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from different client devices via thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with possible exceptions such as limited user-specific application configuration settings.

[0175] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created by the consumer or acquired using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environment.

[0176] Infrastructure as a Service (IaaS): The capabilities offered to consumers are processing, storage, networking, and other basic computing resources that enable consumers to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0177] The deployment model is as follows:

[0178] Private cloud: A cloud infrastructure that operates solely for an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0179] Community cloud: A cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0180] Public cloud: Makes cloud infrastructure available to the public or large industry groups and is owned by an organization that sells cloud services.

[0181] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported together (e.g., cloud bursting for load balancing between clouds).

[0182] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure comprising a network of interconnected nodes.

[0183] See now Figure 13 The diagram illustrates an illustrative cloud computing environment 1350. As shown, the cloud computing environment 1350 includes one or more cloud computing nodes 1310 that can communicate with local computing devices used by cloud consumers, such as, for example, personal digital assistants (PDAs) or cellular phones 1354A, desktop computers 1354B, laptop computers 1154C, and / or automotive computer systems 1354N. The nodes 1310 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 1350 to provide infrastructure, platforms, and / or software as services that cloud consumers do not need to maintain on their local computing devices. It should be understood that... Figure 13 The types of computing devices 1354A-N shown are intended to be illustrative only, and computing node 1310 and cloud computing environment 1350 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0184] See now Figure 14 This demonstrates the 1350 cloud computing environment ( Figure 13 This provides a set of functional abstractions. It should be understood beforehand. Figure 14The components, layers, and functions shown are intended to be illustrative only, and embodiments of the invention are not limited thereto. As described, the following layers and corresponding functions are provided:

[0185] The hardware and software layer 1460 includes hardware and software components. Examples of hardware components include: a host 1461; a server 1462 based on a RISC (Reduced Instruction Set Computer) architecture; a server 1463; a blade server 1464; a storage device 1465; and a network and network components 1466. In some embodiments, the software components include network application server software 1467 and database software 1468.

[0186] The virtualization layer 1470 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 1471; virtual storage 1472; virtual network 1473, including virtual private network; virtual application and operating system 1474; and virtual client 1475.

[0187] In one example, management layer 1480 may provide the following functionalities: Resource Provisioning 1481 Provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 1482 Provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security Provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User Portal 1483 Provides access to the cloud computing environment for consumers and system administrators. Service Level Management 1484 Provides allocation and management of cloud computing resources to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 1485 Provides pre-scheduling and procurement of cloud computing resources, anticipating future requirements for those resources according to the SLA.

[0188] The workload layer 1490 provides examples of functionalities that can be leveraged in a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: mapping and navigation 1491; software development and lifecycle management 1492; virtual classroom education delivery 1493; data analytics and processing 1494; transaction processing 1495; and prevention of unauthorized encapsulated deployments 1496.

[0189] This invention can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0190] Computer-readable storage media can be a tangible means for retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0191] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0192] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as SMALLTALK, C++, etc.) and conventional procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)) or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to perform aspects of the invention.

[0193] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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-readable program instructions.

[0194] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, 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, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium storing the instructions comprises an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0195] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, such that the instructions executed on the computer, other programmable apparatus, or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0196] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than indicated in the figures. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0197] References to the invention in this specification as "one embodiment" or "embodiment" and other variations thereof mean that a particular feature, structure, characteristic, etc., described in connection with that embodiment is included in at least one embodiment of the invention. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places throughout the specification, as well as any other variations, do not necessarily refer to the same embodiment.

[0198] It should be understood that, for example, in the cases of “A / B,” “A and / or B,” and “at least one of A and B,” the use of any of the following “ / ,” “and / or,” and “at least one of” is intended to include selecting only the first listed item (A), or only the second listed item (B), or selecting both options (A and B). As another example, in the cases of “A, B, and / or C” and “at least one of A, B, and C,” this wording is intended to cover only the selection of the first listed option (A), or only the selection of the second listed option (B), or only the selection of the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed items (A and C), or only the second and third listed items (B and C), or all three options (A, B, and C). It will be apparent to those skilled in the art that this can be extended for many of the listed items.

[0199] Preferred embodiments of the systems and methods have been described (these are intended to be illustrative and not restrictive), and it should be noted that modifications and variations can be made by those skilled in the art based on the foregoing teachings. Therefore, it should be understood that changes may be made to the specific embodiments disclosed within the scope of the invention as outlined in the appended claims. Various aspects of the invention, having the details and features required by patent law, have thus been described, and the claimed and desired protection by a patent certificate is set forth in the claims.

Claims

1. A computer-implemented method, executed by a server in a cluster, for checking the integrity of objects to be deployed to the cluster, comprising: Detect resource creation requests from clients; In response to the resource creation request being an initial resource creation request for the object, the integrity of the object is verified based on the attributes in the resource creation request to create a release secret in the cluster for the positive integrity verification result of the object, the release secret representing the specific deployment configuration of the object on the cluster; In response to a resource creation request that differs from the initial resource request, the resource creation request is checked against the release secret in the cluster to determine whether the resource creation request corresponds to the specific deployment configuration of the object. as well as In response to the resource creation request corresponding to the deployment of the object and the existence of the release secret in the cluster, the resource requested by the resource creation request is created in the cluster.

2. The computer-implemented method according to claim 1, wherein, Verifying the integrity of the object includes: Check the name of the resource requested in the resource creation request; Check the signature on the object content retrieved from the repository; and The template definition in the signature on the object is matched with the definition in the resource creation request; and in response to the discovery of the resource name and the signature, the signed deployment configuration in the database is matched with the deployment configuration in the resource creation request.

3. The computer-implemented method according to claim 1, wherein, Checking whether the resource creation request corresponds to the specific deployment configuration of the object includes: Create the expected resource definition from the signature template and the specific deployment configuration; and The expected resource definition is compared with the resource definition in the resource creation request.

4. The computer-implemented method according to claim 1, further comprising: The resource creation request is checked to see if the identifier of the owner of the object's content is found in the cluster; In response to finding the owner's identifier in the cluster, verify the integrity of the object and create the resource with an annotation in the cluster, the annotation indicating a positive integrity verification result; and In response to the fact that the annotation is not found in the resource, any incoming update requests are blocked.

5. The computer-implemented method according to claim 1, wherein, The integrity verification of the object is performed only at the cluster.

6. The computer-implemented method according to claim 1, wherein, The integrity of the object is verified using the transformation permission hook in the cluster.

7. The computer-implemented method according to claim 6, wherein, The change allows the hook to intercept the resource creation request to perform an integrity check on the resource creation request.

8. The computer-implemented method according to claim 1, wherein, Verifying the integrity of the object using the secret release is performed on both the creation and updating of the object.

9. The computer-implemented method according to claim 1, wherein, Verifying the integrity of the object includes adding annotations to indicate the positive integrity verification results of the encapsulation.

10. The computer-implemented method according to claim 1, wherein, The integrity of the object is verified using a resource signature.

11. The computer-implemented method according to claim 10, wherein, The signature was detected as an artifact associated with the specific deployment configuration.

12. The computer-implemented method according to claim 1, wherein, The release of secret storage represents the release of the running instance of the object in the cluster.

13. The computer-implemented method according to claim 1, wherein, Verifying the integrity of the object includes: Check if the authorized owner has signed the chart corresponding to the object and found in the repository; and Check whether the content of the chart has been tampered with since the chart's content was bundled.

14. The computer-implemented method according to claim 13, wherein, Checking whether the content of the chart has been tampered with includes comparing the content from the release source in the resource creation request with the expected content of the chart found in the repository.

15. The computer-implemented method according to claim 1, further comprising: The changes are handled by ensuring that changes in object encapsulation and deployment are associated with a signature from the repository or the cluster and by verifying the signature from the repository or the cluster.

16. The computer-implemented method according to claim 1, wherein, The object is a software package.

17. The computer-implemented method according to claim 1, wherein, The object is a deployment based on a single YAML non-markup language (YAML).

18. The computer-implemented method according to claim 1, wherein, The object is an operator-based application bundle.

19. A computer program product comprising program instructions executable by a computer to cause the computer to perform the method according to any preceding claim, the method being executed by a server in a cluster to check the integrity of objects to be deployed to the cluster.

20. A server in a cluster for checking the integrity of objects to be deployed to the cluster, the server comprising: The memory is configured to store program code; as well as The hardware processor is configured to run the program code to: Detect resource creation requests from clients; In response to the resource creation request being an initial resource creation request for the object, the integrity of the encapsulation is verified based on the attributes in the resource creation request to create a release secret in the cluster for the positive integrity verification result of the object, the release secret representing the specific deployment configuration of the object on the cluster; In response to a resource creation request that differs from the initial resource request, the resource creation request is checked against the release secret in the cluster to determine whether the resource creation request corresponds to the specific deployment configuration of the object. as well as In response to the resource creation request corresponding to the encapsulated deployment and the release secret existing in the cluster, the resource requested by the resource creation request is created in the cluster.

Images