Signature Enforcement for Software Deployment Configurations

Abstract

In one approach, a process intercepts a deployment resource associated with software before deploying the software to a node, the deployment resource configuring how the software is deployed and operates. A processor verifies the authenticity of a digital signature present in the deployment resource. In response to verifying the authenticity of the digital signature, the processor deploys the software to the node according to the deployment resource.

Description

[Technical field]

[0001] The present invention relates generally to the field of software deployment, and more particularly to enforcing signatures of software deployment configuration data. [Background technology]

[0002] Software deployment includes all of the activities that make a software system available for use. Typically, the two necessary items for software deployment are content and configuration. Configuration refers to the data that configures how an application is deployed and how the application runs once deployed. Configuration files are used to configure parameters and initial settings for an application or container. Example configuration files include Kubernetes(R) YAML (YAML Ain't Markup Language) and Ansible(R) Playbooks. Ansible is a trademark or registered trademark of Red Hat, Inc. or its subsidiaries in the United States and other countries.

[0003] Cryptographic signing techniques, such as digital signatures, are mathematical methods for verifying the authenticity of a digital message or document. A valid digital signature gives one strong reason to believe that the document was generated or edited by the signer and that the message was not altered in transit. Digital signatures employ asymmetric cryptography and may provide a layer of validation and security for messages or documents sent through insecure channels. Typically, there are three algorithms involved in the digital signature process. A key generation algorithm produces a signature upon receiving a private key along with its corresponding public key. A signing algorithm produces a signature upon receiving a private key and the message or data being signed. A verification algorithm checks the authenticity of the message by verifying the message along with the signature and public key. Summary of the Invention

[0004] Aspects of an embodiment of the present invention disclose a method, a computer program product, and a computer system. A processor intercepts a deployment resource associated with software before deploying the software to a node, the deployment resource configuring how the software is deployed and operates. The processor verifies authenticity of a digital signature present in the deployment resource. In response to verifying the authenticity of the digital signature, the processor deploys the software to the node according to the deployment resource.

[0005] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0006] [Figure 1] FIG. 2 illustrates a cloud computing node according to an embodiment of the present invention. [Diagram 2] FIG. 1 illustrates a cloud computing environment according to an embodiment of the present invention. [Diagram 3] FIG. 2 illustrates an abstract model layer according to an embodiment of the present invention. [Figure 4] FIG. 1 is a block diagram of a computing environment in accordance with an embodiment of the present invention. [Diagram 5] 4 is a flowchart illustrating the operational steps of generating a digital signature on a deployment resource according to an embodiment of the present invention. [Figure 6] 4 is a flowchart illustrating the operational steps of verifying a digital signature on a deployment resource according to an embodiment of the present invention. [Figure 7] FIG. 2 illustrates an example admission policy, according to an embodiment of the present invention. [Figure 8] FIG. 2 illustrates an example deployment resource, according to an embodiment of the present invention. [Figure 9]FIG. 4 illustrates another example deployment resource, according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] A software deployment includes the software to be deployed (i.e., content) and configuration data. The configuration data and associated deployment metadata, collectively referred to herein as deployment resources, may include sensitive data that configures how an application is deployed and how the application operates once deployed. Embodiments of the present invention recognize that there is currently no way to verify the origin and integrity of the configuration data and associated deployment metadata in a software deployment. Embodiments of the present invention further recognize that verification of both content and deployment resources is essential to the security of a software platform. Embodiments of the present invention provide an approach that uses cryptographic signature techniques to sign software deployment configuration and / or metadata deployment resources. The system may then rely on the cryptographic signature techniques to verify the origin and integrity of the deployment resources and determine whether the signature complies with an admission policy. Such verification may then be used to determine whether to deploy software according to the provided deployment resources.

[0008] Although this disclosure includes a detailed description of cloud computing, it should be understood that implementations of the teachings provided herein are not limited to cloud computing environments. Rather, embodiments of the invention may be practiced in conjunction with any other type of computing environment now known or later developed.

[0009] Cloud computing is a model of service delivery 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 administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0010] The characteristics are as follows: On-Demand Self-Service: Cloud consumers can unilaterally provision computing capabilities such as server time and network storage automatically as needed, without the need for human interaction with the service provider. Broad network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin-client or thick-client platforms (e.g., cell phones, laptops, and PDAs). Resource Sharing: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Location independence is implied in that consumers generally do not have control or knowledge over the exact location of the resources provided, but may be able to specify location at a higher level of abstraction (e.g., country, state, or data center). Rapid Scalability: Capabilities can be quickly and elastically provisioned, in some cases automatically, to instantly scale out, and quickly released to instantly scale in. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased in any quantity at any time. Services are meterable: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services being used.

[0011] The service model is as follows: Software as a Service (SaaS): The capability provided to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The capability provided to the consumer is to deploy consumer-created or consumer-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 networks, servers, operating systems, or storage, but does have control over the deployed applications and, to the extent possible, the application hosting environment configuration. Infrastructure as a Service (IaaS): The capability provided to the consumer is the supply of processing, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating systems, storage, deployed applications, and possibly limited control over select networking components (e.g., host firewalls).

[0012] The deployment model is as follows: Private Cloud: The cloud infrastructure is operated exclusively for an organization. It may be managed by that organization or a third party and may be on-premise or off-premise. Community Cloud: The cloud infrastructure is shared by multiple organizations to support a specific community with shared concerns (e.g., mission, security requirements, policy, and compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may reside on-premise or off-premise. Public Cloud: The cloud infrastructure is made available to the general public or large industry organizations and is owned by an organization that sells cloud services. Hybrid Cloud: The cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain a unique entity but are joined by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0013] A cloud computing environment is stateless, low-coupling, modular, and service-oriented with a focus on semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0014] 1, an example of a cloud computing node is shown generally. Cloud computing node 10 is merely one example of a suitable computing node and is not intended to suggest any limitation as to the scope of use or functionality of the inventive embodiments described herein. Regardless, cloud computing node 10 is capable of implementing and / or performing any of the functionality described above.

[0015] Cloud computing node 10 includes computer system / server 12, which may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable appliances, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0016] The computer system / server 12 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 12 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0017] 1, computer system / server 12 in cloud computing node 10 is shown in the form of a general purpose computing device. Components of computer system / server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 coupling various system components including system memory 28 to processor 16.

[0018] Bus 18 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a high-speed graphics port, and a processor or local bus using any of a variety of bus architectures, including, by way of example and not limitation, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0019] Computer system / server 12 typically includes a variety of computer system readable media. Such media may be any available media that can be accessed by computer system / server 12 and includes both volatile and nonvolatile media, removable and non-removable media.

[0020] The system memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. The computer system / server 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 34 may be provided for reading from and writing to a non-removable non-volatile magnetic medium (not shown, and typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), as well as an optical disk drive for reading from or writing to a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. In such instances, each may be connected to the bus 18 by one or more data media interfaces. As further shown and described below, the memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of an embodiment of the present invention.

[0021] A program / utility 40 having a set (at least one) of program modules 42 may be stored in memory 28, as well as, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a networked environment. The program modules 42 generally perform the functions and / or methodologies of the embodiments of the invention described herein.

[0022] The computer system / server 12 may also communicate with one or more external devices 14, such as a keyboard, pointing device, display 24, one or more devices that allow a user to interact with the computer system / server 12, or any device that allows the computer system / server 12 to communicate with one or more other computing devices (e.g., network cards, modems, etc.), or combinations thereof. Such communication may occur through an input / output (I / O) interface 22. Additionally, the computer system / server 12 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or combinations thereof, through a network adapter 20. As shown, the network adapter 20 communicates with other components of the computer system / server 12 through a bus 18. Although not shown, it is understood that other hardware and / or software components may be used in conjunction with the computer system / server 12. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0023] Referring now to FIG. 2, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or cell 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 communicate with each other. They may be physically or virtually grouped in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described above (not shown). This allows the cloud computing environment 50 to offer infrastructure, platform, and / or software as a service without the cloud consumer having to maintain resources on the local computing device. It should be understood that the types of computing devices 54A-N shown in FIG. 2 are intended to be exemplary only, and that the computing node 10 and cloud computing environment 50 may communicate with any type of computerized device via any type of network and / or network-addressable connections (e.g., using a web browser).

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

[0025] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61, Reduced Instruction Set Computer (RISC) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0026] The virtualization layer 70 provides an abstraction layer at which the following examples of virtual entities may be provided: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0027] In one example, management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides protection for data and other resources as well as identity verification for cloud consumers and tasks. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management so that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-positioning and procurement of cloud computing resources where future requirements are anticipated according to SLAs.

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

[0029] Figure 4 is a functional block diagram illustrating a computing environment, generally designated 400, in accordance with one embodiment of the present invention. Computing environment 400 is a partial view of an example architecture of cloud computing environment 50, as described with reference to Figure 2. Figure 4 provides only an illustration of one embodiment and does not imply any limitation with regard to the environments in which different embodiments may be implemented.

[0030] In the illustrated embodiment, computing environment 400 includes a server 420 and a node 480 interconnected via a network 410. Network 410 may be a local area network (LAN), a wide area network (WAN) such as the Internet, a public switched telephone network (PSTN), any combination thereof, or any combination of connections and protocols supporting communications between server 420 and node 480. Network 410 may include wired, wireless, or fiber optic connections. Computing environment 400 may include additional servers, computing devices, or other devices not shown.

[0031] Server 420 may be an administration server, a web server, or any other electronic device or computing system capable of receiving and transmitting data. In some embodiments, server 420 may be a laptop computer, a tablet computer, a personal computer (PC), a desktop computer, or any programmable electronic device capable of communicating with node 480 over network 410. In one embodiment, server 420 represents a node, such as node 10, of a cloud computing environment, such as cloud computing environment 50 (see FIG. 2). In some embodiments, server 420 may represent a server computing system that uses clustered computers and components to function as a single pool of seamless resources. In the illustrated embodiment, server 420 includes at least a deployment program 430, a signature function 440, a verification function 450, software 460, and an admission policy 470.

[0032] Node 480 may be an administration server, a web server, or any other electronic device or computing system capable of receiving and transmitting data. In some embodiments, node 480 may be a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, or any programmable electronic device capable of communicating with server 420 over network 410. In one embodiment, node 480 is an example of a computing device, such as computing devices 54A-54N, used to access and / or communicate with cloud computing environment 50. In another embodiment, node 480 represents a node, such as node 10, of a cloud computing environment, such as cloud computing environment 50 (see FIG. 2). In some embodiments, node 480 may represent a server computing system that uses multiple computers as server systems, such as in a cloud computing environment. In some embodiments, node 480 represents a computing system that uses clustered computers and components to function as a single pool of seamless resources. In the illustrated embodiment, node 480 includes software 490. Although illustrated as multiple nodes, node 480 may represent one or any other number of nodes in various embodiments.

[0033] In one embodiment, server 420 and node 480 are part of a Kubernetes® environment, where server 420 represents a master node and node 480 represents one or more worker nodes. In such an embodiment, validation function 450 may be part of an application programming interface (API) server in the master node.

[0034] The deployment program 430 executes on the server 420. The deployment program 430 may be a dedicated deployment program, a function integrated within another program, such as an orchestration or software deployment program, or any other program or function that may communicate with the node 480 and provide a user interface for interacting with the deployment resources and for generating / enforcing cryptographic signatures of the deployment resources. In other embodiments, the deployment program 430 may reside on other devices, so long as the deployment program 430 may communicate with the software 460, the admission policies 470, and the node 480. The deployment program 430 may include a signing function 440 and a verifying function 450.

[0035] The signing function 440 operates to receive a selection of one or more sections of the deployment resource to be signed, encrypt the selected sections, and attach a signature to the deployment resource. The signing function 440 may be a function of the deployment program 430 or may be a stand-alone program. In one embodiment, the signing function 440 resides on the server 420. In other embodiments, the signing function 440 may reside on a separate server or separate computing device, so long as the signing function 440 is accessible to the deployment program 430 and has access to the software 460 and / or admission policies 470.

[0036] The verification function 450 operates to intercept the deployment resources prior to the deployment of the software and verify whether the signatures present in the deployment resources comply with the admission policies. The verification function 450 may be a function of the deployment program 430 or may be a standalone program. In a Kubernetes® environment, the verification function 450 may be implemented as an admission controller. The admission controller is a piece of code that intercepts requests to a Kubernetes® API server. In one embodiment, the verification function 450 resides on the server 420. In other embodiments, the verification function 450 may reside on another server or another computing device, as long as the verification server has access to the deployment program 430 and has access to the software 460 and the admission policies 470.

[0037] Software 460 may be a repository that may be written and read by deployment program 430 and signing function 440, and may be accessible to verification function 450. Software 460 may include, for example, software and deployment resources such as configuration files (e.g., YAML, Ansible® Playbooks) and associated metadata. Software content may include, for example, virtual machines and container images. In general, software 460 may include any combination of content and configuration data deployable to node 480. Software 460 may be, for example, a database.

[0038] Admission policies 470 may be a repository that may be written and read by deployment program 430 and that is accessible to signing function 440 or verification function 450 or both. Admission policies 470 may include one or more admission policies for deployment of software resources. Generally, an admission policy specifies signing requirements for either specific sections or the entire configuration file that must be met in order to deploy the software. More specifically, admission policies 470 may specify specific sections of the configuration file and the required signatures for each specific section. An example admission policy is shown in FIG. 7. Each admission policy may specify one or more individuals via some means of identification, e.g., email address or user identification. The admission policy further specifies specific paths that indicate sections of the configuration file that must be signed by the identified individuals. The admission policy may specify any number of specific individuals that must sign the sections, or may not specify any individuals, e.g., if no signatures are required. In some embodiments, if multiple users are enumerated, each enumerated individual must sign the section. In other embodiments, if multiple users are listed, at least one of the listed individuals must sign the section. The applicable admission policies may vary based on factors such as the client, the target node, the type of software, etc. In some embodiments, the admission policies are manually entered by the client or entity responsible for the deployment.

[0039] Software 490 may be software that has been deployed by deployment program 430 after meeting applicable admission policy requirements that have been verified by validation function 450. Software 490 may be, for example, a container, a virtual machine, an application, or any other software that can be deployed.

[0040] FIG. 5 illustrates a flowchart 500 of steps of a signing function executed within the computing environments of FIGS. 1-4 to add a digital signature to a deployment resource, such as a configuration file, according to one embodiment of the present invention.

[0041] In one embodiment, an administrative user first creates or edits deployment resources, such as configuration files, corresponding to the software to be deployed, such as the software stored in software 460. Examples of such configuration files are shown in FIG. 8 and FIG. 9. The configuration file may be, for example, a YAML file. In general, the configuration file is used to configure parameters and initial settings for the software to be deployed. An embodiment of the present invention recognizes the importance of providing cryptographic signature techniques for deployment resources, such as configuration files, because such deployment resources may contain sensitive data that configures how an application or other software is deployed and how it operates after deployment. The configuration file may include multiple sections and an organizational structure that may enable the administrative user to select specific sections within the configuration file.

[0042] In step 510, the signing functionality 440 receives a selection of one or more sections of the deployment resource to sign. In some cases, the signing user may select all of the sections or may specify that the entire file is to be signed, while in other cases, the signing user may select one or more sections of the deployment resource. The selected sections represent sections of the deployment resource for which the signing user intends to verify or vouch for the work product contained in the contents of each selected section. In some cases, the selected sections may correspond to sections that the user edited or generated. In other cases, the selected sections may correspond to sections that the user reviewed. The selected sections may be identified by dot notation, slash notation, or another means. In some embodiments, the signing functionality 440 provides a text entry option for providing such notation. In other embodiments, the signing functionality 440 may allow the user to highlight or select one or more sections of the deployment resource using a graphic user interface and, for example, a cursor.

[0043] In step 520, signing function 440 encrypts the selected sections as one or more digests and / or encrypted messages. In some embodiments, a one-way hash function is used to generate a message digest for each selected section. The message digest is a fixed-size numeric representation of the contents of the message, computed by the hash function. The message digest may be encrypted to form a digital signature. Thus, in other embodiments, the generated message digest is encrypted with a private key to generate a digital signature. In such embodiments, the corresponding public key is either (i) already made accessible to verification function 450 or (ii) made accessible to verification function 450 prior to verifying the deployment resource. In some embodiments, the corresponding public key is stored in admission policy 470.

[0044] In step 530, the signing function 440 adds a digital signature to the deployment resource. Note that in embodiments requiring only a message digest, the message digest is added to the resource rather than the digital signature. In embodiments requiring a digital signature, the digital signature is added to the deployment resource. In some embodiments, the digital signature is added as an annotation at the top level of the metadata for the deployment resource. However, embodiments of the present invention recognize that the digital signature may be added anywhere in the deployment resource. Along with the digital signature, the signing function 440 may also include a description of which sections and / or attributes are included in the signature. In other words, the digital signature attests to the verification of which sections. The description of which sections are included in the signature may use any format, such as, but not limited to, dot notation or slash notation. For example, if the configuration file is a YAML file, dot notation may be used to describe the path to the section of the YAML file associated with the signature.

[0045] The appended digital signature serves as a method of ensuring and verifying the origin and integrity of the configuration and usage metadata and may be used by verification function 450 to verify the presence and authenticity of signatures by one or more required parties or individuals.

[0046] FIG. 6 illustrates a flowchart 600 of steps for a verification function 450 executing within the computing environment of FIGS. 1-4 to verify signatures of deployment resources, such as configuration files, against admission policies prior to software deployment, in accordance with one embodiment of the present invention.

[0047] In one embodiment, initially, software from software 460 is deployed to one or more nodes. An admission policy is generated and stored in admission policies 470, where the admission policy specifies signature requirements for one or more sections (or entire configuration files) associated with the software deployment. In addition, if digital signatures are used, one or more public keys associated with individuals required by the admission policy may be accessible to verification function 450, and in some embodiments such public keys are also stored in the repository of admission policies 470 or in another database / repository accessible to verification function 450.

[0048] In step 610, validation function 450 blocks deployment resources prior to deployment of the corresponding software. In some embodiments, validation function 450 is a Kubernetes® admission controller. An admission controller is a piece of code that blocks requests to a Kubernetes® API server before persistence of objects, but after the request has been authenticated and authorized. In an embodiment of the invention, validation function 450 operates as a validation controller. Validation controllers may not modify the objects that they admit. In other environments, validation function 450 may be any function of deployment program 430 that operates to block deployment resources prior to deployment of the corresponding software.

[0049] In step 620, verification function 450 identifies the signatures required for deployment. Verification function 450 may access pre-stored admission policies, such as pre-stored admission policies stored in admission policies 470. As previously described, the admission policies correspond to the particular software, the client associated with node 480 to which the software is to be deployed, the development / deployment team, or other factors established prior to beginning the deployment and stored in the admission policies. Verification function 450 may extract the required signature or signatures, and any relevant sections associated with those signatures, from the relevant admission policies.

[0050] In decision 630, verification function 450 determines whether a signature is present and verified on the deployment resource to be blocked. Verification function 450 compares the signatures present on the configuration file or other deployment resource to determine whether the required signature is present. In addition, verification function 450 uses a hash algorithm and / or public key associated with each of the signatures to identify whether the signatures are valid. Signature verification is accomplished by applying a hash function to the data and decrypting the signature with the signer's public key. If the resulting hashes are equal, the signature may be confirmed as valid. As described with reference to signature function 440, verification function 450 determines which section is associated with the signature based on an appended path or other description of the section. In some embodiments, the admission policy may specify that multiple signatures may be required for a section. In other embodiments, the admission policy may specify that at least one of the following signatures is required for a particular section: Not all sections require signature verification:

[0051] If the verification function 450 determines that all required signatures are present and verified (decision 630, yes branch), the verification function 450 allows deployment of the software to the node 480 in accordance with the configuration and deployment parameters (step 640), resulting in the software 490 running on the associated node 480.

[0052] If the verification function 450 determines that not all of the required signatures are present or that not all of the required signatures can be verified as authentic (decision 630, no branch), the verification function prevents the deployment of the software to the node 480. In some embodiments, in addition to preventing the deployment from occurring, the verification function 450 may generate an error or other notification. Such an error or communication may be communicated to an administrative user associated with the deployment, to users associated with each of the nodes 480 that were expecting the software to be deployed to, or to other users, or a combination thereof. In some embodiments, the notification may include details about what caused the software to not be able to be deployed. For example, the verification function 450 may specify required signatures that were missing from the deployment resources and / or signatures that could not be authenticated or verified. The inability to authenticate or verify a signature may mean that the section associated with the signature was modified after the signer generated the signature. Such a notification may provide details to the administrative user responsible for deploying the software to better enable them to correct any issues with the deployment resources, discard various sections as necessary, and attempt to deploy the software again.

[0053] FIG. 7 illustrates an example admission policy 700 that may be used to enforce the signing requirements for deployment resources illustrated by FIGS.

[0054] Admission policy 700 shows five sections that include signature requirements: "spec.replicas", "spec.template.metadeta.*", "spec.template.spec.containers.image", "spec.template.spec.containers.ports", and "spec.template.spec.containers.env.*". The paths specifying the sections are written in dot notation, although embodiments of the present invention recognize that other types of notations or descriptive means for identifying sections may be used. The "*" acts as a wildcard, for example, indicating that all subsections of a metadata item are to be signed. Each section also includes a signature requirement for that section that appears after a colon. As shown, some sections require a single signature, while other sections require at least one signature from multiple enumerated signatures (indicated as "||" for "or"). Although not shown in admission policy 700, other admission policies may enumerate multiple signatures for a particular section and may require that all of the enumerated signatures be obtained prior to software deployment. For example, a policy that is not included in admission policy 700 but requires multiple signatures might be "spec.template.spec.containers.ports:bobsmith@foo.com&&alicejones@foo.com" (with "and" denoted as "&&").

[0055] 8 illustrates an example configuration file or deployment resource, referred to herein as deployment resource 800. As illustrated, deployment resource 800 is an example of a deployment resource that corresponds to admission policy 700 and passes validation by validation function 450.

[0056] The deployment resource 800 includes a signature section 810 that is attached to the deployment resource 800 as an annotation, the signature section 810 including a digital signature and a path that correspond to the requirements of the admission policy 700. Each signature includes (i) a path that specifies the section being signed, a signer identification tag (in the illustrated example, the signer identification tag is an email address), and a cryptographic signature shown as a long string. As described above, the cryptographic signature is generated using a hash algorithm and / or the signer's private key. The signature is attached to the deployment resource 800 by the signing function 440 and may be verified by the verification function 450 by accessing the admission policy 700 from the repository admission policy 470. The verification function 450 may use a public key associated with the signer to verify that the cryptographic signature is valid and that the data in the relevant section has not been modified.

[0057] When comparing deployment resource 800 to admission policy 700, all of the signature requirements specified by admission policy 700 are present. Assuming verification function 450 is able to verify the integrity of the signature, deployment resource 800 can be used in configuring software during the software deployment process.

[0058] In contrast, FIG. 9 illustrates a deployment resource 900 that does not meet the requirements of admission policy 700. Reviewing signature section 910, signature 920 specifies “bobsmith@foo.com” and admission policy 700 requires a signature from “chrisbuck@foo.com” for section “spec.template.metadeta.*”. Thus, validation function 450 determines that the required signature from admission policy 700 is missing, preventing deployment resource 900 from being used to configure the corresponding software destined for deployment to node 480. In addition, although not shown, deployment resource 900 may also experience difficulties with a signature that cannot be verified. For example, if a required signature is added and then data from the relevant section is modified after the signature is added, the signature will no longer be valid because the changes to the section contents would result in an inconsistency during the validation process. In such a situation, validation function 450 again determines that the deployment resource cannot be processed for software deployment due to the invalid signature.

[0059] As previously discussed, validation function 450 may generate an error or notice describing a deficiency in deployment resource 900. In this particular example, validation function 450 may generate a notice identifying that the “spec.template.metadeta.*” section of deployment resource 900 was signed by “bobsmith@foo.com” and that admission policy 700 requires a digital signature from “chrisbuck@foo.com”. Further, assuming another signature is determined to be invalid by validation function 450, validation function 450 would cause the notice to identify the invalid signature. Such information may be used by an administrative user to address the deficiency and update deployment resource 900 so that deployment resource 900 meets the signature requirements of admission policy 700.

[0060] It should be noted that although FIGS. 8 and 9 are shown as YAML configuration files, any type of deployment resource or configuration file may be used by various embodiments of the present invention.

[0061] The invention may be a system, method, or computer program product, or 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 thereon for causing a processor to perform aspects of the invention.

[0062] A computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but 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, punch cards or mechanically encoded devices such as ridge structures in grooves that allow instructions to be recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, 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 a fiber optic cable), or electrical signals transmitted through an electrical wire.

[0063] The computer readable program instructions described herein may be downloaded from the computer readable storage medium to the respective computing / processing device or to an external computer or storage device via 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 transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions for storage in the computer readable storage medium in the respective computing / processing device.

[0064] The computer readable program instructions for carrying out the operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may execute completely 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 completely 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 made to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions by individualizing the electronic circuitry with state information of the computer readable program instructions to perform aspects of the invention.

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

[0066] 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, executed by the processor of the computer or other programmable data processing apparatus, generate means for performing the functions / operations 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 on which the instructions are stored comprises an article of manufacture including instructions for performing aspects of the functions / operations 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.

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

[0068] 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 the flowcharts or block diagrams may represent a module, segment, or part of an instruction, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be implemented as one step, executed simultaneously, substantially simultaneously, partially or fully overlapping in time, or the blocks may be executed in the reverse order depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0069] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the present invention. The terms used in this specification are selected to best explain the principles of the embodiments, practical applications, or technical improvements beyond the technology found in the market, or to enable other skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method comprising: The processor: Shutting down deployment resources associated with the software before deploying the software to a node, the deployment resources configuring how the software is deployed and operates; verifying the authenticity of a digital signature present in the deployment resource; deploying the software to the node according to the deployment resource in response to verifying the authenticity of the digital signature; Including, wherein the digital signature is a message digest encrypted with a private key, the message digest being generated by encrypting one or more sections of the deployment resource selected by a user with a one-way hash function, the one or more sections being sections that are intended to be guaranteed to be verified. Computer-implemented method.

2. verifying the authenticity of the digital signature, by the processor retrieving an admission policy, the admission policy specifying one or more digital signatures required for deployment of the software; verifying that the required one or more digital signatures are present in the deployment resource; The computer-implemented method of claim 1 , further comprising:

3. by the processor receiving a selection of a section within the deployment resource to be signed; encrypting the selected section with a hash function and a private key; adding a digital signature and an identification of said section within said deployment resource; The computer-implemented method of claim 1 , further comprising:

4. verifying the authenticity of the digital signature, by the processor decrypting the digital signature; and comparing the resulting hash function with the hash function associated with the data in said section; The computer-implemented method of claim 3 , comprising:

5. 3. The computer-implemented method of claim 2, wherein the admission policy further specifies multiple sections of the deployment resource and corresponding digital signatures required for each section.

6. The computer-implemented method of claim 1 , wherein the deployment resource is a Kubernetes YAML file.

7. The computer-implemented method of claim 3 , wherein the digital signature and an identification of the section within the expanded resource are added to an annotation in top-level metadata for the expanded resource.

8. A program for causing a processor to carry out the computer-implemented method of any one of claims 1 to 7.

9. A storage medium storing the program according to claim 8.

10. A computer system comprising a processor for executing the computer-implemented method of any one of claims 1 to 7.

Images