Cluster Resource Signature Verification

Abstract

A method and system for validating a resource definition includes simulating an original resource definition to identify at least one change made to the original resource definition by a management service. A signature of the received resource definition is generated omitting a portion of the received resource definition corresponding to the at least one identified change. The signature of the received resource definition is compared to the signature of the original resource definition to find a match and to validate the received resource definition. In response to finding a match, the received resource definition is executed.

Description

[Technical Field]

[0001] The present invention relates generally to cluster management and security, and more particularly to signing static portions of resource definitions. [Background technology]

[0002] Cloud computing systems currently power a variety of mission-critical applications, including those in financial and government organizations. Such systems may be run in a variety of ways, including using one of several container orchestration systems. The highly sensitive nature of such applications implies a need for strong security, for example, to prevent resources from being tampered with prior to execution. Summary of the Invention

[0003] A method for validating a resource definition includes simulating an original resource definition to identify at least one change made to the original resource definition by a management service. A signature of the received resource definition is generated omitting a portion of the received resource definition corresponding to the at least one identified change. The signature of the received resource definition is compared with the signature of the original resource definition to find a match and to validate the received resource definition. In response to finding a match, the received resource definition is executed.

[0004] A system for validating a resource definition includes a hardware processor and memory storing computer program code that, when executed by the hardware processor, causes the hardware processor to: simulate 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 while omitting a portion of the received resource definition corresponding to the 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 to validate the received resource definition; and, in response to finding a match, execute the received resource definition.

[0005] These and other features and advantages will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.

[0006] The following description provides details of a preferred embodiment with reference to the following figures: [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram of a Platform as a Service (PaaS) system including resource signature verification, according to an embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram of an individual processing node in a PaaS system that performs signature verification on received resource definitions, according to an embodiment of the present invention. [Figure 3] 3 is a block / flow diagram of a method for verifying a received resource definition against a signature of a corresponding original resource definition according to an embodiment of the present invention. [Figure 4]1 is a block / flow diagram of a method for installing and using a requested resource in a PaaS system including signature verification, according to an embodiment of the present invention. [Figure 5] FIG. 1 is a block diagram of a signature verification system that simulates an original resource definition to identify a whitelist of changes that occurred during handling of the resource definition, and uses this whitelist to verify a received resource definition, in accordance with an embodiment of the present invention. [Figure 6] FIG. 2 illustrates different types of resource definitions and the changes that can occur within these resource definitions, according to an embodiment of the present invention. [Figure 7] This is a diagram of a cloud computing environment based on the present principles. [Figure 8] FIG. 1 is a diagram of abstraction model layers in accordance with present principles. DETAILED DESCRIPTION OF THE INVENTION

[0008] A given cluster resource may change during use. For example, the original resource may differ from the resource that actually runs. This presents a challenge when an application requires that resources be digitally signed before installation. In such cases, installation may fail because the signed resource is not identical to the installed resource.

[0009] To address this issue, a resource whitelist may be generated to identify portions of the resource that never change. This may be achieved by simulating the resource multiple times to identify attributes within the resource that remain constant and attributes that change. A signature file based on the static portion of the resource can then be generated. At install time, the signature can be verified by looking only at attributes within the static resource.

[0010] Referring now to FIG. 1 , a diagram of a Platform as a Service (PaaS) system 100 is shown. A user 102 has a workload to execute on a distributed computing platform. The user 102 communicates with a manager system 104 and provides information about the workload, including the number and type of processing nodes 106 that will be required to execute the workload. The information provided to the 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 aspects that may be required for the workload. The user 102 can further provide a specific image or container to the manager system 104 for storage in the manager system's 104 registry. It should be understood that the PaaS system 100 can include thousands of processing nodes 106, each of which can be idle or busy at any time, depending on the workload being executed by the PaaS system 100. While a single manager system 104 is shown, it should be understood that there may be multiple such manager systems 104, and multiple registries distributed throughout the PaaS system 100. This can mitigate the issue of limited bandwidth at the registry by providing an alternative image source, but very large deployments will still introduce delays. Additionally, while the manager system 104 is shown as a single device, it should be understood that scheduling can be performed at a location separate from the image registry.

[0011] Before and during workload execution, manager system 104 determines which processing nodes 106 will use which images. Thus, manager system 104 distributes images to processing nodes 106 according to its own internal logic, for example, based on node and resource availability at the time of provisioning. Manager system 104 and PaaS system 100 can handle multiple different workloads from multiple different users 102, such that the availability of a particular resource depends entirely on what is happening in PaaS system 100.

[0012] Provisioning, as the term is used herein, refers to the process by which resources of the PaaS system 100 are allocated to users 102 and prepared for execution. Thus, provisioning includes a determination made by the manager system 104 as to which processing elements 106 will be used for the workload, as well as the transmission of images and any configuration steps necessary to prepare the processing nodes 106 for execution of the workload. The processing nodes 106 selected by the manager system 104 then install the images and perform any configuration required for the workload. Execution can then proceed, triggered by the manager system 104, by the users 102, or by any other suitable source.

[0013] Although this disclosure includes a detailed description of cloud computing, it should be understood in advance that implementation of the teachings recited herein is not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

[0014] 2, additional details about the processing node 106 are shown. The 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 with other processing nodes 106, as appropriate, using any suitable wired or wireless communication medium and protocol. The processing node 106 also includes one or more functional modules that, in some embodiments, may be implemented as software stored in the 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 separate hardware components, for example, in the form of an application-specific integrated chip or a field-programmable gate array.

[0015] A processing node 106 may include one or more containers 208, distributed across the processing node 106 by, for example, manager system 104. Specifically, each container 208 is intended to represent a distinct operating environment. Each container 208 includes a set of software applications, configuration files, workload datasets, and any other information or software necessary to execute a unique workload. Containers 208 are stored in memory 204 and are instantiated and closed as needed by container orchestration engine 210. It should be understood that, as a general matter, the operating system of a processing node 106 resides outside of the containers 208. Thus, each container 208 interfaces with the same operating system kernel, reducing the overhead required to run multiple containers simultaneously. Meanwhile, containers 208 generally do not communicate with each other outside of specifically agreed-upon interfaces, reducing security concerns.

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

[0017] The quota manager 214 interacts with the storage provisioning engine 212 to set quotas and isolation for persistent volume directories 218. The quota manager 214 obtains information about successful mounts of the distributed file system from the storage provisioning engine 212 and can be implemented, for example, as a kernel module, through system calls to monitor the directory size and isolation of persistent volumes 218. The quota manager 214 interacts with the storage provisioning engine 212 to handle volumes that exceed their quotas. For example, the quota manager 214 can implement policy-based actions, such as aborting write operations, when the size of a directory exceeds a specified quota. The quota amount for each directory is determined when the persistent volume 218 is created. Isolation is used to ensure that the persistent volume 218 cannot be used by other processes.

[0018] The synchronization engine 216 communicates with synchronization engines 216 on other processing nodes 106. The synchronization engine 216 communicates information about how the persistent volume 218 is being used, including quota and isolation information. Quotas and isolation are set per host, so the synchronization engine 216 communicates this information to other hosts to ensure consistency across different nodes.

[0019] Persistent volumes 218 are represented herein as directories in the local file system of a processing node 106. These directories may therefore be mount points 220 in the distributed file system 106. When a container 208 accesses a persistent volume 218, file system operations are transmitted to and from the distributed file system 106, enabling the container to access data in the distributed file system 106. Note in particular that multiple containers 208 can share access to the distributed file system in this manner.

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

[0021] Referring now to FIG. 3, a method for validating a resource definition is shown. Block 302 generates a signature of the original resource definition. In one specific, non-limiting example, a KUBERNETES® system may be used for container management. In such an embodiment, resources may be defined using text-based files in "YAML" format. The following is an exemplary YAML resource definition that may be used in a KUBERNETES® system:

[0022] abiVersion: v1

[0023] kind: ConfigMap

[0024] data:

[0025] sample-data: abc

[0026] Security-enabled: true

[0027] It should be understood that this resource definition is purely exemplary and that any suitable resource may be used instead. The signature may be generated by any suitable signature algorithm, for example, using a signing key. Such algorithms may include, for example, RSA, DSA, and ECDSA. Additionally, the use of other container management systems is also contemplated.

[0028] Block 304 receives a request to install a resource using a resource definition file modified by, for example, a KUBERNETES® system. For example, the modified resource definition may be changed as follows, with the differences indicated:

[0029] abiVersion: v1

[0030] kind: ConfigMap

[0031] metadata: #This line was added

[0032] uid: a2b4e4f2-3ca8-a996 #This line was added

[0033] data:

[0034] sample-data: abc

[0035] Security-enabled: true

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

[0037] If a signature for the original resource definition is generated and signature verifier 222 later attempts to verify the signature for the entire modified resource definition, the verification will fail because the modified resource definition is not identical. To address this issue, signature verifier 222 ignores those lines of the modified resource definition that are expected to be changed by the system. With these lines excluded, signature verifier 222 generates a signature for the remaining lines and compares this signature with the signature of the original resource definition. If there is a match, the modified resource definition can be verified.

[0038] These mutable lines and fields may be predetermined by analysis of the KUBERNETES® system software, but software updates may cause changes to how resource definitions are handled or add new types of information not previously intended. To address this, changes may be analyzed on a per-resource basis at runtime to build a whitelist of current changes.

[0039] Thus, block 306 may simulate the original resource definition, for example, using the KUBERNETES® “DryRun” feature, to generate one or more simulated resource definitions, which may be modified in a manner similar to the changes that would be made by the KUBERNETES® system for actual execution. By simulating resources rather than relying on a static whitelist, changes to the underlying software can be immediately accommodated. By comparing the simulated resource definition with the original resource definition, block 308 can find lines in the simulated resource definition that have been changed or added to the simulated resource definition. At least two simulations may be run, but a larger number may yield better results.

[0040] Block 310 generates a signature for the modified resource definition, ignoring any lines indicated in block 308 as changed. Block 312 compares the signature of the original resource definition with the signature of the modified resource definition. If block 314 finds that the two signatures do not match, block 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, block 318 causes signature verifier 222 to instruct container orchestration engine 210 to install the resource.

[0041] 4, a method for performing a task using a PaaS system, such as system 100 described above, is illustrated. Block 402 generates a workload. For example, the workload may include any suitable software for performing any purpose, such as processing financial transactions or performing statistical calculations on large data sets. Block 404 determines what resources are needed to perform the workload. For example, block 404 may determine how many instantiations may be needed, what operating systems and supporting software may be used, and what containers may be used. Block 406 sends a request for these resources to manager system 104.

[0042] Block 408 verifies the resource signature, as described above. If the verification is successful, block 410 installs the requested resource, and block 412 performs the workload using the installed resource. If block 408 cannot verify the resource signature, user 102 may return to inspecting the resource request to identify and address any discrepancies. Failure to verify the signature may indicate an attempt by an attacker to tamper with the resource.

[0043] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0044] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, 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 versatile disk (DVD®), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein should not be construed as being signals that are transitory in nature, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through wires.

[0045] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0046] Computer-readable program instructions for carrying out operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuit devices, or object-oriented programming languages ​​such as Smalltalk®, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone 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 scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry devices, including, for example, programmable logic devices, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute computer readable program instructions by utilizing state information of the computer readable program instructions to individualize the electronic circuitry devices to implement aspects of the present invention.

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

[0048] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, the instructions of which execute on a processor of the computer or other programmable data processing apparatus to produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium such that the computer-readable storage medium comprises an article of manufacture including instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and may direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0049] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device such that the instructions, executing on the computer, other programmable apparatus, or other device, cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-executed process to perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0050] References herein to "one embodiment" or "an embodiment" of the invention, as well as other variations thereof, mean that a particular feature, structure, characteristic, etc. described in connection with an embodiment is included in at least one embodiment of the invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment," as well as any other variations, appearing in various places throughout this specification are not necessarily all referring to the same embodiment.

[0051] It should be recognized that the use of any of the following terms " / ," "...and / or," and "at least one of" is intended to encompass, for example, the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B), in the cases of "A / B," "A or B or both," and "at least one of A and B." As a further example, in the cases of "A, B, or C or a combination thereof" and "at least one of A, B, and C," such language is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and second listed options (A and B), or the selection of the first and third listed options (A and C), or the selection of the second and third listed options (B and C), or the selection of all three options (A, B, and C). This may be extended to many of the items listed, as would be readily apparent to one skilled in the art.

[0052] The flowcharts and block diagrams in the figures 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, including one or more executable instructions for performing specified logical functions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be accomplished as a single step performed concurrently, substantially concurrently, in a partially or fully time-overlapping manner, or the blocks may sometimes be performed in the reverse order, depending on the functionality involved. It is also 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 by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

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

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

[0055] 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, or PLAs, or a combination thereof.

[0056] These and other variations of hardware processor subsystems according to embodiments of the present invention are also contemplated.

[0057] 5, additional details about the signature verifier 222 are shown. It should be understood that the signature verifier 222 may execute as part of the processing node 106, as described above, as part of the manager system 104, as an independent system running on separate hardware, or in any other suitable manner. If the signature verifier 222 executes on separate hardware, the signature verifier 222 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, the signature verifier 222 may share the hardware resources of these systems.

[0058] The 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 inconsistencies introduced by the PaaS system, for example, by the KUBERNETES® software. A resource simulator 504 (e.g., the KUBERNETES® "DryRun" feature) runs one or more simulations of the original resource definition 502 to generate simulated resources 506. A whitelist generator 508 analyzes the simulated resources 506 to identify portions of the definition that change when the simulated resources 506 are handled by the PaaS system. From this, the whitelist generator 508 generates a signature whitelist 510, which may identify lines and fields in the resource definition that changed during normal operation.

[0059] Requested resource definition 511 is processed by signature generator 512, e.g., using the same function used to generate original resource signature 516, using signature whitelist 510 to omit portions of requested resource definition 511 that have changed during normal operation. Signature generator 512 then produces requested resource signature 514. Requested resource signature 514 is compared to original resource signature 516 in signature comparison 518. Verifier 520 makes a determination, based on any discrepancy between the two signatures, as to whether the requested resource definition is legitimate and may be installed.

[0060] Referring now to Figure 6, a comparison of various resource definitions is shown. The original resource definition is shown as block 502, which shows information specifying the resource. Block 506 shows a set of simulated resource definitions based on the original resource definition 502. Changes made during the simulation are 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.

[0061] The requested resource definition is shown in block 511. During verification, these additions shown in simulated definition 506 are located in requested resource definition 511 and omitted during signature verification. Excluding these additions, the remaining content of requested resource definition 511 matches the content of original resource definition 502, resulting in successful verification.

[0062] In contrast, malicious resource definition 602 is shown. As with requested resource definition 511, any identified mutable lines are omitted during signature verification. Nevertheless, additional lines, shown in bold, have been introduced by a malicious actor. If this malicious resource definition 602 were submitted for signature verification, the mismatch caused by the introduced lines would cause the verification to fail, preventing installation of the malicious resource.

[0063] 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) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0064] The characteristics are as follows:

[0065] On-Demand Self-Service: Cloud customers can unilaterally provide computing power, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider.

[0066] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0067] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with dynamic allocation and reallocation of various physical and virtual resources on demand. Location independence is meant in that consumers generally have no control or knowledge over the exact location of the resources provided, but may have the ability to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0068] Rapid Elasticity: Capacity can be provisioned quickly, elastically, and sometimes automatically to quickly scale out, and can be released quickly to quickly scale in. To the consumer, the capacity available to provision often appears unlimited and can be purchased at any time in any quantity.

[0069] Measured Services: Cloud systems automatically control and optimize resource utilization by leveraging metering capabilities at several levels of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource utilization can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services used.

[0070] The service model is as follows:

[0071] Software as a Service (SaaS): The consumer is provided with the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface, such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or possibly individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0072] Platform as a Service (PaaS): The ability provided to a consumer is to deploy consumer-created or acquired applications, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the environment that hosts the applications.

[0073] Infrastructure as a Service (IaaS): The capability provided to a customer is the provision of processing, storage, networking, and other basic computing resources on which the customer can deploy and run any software, which may include operating systems and applications. The customer does not manage or control the underlying cloud infrastructure, but does have control over the selection of operating systems, storage, deployed applications, and possibly limited control over networking components (e.g., host firewalls).

[0074] The implementation model is as follows:

[0075] Private Cloud: The cloud infrastructure is operated solely for the organization. It may be managed by the organization or a third party and may be on-site or off-site.

[0076] Community Cloud: Cloud infrastructure is shared by several organizations to support a unique community of shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by the organization or a third party and may be on-site or off-site.

[0077] Public cloud: The infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0078] Hybrid Cloud: A cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are tied together by standard or proprietary technologies that allow for the portability of data and applications (e.g., cloud bursting for load balancing between clouds).

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

[0080] Referring now to FIG. 7, an illustrative cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud users, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, may communicate. The nodes 10 may also communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as private, community, public, or hybrid clouds, or combinations thereof, as described above. This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service without the need for cloud users to maintain resources on their local computing devices. It is understood that the types of computing devices 54A-N shown in FIG. 7 are intended to be illustrative only, and that the computing node 10 and cloud computing environment 50 can communicate with any type of computerized device over any type of network, or network-addressable connection, or both (e.g., using a web browser).

[0081] Referring now to Figure 8, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 7) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 8 are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0082] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0083] The virtualization layer 70 provides an abstraction layer within which examples of virtual entities such as virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75 can be provided.

[0084] In one example, management layer 80 may provide the functions described below. Resource provisioning 81 dynamically procures computing and other resources utilized to perform tasks within the cloud computing environment. Metering and pricing 82 tracks costs as resources are utilized within the cloud computing environment and bills or invoices for the usage of these resources. In one example, these resources may include application software licenses. Security verifies the identity of cloud users and tasks and protects data and other resources. User portal 83 provides users and system administrators with access to the cloud computing environment. Service level management 84 allocates and manages cloud computing resources to meet required service levels. Service level agreement (SLA) planning and fulfillment 85 pre-provisions and procures cloud computing resources in anticipation of future requirements according to SLAs.

[0085] The workload layer 90 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and signature verification 96.

[0086] Having described a preferred embodiment of cluster resource signature verification (intended to be illustrative and not limiting), it is noted that modifications and variations may be made by those skilled in the art in light of the above teachings. It is therefore to be understood that variations may be made to the particular embodiments disclosed that are within the scope of the invention as outlined by the appended claims. Thus, having described aspects of the invention with the detail and precision required by the patent laws, what is claimed and desired to be protected by Letters Patent is set forth in the appended claims.

Claims

1. 1. A computer-implemented method for validating a resource definition, comprising: 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 a portion 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 to verify the received resource definition; responsive to finding the match, executing the received resource definition; A method comprising:

2. The method of claim 1 , wherein the original resource definition and the received resource definition are defined for a container manager.

3. The method of claim 2 , wherein the at least one identified change is introduced by the container manager during handling of any resource definition.

4. The method of claim 2 , wherein simulating the original resource definition includes using a DryRun feature of the container manager to run the original resource definition.

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

6. 2. The method of claim 1, wherein generating the signature of the received resource definition includes removing the portion of the received resource definition that corresponds to the at least one identified change from the received resource definition before generating a signature from the remaining portion.

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

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

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

10. The method of claim 1 , wherein executing the received resource definition comprises installing the corresponding resource on a local processing node.

11. 1. A computer program for validating a resource definition, the computer comprising: 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 a portion 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 to verify the received resource definition; responsive to finding the match, executing the received resource definition; A computer program that executes the following:

12. 12. The computer program product of claim 11, wherein the original resource definition and the received resource definition are defined for a container manager.

13. 13. The computer program product of claim 12, wherein the at least one change is introduced by the container manager during handling of any resource definition.

14. 13. The computer program product of claim 12, wherein simulating the original resource definition comprises using a DryRun feature of the container manager to run the original resource definition.

15. 12. The computer program product of claim 11, wherein simulating the original resource definition comprises running a simulation of the original resource definition at least twice.

16. 12. The computer program product of claim 11, wherein generating the signature of the received resource definition comprises removing the portion of the received resource definition that corresponds to the at least one identified change from the received resource definition before generating a signature from a remaining portion.

17. 12. The computer program product of claim 11, further comprising receiving the received resource definition from a user, and wherein simulating the original resource definition is performed after receiving the received resource definition.

18. The computer program of claim 17, further comprising generating the signature of the original resource definition, wherein generating the signature of the original resource definition is performed before receiving the received resource definition.

19. 12. The computer program product of claim 11, wherein executing the received resource definition comprises installing the corresponding resource on a local processing node.

20. 1. A system for validating a resource definition, comprising: a hardware processor; a memory storing computer program code, the computer program code, when executed by the hardware processor, 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 a portion 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 to verify the received resource definition; responsive to finding the match, executing the received resource definition; a memory; A system comprising:

Images