Cluster resource signature verification

Abstract

Methods and systems for validating resource definitions include simulating an original resource definition to identify at least one change made to the original resource definition by a management service. A signature of a received resource definition is generated, omitting portions of the received resource definition corresponding to the identified at least one change. The signature of the received resource definition is compared to the signature of the original resource definition to find a match and validate the received resource definition. Responsive to finding a match, the received resource definition is implemented.

Description

Background Technology

[0001] This invention relates generally to cluster management and security, and more specifically, to signing the static portions of a resource definition.

[0002] Cloud computing systems now run a wide variety of mission-critical applications, including those from financial and government agencies. Such systems can be implemented in various ways, including any of several container orchestration systems. The sensitive nature of these applications necessitates strong security measures, such as preventing resources from being tampered with before implementation. Summary of the Invention

[0003] A method for verifying a resource definition includes: simulating the original resource definition to identify at least one change made to the original resource definition by a management service; generating a signature of the received resource definition, omitting portions of the received resource definition corresponding to the at least one identified change; comparing the signature of the received resource definition with the signature of the original resource definition to find a match and verifying the received resource definition; and implementing the received resource definition in response to finding a match.

[0004] A system for verifying a resource definition includes a hardware processor and a memory storing computer program code. When the computer program code is executed by the hardware processor, it causes the hardware processor to emulate the original resource definition to identify at least one change made to the original resource definition by a management service, generate a signature of the received resource definition, omit portions of the received resource definition corresponding to at least one identified change, compare the signature of the received resource definition with the signature of the original resource definition to find a match and verify the received resource definition, and implement the received resource definition in response to finding a match.

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

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

[0007] Figure 1 This is a block diagram of a Platform as a Service (PaaS) system including resource signature verification according to an embodiment of the present invention;

[0008] Figure 2 This is a block diagram of a separate processing node in a PaaS system according to an embodiment of the present invention, which performs signature verification on the received resource definition.

[0009] Figure 3This is a block diagram / flowchart of a method for verifying a received resource definition by comparing it with the signature of the corresponding original resource definition, according to an embodiment of the present invention.

[0010] Figure 4 This is a block diagram / flowchart of a method for installing and using requested resources in a PaaS system including signature verification, according to an embodiment of the present invention.

[0011] Figure 5 This is a block diagram of a signature verification system according to an embodiment of the present invention. The signature verification system emulates the original resource definition to identify a whitelist that changes during the processing of the resource definition, and uses the whitelist to verify the received resource definition.

[0012] Figure 6 This is a diagram illustrating different types of resource definitions and possible changes therein according to embodiments of the present invention;

[0013] Figure 7 This is a diagram of a cloud computing environment based on this principle; and

[0014] Figure 8 It is a diagram of the abstract model layer based on this principle. Detailed Implementation

[0015] The given cluster resources may change during use. For example, the original resource may differ from the actual resource implemented. This presents a challenge when applications require digital signatures of resources before installation. In such cases, installation may fail because the signed resource is different from the one being installed.

[0016] To address this issue, a resource whitelist can be generated to identify the unchanging parts of a resource. This can be achieved by simulating the resource multiple times to identify which attributes within the resource remain unchanged and which change. A signature file based on the static parts of the resource can then be generated. During installation, the signature can be verified by examining only the static attributes within the resource.

[0017] Now for reference Figure 1The diagram illustrates a Platform as a System (PaaS) system 100. User 102 has a workload to execute on the distributed computing platform. User 102 communicates with manager system 104 and provides information about the workload, including the number and type of processing nodes 106 required to execute the workload. Information provided to manager system 104 includes, for example, the number of processing nodes 106, processor type, operating system, execution environment, storage capacity, random access memory capacity, network bandwidth, and any other points the workload might require. User 102 may also provide manager system 104 with specific images or containers to be stored in a registry there. It should be understood that PaaS system 100 may include thousands of processing nodes 106, each of which may be idle or busy at any given time depending on the workload executed by PaaS system 100. It should also be understood that although a single manager system 104 is shown, multiple such manager systems 104 may exist, with multiple registries distributed across PaaS system 100. While this can mitigate the limited bandwidth issue at the registry by providing alternative image sources, very large deployments will still result in latency. Furthermore, although the manager system 104 is presented as a single device, it should be understood that scheduling can be performed in a location separate from the image registry.

[0018] Before and during workload execution, the manager system 104 determines which processing nodes 106 will use which images. The manager system 104 then distributes the images to the processing nodes 106 based on its own internal logic, such as node and resource availability at provisioning time. The manager system 104 and the PaaS system 100 are capable of handling multiple different workloads from multiple different users 102, such that the availability of specific resources will generally depend on what happens within the PaaS system 100.

[0019] As used herein, provisioning refers to the process by which resources in PaaS system 100 are allocated to user 102 and prepared for execution. Therefore, provisioning includes the determination by manager system 104 of which processing nodes 106 will be used for the workload, as well as any configuration steps required for image transfer and preparation of processing nodes 106 for workload execution. The processing nodes 106 selected by manager system 104 then install the image and perform any necessary configurations for executing the workload. Execution, then triggered by manager system 104, user 102, or any other appropriate source, can then proceed.

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

[0021] Now for reference Figure 2 Additional details of processing node 106 are shown below. Processing node 106 includes a hardware processor 202, a memory 204, and a network interface 206. The network interface 206 is configured to communicate with the manager system 104 and other processing nodes 106 as needed, using any suitable wired or wireless communication media and protocols. Processing node 106 also includes one or more functional modules, which in some embodiments may be implemented as software stored in memory 204 and executed by the hardware processor 202. In other embodiments, one or more of the functional modules may be implemented as one or more discrete hardware components, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0022] Processing node 106 may include one or more containers 208, such as those already assigned to it by manager system 104. Specifically, it is conceivable that each container 208 represents a different operating environment. Each container 208 includes a set of software applications, configuration files, workload datasets, and any other information or software required to execute a specific workload. Containers 208 are stored in memory 204 and are instantiated and deactivated by container orchestration engine 210 when needed. It should be understood that, in general, the operating system of processing node 106 resides outside of the containers 208. Therefore, each container 208 interfaces with the same operating system kernel, reducing the overhead required to execute multiple containers simultaneously. Furthermore, containers 208 typically do not communicate with each other outside of a specifically agreed-upon interface, thereby reducing security concerns.

[0023] Container 208 can access a distributed file system shared among multiple processing nodes 106. Container 208 can communicate with container orchestration engine 210 to mount persistent volume 218. Upon receiving a request from container 208, container orchestration engine 210 communicates with storage provisioning engine 212. When storage provisioning engine 212 receives a directory request, it provides a local directory mount point to the distributed file system, notifies quota manager 214 and synchronization engine 216 to complete the quota / isolation and information synchronization process, and provides the directory back to container orchestration engine 210.

[0024] Quota manager 214 interacts with storage provisioning engine 212 to set quotas and isolation for persistent volume 218. Quota manager 214 obtains information from storage provisioning engine 212 regarding successful mounts to the distributed file system and can be implemented, for example, as a kernel module, where system calls monitor the directory size and isolation of persistent volume 218. Quota manager 214 interacts with storage provisioning engine 212 to address volumes exceeding its quota. For example, quota manager 214 can perform actions based on policies, such as stopping write operations when the directory size exceeds a predetermined quota. When persistent volume 218 is created, the amount of quota allocated to individual directories is determined. Isolation is used to ensure that persistent volume 218 cannot be used by other processes.

[0025] Synchronization engine 216 communicates with synchronization engines 216 in other processing nodes 106. Synchronization engine 216 transmits information related to how persistent volume 218 is used, including quota information and isolation information. Quotas and isolation are set on a per-host basis, so synchronization engine 216 transmits this information to other hosts to ensure consistency between different nodes.

[0026] Persistent volume 218 is represented in this document as a directory in the local file system of processing node 106. These directories can then be mount points 220 of the distributed file system. When container 208 accesses persistent volume 218, file system operations are transferred to and from the distributed file system, making data in the distributed file system accessible to the container. In particular, it should be noted that multiple containers 208 can share access to the distributed file system in this manner.

[0027] In some cases where signature verification is required before a resource can be installed, the container orchestration engine 210 communicates with the signature verifier 222. The signature verifier compares the resource to be installed (e.g., the description of container 208) with the signature of that resource. If the signatures match, the resource can be installed and executed. If the signatures do not match, the signature verifier 222 rejects the request and prevents the resource from being installed or executed.

[0028] Now for reference Figure 3 The diagram illustrates a method for verifying resource definitions. Box 302 generates a signature for the original resource definition. In a specific, non-limiting example, the KUBERNETES® system can be used for container management. In such an embodiment, resources can be defined using a text-based file in "YAML" format. The following are exemplary YAML resource definitions that can be used in the KUBERNETES system:

[0029] abiVersion:v1

[0030] kind:ConfigMap

[0031] data:

[0032] sample-data:abc

[0033] Security-enabled:true

[0034] It should be understood that this resource definition is purely exemplary and, alternatively, any suitable resource can be used. The signature can be generated using any suitable signature algorithm, such as a signature key. Such algorithms can include, for example, RSA, DSA, and ECDSA. Alternatively, other container management systems may also be considered.

[0035] Box 304 receives a request to install a resource, for example, using a resource definition file that has been modified by the KUBERNETES system. For example, the modified resource definition could be changed as follows, where the differences are indicated:

[0036] abiVersion:v1

[0037] kind:ConfigMap

[0038] metadata: #This line was added.

[0039] uid:a2b4e4f2-3ca8-a996 #This line is added.

[0040] data:

[0041] sample-data:abc

[0042] Security-enabled:true

[0043] default-config:def # This line was added.

[0044] If a signature is generated for the original resource definition, and the signature verifier 222 later attempts to verify the signature used for the entire modified resource definition, the verification will fail because the modified resource definition is different. To address this issue, the signature verifier 222 ignores those lines in the modified resource definition that are expected to be changed by the system. After excluding these lines, the signature verifier 222 generates signatures for the remaining lines and compares them with the signature of the original resource definition. If a match is found, the modified resource definition can be verified.

[0045] While these mutable rows and fields can be predetermined by analyzing the KUBERNETES system software, software updates can cause changes to how resource definitions are handled and may add new types of information that were not previously considered. To address this, changes can be analyzed at runtime on a per-resource basis to build a whitelist of current changes.

[0046] Therefore, box 306 can, for example, use the KUBERNETES “DryRun” feature to simulate the original resource definitions to generate one or more simulated resource definitions, which can be modified in a manner similar to changes made to the KUBERNETES system for the actual implementation. By simulating resources, rather than relying on static whitelists, changes to the underlying software can be adapted immediately. By comparing the simulated resource definitions with the original resource definitions, box 308 can identify lines that have been changed in the simulated resource definitions or lines that have been added to the simulated resource definitions. At least two simulations can be run, but a larger number of runs can provide better results.

[0047] Box 310 generates a signature for the modified resource definition, ignoring any lines indicated as changed in Box 308. Box 312 compares the signature of the original resource definition with the signature of the modified resource definition. If Box 314 finds that the two signatures do not match, then Box 316 rejects the resource. In this case, signature verifier 222 instructs container orchestration engine 210 to reject the request to install the resource. If the two signatures match, then Box 318 causes signature verifier 222 to instruct container orchestration engine 210 to install the resource.

[0048] Now for reference Figure 4 A method for performing tasks using a PaaS system (such as system 100 described above). Box 402 generates a workload. For example, a workload may include any suitable software to perform any purpose, such as processing financial transactions or performing statistical computations on large datasets. Box 404 determines what resources will be needed to perform the workload. For example, Box 404 may determine how many instantiations may be needed, what operating system and supporting software can be used, and what containers can be used. Box 406 sends requests for these resources to the manager system 104.

[0049] Box 408 verifies the resource signature as described above. If verification is successful, box 410 installs the requested resource, and box 412 uses the installed resource to perform the workload. In the event that verification of the resource signature fails in box 408, user 102 can return to audit their resource request to identify and resolve discrepancies. Failed signature verification can indicate an attacker's attempt to tamper with the resource.

[0050] This invention can be a system, method, and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0051] Computer-readable storage media can be tangible devices capable of 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 the following: 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 optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures with 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 through fiber optic cables), or electrical signals transmitted through wires.

[0052] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, 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 respective computing / processing device.

[0053] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration 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 procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the 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, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing the status information of the computer-readable program instructions.

[0054] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will 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.

[0055] These computer-readable program instructions may be provided to a processor of a 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 can direct a computer, programmable data processing apparatus, and / or other devices to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0056] 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 a computer-implemented process, such that the instructions, which execute 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.

[0057] References to "one embodiment" or "embodiment" and other variations of the invention in this specification 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.

[0058] 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 cover the selection of only the first listed option (A), or only the second listed option (B), or the selection of both options (A and B). As a further example, in the cases of “A, B, and / or C” and “at least one of A, B, and C,” such wording is intended to include selecting only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or selecting all three options (A, B, and C). This can be extended to many of the listed items, as will be apparent to those skilled in the art and related fields.

[0059] 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. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may occur in a different order than indicated in the figures. For example, two blocks shown consecutively may actually be implemented as a single step, executed simultaneously, substantially simultaneously, with partial or complete time overlap, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0060] As used herein, the terms "hardware processor subsystem" or "hardware processor" can refer to a processor, memory, 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.), which 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 that may be on-board or off-board, or may be dedicated to the use of the hardware processor subsystem (e.g., ROM, RAM, basic input / output system (BIOS), etc.).

[0061] In some embodiments, the hardware processor subsystem may include and execute one or more software elements. These software elements may include an operating system and / or one or more applications and / or specific code to achieve a specified result.

[0062] In other embodiments, the hardware processor subsystem may include dedicated, specialized 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.

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

[0064] Now for reference Figure 5 Additional details of the signature verifier 222 are shown below. It should be understood that the signature verifier 222 can be implemented as part of the processing node 106 as described above, as part of the manager system 104, as a standalone system running on separate hardware, or in any other suitable manner. If the signature verifier 222 runs on separate hardware, it may include a hardware processor, memory, and a communication interface (not shown). If the signature verifier 222 is co-located with the manager system 104 or the processing node 106, it may share the hardware resources of those systems.

[0065] Signature verifier 222 receives and stores a copy of the original resource definition 502. This original resource definition 502 may differ from the original resource definition due to differences introduced by the PaaS system (e.g., KUBERNETES software). Resource simulator 504 (e.g., KUBERNETES's "DryRun" function) runs one or more simulations of the original resource definition 502 to generate a simulated resource 506. Whitelist generator 508 analyzes the simulated resource 506 to identify portions of the definition that have changed while it is being processed by the PaaS system. Whitelist generator 508 thereby generates a signature whitelist 510, which can identify rows and fields in the resource definition that have changed during normal operation.

[0066] The requested resource definition 511 is processed by the signature generator 512, for example, using the same function used to generate the original resource signature 516, and using a signature whitelist 510 to omit portions of the requested resource definition 511 that have changed during normal operation. The signature generator 512 thus produces the requested resource signature 514. At signature comparison 518, the requested resource signature 514 is compared with the original resource signature 516. The verifier 520 determines whether the requested resource definition is valid and can be installed based on any differences between the two signatures.

[0067] Now for reference Figure 6 The diagram illustrates a comparison of various resource definitions. The original resource definition is shown in box 502, which displays information about the specified resource. Box 506 shows a set of simulated resource definitions based on the original resource definition 502. Parts that change during simulation are shown underlined; these additions are introduced by the PaaS system for its own purposes and generally do not affect the functionality of the final resource installation.

[0068] The requested resource definition is shown in box 511. During verification, those additions shown in simulation definition 506 are located within the requested resource definition 511 and are omitted during signature verification. Excluding these additions, the remaining content of the requested resource definition 511 matches the content of the original resource definition 502, and therefore verification is successful.

[0069] Instead, malicious resource definition 602 is shown. Similar to the requested resource definition 511, any identified modifiable lines are omitted during signature verification. However, another line is introduced by the malicious actor and is shown in bold. If this malicious resource definition 602 is submitted for signature verification, the mismatch caused by the introduced line will result in verification failure, thus preventing the installation of the malicious resource.

[0070] Cloud computing is a service delivery model for enabling 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) that can be rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0071] The characteristics are as follows:

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

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

[0074] 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 allocated and reallocated based on demand. Location independence has significance because consumers typically do not control or know the exact location of the resources provided, but can specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0075] Rapid Flexibility: In some cases, the ability to scale outwards and inwards quickly and flexibly can be provided. For consumers, the available capacity often appears unlimited and can be purchased in any quantity at any time.

[0076] 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.

[0077] The service model is as follows:

[0078] Software as a Service (SaaS): The capability offered to consumers is the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from various client devices through 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.

[0079] Platform as a Service (PaaS): This provides consumers with the ability to deploy consumer-created or acquired applications onto cloud infrastructure using programming languages ​​and tools supported by the provider. 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 environments.

[0080] Infrastructure as a Service (IaaS): This provides consumers with the capability to deliver processing, storage, networking, and other basic computing resources that enable them to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0081] The deployment model is as follows:

[0082] Private cloud: Cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist inside or outside a building.

[0083] Community cloud: 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.

[0084] Public cloud: Cloud infrastructure available to the general public or large industrial groups and owned by organizations that sell cloud services.

[0085] 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).

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

[0087] Now for reference Figure 7The illustration depicts a cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 that can communicate with local computing devices used by cloud consumers, such as personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 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 50 to provide infrastructure, platform, and / or software as a service, without requiring cloud consumers to maintain resources on their local computing devices. It should be understood that... Figure 7 The types of computing devices 54A-N shown are for illustrative purposes only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device on any type of network and / or network-addressable connection (e.g., using a web browser).

[0088] Now for reference Figure 8 This demonstrates a cloud computing environment of 50 ( Figure 7 This provides a set of functional abstractions. It should be understood beforehand that... Figure 8 The components, layers, and functions shown are for illustrative purposes only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0089] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a host 61; a server 62 based on a RISC (Reduced Instruction Set Computer) architecture; a server 63; a blade server 64; a storage device 65; and a network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0090] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0091] In one example, management layer 80 can provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking when utilizing resources in the cloud computing environment, as well as billing or invoicing for consuming these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, and protection for data and other resources. User Portal 83 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 84 provides cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources, where future needs are anticipated according to the SLA.

[0092] Workload layer 90 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 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis and processing 94; transaction processing 95; and signature verification 96.

[0093] Preferred embodiments of cluster resource signature verification have been described (these are intended to be illustrative and not restrictive). 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 can be made to the specific embodiments disclosed, and these changes are within the scope of the invention as summarized by the appended claims. Thus, aspects of the invention have been described in the details and features required by patent law, and the claimed and desired patentable aspects are set forth in the appended claims.

Claims

1. A computer-implemented method for validating resource definitions, comprising: Use the DryRun feature of the container manager to simulate the original resource definition defined by the container manager to generate a simulated resource definition that conforms to at least one change made by the container manager to the original resource definition. The at least one change is identified by comparing the original resource definition with the simulation resource definition; The portion of the received resource definition corresponding to at least one identified change is omitted to generate a signature of the received resource definition; The signature of the received resource definition is compared with the signature of the original resource definition to find a match and verify the received resource definition; and In response to finding the match, the received resource definition is implemented.

2. The method of claim 1, wherein simulating the original resource definition comprises running the simulation of the original resource definition at least twice.

3. The method of claim 1, wherein generating a signature of the received resource definition comprises removing a portion of the received resource definition corresponding to at least one identified change from the received resource definition, and then generating a signature from the remaining portion.

4. The method of claim 1, further comprising receiving a received resource definition from a user, wherein simulating the original resource definition is performed after receiving the received resource definition.

5. The method of claim 4, further comprising generating a signature of the original resource definition, wherein generating the signature of the original resource definition is performed before receiving the received resource definition.

6. The method of claim 1, wherein the original resource definition and the received resource definition are text-based YAML files.

7. The method of claim 1, wherein implementing the received resource definition includes installing the corresponding resource on the local processing node.

8. A computer program product for validating resource definitions, the computer program product comprising program instructions executable by a hardware processor to cause the hardware processor to: Use the DryRun feature of the container manager to simulate the original resource definition defined by the container manager to generate a simulated resource definition that conforms to at least one change made by the container manager to the original resource definition. The at least one change is identified by comparing the original resource definition with the simulation resource definition; The portion of the received resource definition corresponding to at least one identified change is omitted to generate a signature of the received resource definition; The signature of the received resource definition is compared with the signature of the original resource definition to find a match and verify the received resource definition; and In response to finding the match, the received resource definition is implemented.

9. The computer program product of claim 8, wherein simulating the original resource definition includes running the simulation of the original resource definition at least twice.

10. The computer program product of claim 8, wherein generating a signature of the received resource definition comprises removing a portion of the received resource definition corresponding to at least one identified change from the received resource definition, and then generating a signature from the remaining portion.

11. The computer program product of claim 8, wherein the program instructions are further executable by a hardware processor to cause the hardware processor to receive a received resource definition from a user, wherein emulation of the original resource definition is performed after the received resource definition is received.

12. The computer program product of claim 11, wherein the program instructions are further executable by a hardware processor to cause the hardware processor to generate a signature of the original resource definition, wherein generating the signature of the original resource definition is performed before receiving the received resource definition.

13. The computer program product of claim 8, wherein implementing the received resource definition includes installing the corresponding resource on a local processing node.

14. A system for validating resource definitions, comprising: Hardware processor; as well as A memory that stores computer program code, which, when executed by the hardware processor, causes the hardware processor to: Use the DryRun feature of the container manager to simulate the original resource definition defined by the container manager to generate a simulated resource definition that conforms to at least one change made by the container manager to the original resource definition. The at least one change is identified by comparing the original resource definition with the simulation resource definition; The portion of the received resource definition corresponding to at least one identified change is omitted to generate a signature of the received resource definition; The signature of the received resource definition is compared with the signature of the original resource definition to find a match and verify the received resource definition; and In response to finding the match, the received resource definition is implemented.

Images