Methods and systems for service image deployment in cloud computing systems based on distributed ledger technology

Abstract

A method and system for service image deployment in a cloud computing system based on distributed ledger technology is described. A first signed message is received, the first signed message including a request to authorize installation of a service image, a service image identifier, a service installer account identifier, and one or more hashes of the service image. In response to determining, based on the service installer account identifier and a distributed ledger, that a service installer is authorized to install the service image identified with the service image identifier in the cloud computing system, the following operations are performed: recording the one or more hashes of the service image in a list of valid service images of the distributed ledger; and sending a first message to the service installer. The message includes a first service installation token and the service image identifier, the first service installation token causing the service installer to install the service image in the cloud computing system.

Description

TECHNICAL FIELD

[0001] Embodiments of the present invention relate to the field of distributed ledger technology; and more specifically, to image deployment in a cloud computing system based on distributed ledger technology. BACKGROUND

[0002] In a cloud computing system, multiple instances of an application can be deployed on one or more servers. The instances of the application are typically used to provide services to users of the cloud computing system. Each instance of the application includes program code, which can be referred to as an image or a service image, and is executed on one or more servers of the cloud computing system, respectively. The instances of the application can be deployed as virtual machines or containers. A service image can include program code that represents a computing service, a networking service, and a storage service provided by the cloud computing system or another service provided by a third party that uses the cloud computing system.

[0003] Proper and secure provisioning of service images on a cloud computing system is critical to ensure that reliable and secure services are provided to users of the application. For example, an unauthorized image or a corrupted image installed into the cloud computing system can compromise the data of the users and the resources of the cloud computing system.

[0004] There are mechanisms to ensure that images deployed on a cloud computing system are legitimate and verified before being executed. In some mechanisms, a cloud computing system supports and maintains a collection of certified virtual operating system images and controls the provisioning of these images. If a user of the cloud computing system uses one of these images, the user is likely to avoid images that have been compromised by an attacker. However, any service image that is not certified or verified and executed on the cloud computing system after the cloud computing system boots can have been altered by an attacker.

[0005] In some mechanisms, a cloud computing system provider relies on user login credentials (e.g., username / password) to authenticate a user that installs a new service image. In these mechanisms, when a user’s account is compromised (e.g., a malicious entity can access the user login credentials) without the knowledge of these mechanisms, a malicious or corrupted image can be installed on the cloud computing system, allowing an attacker to collect information about the application or disrupt the operation of the cloud computing system.

[0006] Some mechanisms rely on the Trusted Computing Group Trusted Platform Module (TPM) standard for verifying and validating service images. The TPM provides a series of services for attesting to the validity and authentication of service images at various levels in the stack (boot loader, operating system, application). The TPM relies on a trusted third party (TTP) that maintains a database of trusted image hashes. One problem with this process is how the image hashes end up in the database. An attacker can compromise a service provider’s continuous integration / continuous deployment (CICD) pipeline and can insert hashes of fake service images, or if the attacker just wants to disrupt the service provider’s operations, insert fake hashes. In the first case, the attacker will be able to impersonate the service and trick service users into giving away information and possibly money, while in the second case, the attacker will be able to prevent the service from functioning properly. Another problem is that the system that manages the database storing the hashes is envisioned as a centralized entity. Although scalability techniques are well known to ensure that a centralized database has sufficient availability, a centralized system can encounter difficulties in keeping records synchronized in a highly decentralized network of data centers. SUMMARY

[0007] One general aspect includes a method performed by a network node, the method comprising: receiving, from a service installer, a first signed message including a request to authorize installation of a service image, a service image identifier, a service installer account identifier, and one or more hashes of the service image; and in response to determining, based on the service installer account identifier and a distributed ledger, that the service installer is authorized to install the service image identified by the service image identifier in a cloud computing system, performing the following operations: recording the one or more hashes of the service image in a list of valid service images of the distributed ledger; and sending, to the service installer, a first message including a first service installation token and the service image identifier, wherein the first service installation token causes the service installer to install the service image in the cloud computing system.

[0008] One general aspect includes a network node comprising: one or more processors; and a non-transitory computer-readable storage medium storing instructions that, when executed by the one or more processors, cause the network node to: receive, from a service installer, a first signed message comprising a request to authorize installation of a service image, a service image identifier, a service installer account identifier, and one or more hashes of the service image; and in response to determining, based on the service installer account identifier and a distributed ledger, that the service installer is authorized to install the service image identified with the service image identifier in a cloud computing system, record the one or more hashes of the service image in a list of valid service images of the distributed ledger and send, to the service installer, a first message comprising a first service installation token and the service image identifier, wherein the first service installation token causes the service installer to install the service image in the cloud computing system. BRIEF DESCRIPTION OF DRAWINGS

[0009] The application can best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the application. In the drawings:

[0010] Figure 1 A block diagram illustrating an example system that can be used to provide verified service image deployment is shown in accordance with some embodiments;

[0011] Figure 2A A block diagram illustrating an example transaction between a service installer and a service management system to obtain a service installer account is shown in accordance with some embodiments;

[0012] Figure 2B A block diagram illustrating example operations to authorize installation of a service image is shown in accordance with some embodiments;

[0013] Figure 2C A block diagram illustrating example operations to authorize uninstallation of a service image is shown in accordance with some embodiments;

[0014] Figure 2D A block diagram illustrating example operations for secure execution of a service image is shown in accordance with some embodiments;

[0015] Figure 3A A flow diagram illustrating example operations to obtain a service installer account is shown in accordance with some embodiments;

[0016] Figure 3B A flow diagram illustrating example operations to authorize installation of a service image is shown in accordance with some embodiments;

[0017] Figure 3CA flow diagram illustrating exemplary operations performed by a service installer, in accordance with some embodiments, is shown;

[0018] Figure 3D A flow diagram illustrating exemplary operations for authorizing uninstallation of a service image, in accordance with some embodiments, is shown;

[0019] Figure 3E A flow diagram illustrating exemplary operations for requesting uninstallation of a service image, in accordance with some embodiments, is shown;

[0020] Figure 3F A flow diagram illustrating exemplary operations for securely executing a service image, in accordance with some embodiments, is shown;

[0021] Figure 4 A block diagram of a network device in which generation and / or verification of a new genesis block can be performed, in accordance with some embodiments, is shown. DETAILED DESCRIPTION

[0022] The following description describes methods and apparatus for image deployment in a cloud computing system based on distributed ledger technology. In the following description, numerous specific details are set forth, such as logic implementations, opcodes, means to specify operands, resource partitioning / sharing / replication implementations, types and interrelationships of system components, and logic partitioning / integration choices to provide a thorough understanding of the present invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail in order to avoid obscuring aspects of the present invention.

[0023] Reference throughout this specification to "one embodiment", "an embodiment", "one example embodiment", etc. means that a described embodiment can include, but not necessarily consist of, a specific feature, structure, or characteristic. Furthermore, this language is not necessary to reach from one embodiment to the next, and to this end no language conveys that a described feature, structure, or characteristic must be included in all embodiments. The appearances of the phrase "in one embodiment" is in general not a qualification that a particular feature, structure, or characteristic described applies in all embodiments.

[0024] Bracketed text and boxes with dashed borders (e.g., large dashed, small dashed, point dashed, and dotted) can be used herein to illustrate optional operations that add additional features to embodiments of the invention. However, such notation should not be taken to mean that they are the only options or optional operations, and / or that boxes with solid borders are not optional in certain embodiments of the invention.

[0025] In the following description and claims, the terms "coupled" and "connected," along with their derivatives, can be used. It should be understood that these terms are not intended as synonyms for each other. "Coupled" is used to indicate that two or more elements, which can or can not be in direct physical or electrical contact with each other, co-operate or interact with each other. "Connected" is used to indicate the establishment of communication between two or more elements that are coupled to each other.

[0026] Embodiments provided herein describe a distributed ledger technology based image deployment mechanism in a cloud computing system. The mechanisms described herein provide significant advantages over previous image deployment mechanisms. In embodiments provided herein, a service installer establishes an account in a distributed ledger (e.g., a permissioned blockchain owned and maintained by a group of service installers). The distributed ledger acts as a service management system for service providers. When a service installer / provider installs a new image, the hash of the image (including the hashes of any dynamic link libraries and other files associated with the initial execution of the application) is recorded to the distributed ledger (e.g., a blockchain). A service image executor performs a check of all files of the service image based on the hash stored in the distributed ledger for the service image, and then schedules the service image for execution.

[0027] The solution provides a mechanism for installing service image files into a cloud computing system (e.g., a data center) where a service provider is able to record a proof of providence to enable the verification of the provenance of a service image prior to booting / executing the service image. The solution provided herein is applicable to applications packaged in any form (virtual machine, container, or simple application binary), and contains configuration files and dynamic link libraries as well as the main application image.

[0028] Figure 1 A block diagram of an exemplary system that can be used to provide verified service image deployment is shown in accordance with some embodiments. The system 100 includes a group of service installers 110A-N, a service management system (SMS) 120, a group of cloud computing systems 130A-L, and a service installer verification system 140.

[0029] The service installers 110A-N are operable to manage the lifecycle of applications (generally referred to herein as services) deployed on one or more cloud computing systems. Each of the service installers 110A-N is operable to request installation, update, or deletion of a service image in the cloud computing systems 130A-L. In some embodiments, the service installers can be continuous integration and delivery (CI / CD) pipelines, orchestration systems, operations support systems (OSS), or any other service management system, and are collectively referred to herein as service installers (SI). Each service installer can include or have access to a set of service images. In the following description, for simplicity of description, the operations herein will be described with respect to a single service installer 110A from the set of service installers 110A-N, and this should not be considered limiting to embodiments of the invention. The system 100 can include one or more service installers without deviating from the scope of the inventive concepts. The service installer 110A can store or have access to a set of one or more service images 101A-M.

[0030] The SMS 120 is operable to receive requests for installation of service images, and can validate and authorize installation, uninstallation of service images in one or more cloud computing systems. The SMS 120 includes a plurality of distributed SMS nodes 121A-K. The SMS 120 is built on a distributed ledger technology, and is operable to record information about service images in a distributed ledger. In some embodiments, each of the SMS nodes 121A-K can include a distributed ledger technology that allows data to be recorded in a distributed ledger. In some embodiments, the distributed ledger is a permissioned distributed ledger. In some embodiments, the distributed ledger is a permissioned blockchain.

[0031] The set of cloud computing systems 130A-L includes computing, networking, and storage resources distributed across multiple network devices. In some embodiments, the SMS nodes 121A-K and / or the service installers 110A-N can be part of the cloud computing systems 130A-L. In other embodiments, the SMS nodes 121A-K or the service installers 110A-N can be separate from the cloud computing systems. For example, the service installers 110A-N can be third-party service providers that are not part of the cloud computing systems, but provide one or more services to users by executing their service images on the physical resources of one or more cloud computing systems 130A-L.

[0032] The service installer verification system 140 is a service that allows a user to obtain a service installer certificate. The service installation certificate allows a proof that the holder of the service installation certificate is allowed to use the service management system and obtain an account for installing one or more services on a cloud computing system. After verifying that the service installer 110A is the rightful owner of a public key from a public / private encryption key pair and that the service installer 110A is authorized to use the SMS 120 to install service images in the cloud computing systems 130A-L, the service installer verification system 140 sends the service installation certificate to the service installer 110A. The service installation certificate allows a proof that the service installer 110A holding the private / public key pair is authorized to obtain an account of the SMS 120 to install service images on one or more cloud computing systems 130A-L. In some embodiments, the service installer verification system 140 is based on a public key infrastructure (PKI). In some embodiments, the service installation certificate of the service installer 110A is long-lived and is obtained prior to any image being generated and installed.

[0033] The operation of various components of the system in Figure 2A -D is described in further detail below. Figure 1

[0034] Figure 2A A block diagram illustrating an exemplary transaction between a service installer and a service management system for obtaining a service installer account is shown in accordance with some embodiments.

[0035] At operation 202, the service installer 110A sends a signed message to the SMS 120. The signed message includes a request for an account, a service installation certificate (SIC), and a public key of the service installer 110A. The message is signed with a private key of the service installer 110A. The private and public keys of the service installer 110A are a pair of public / private encryption keys determined based on an asymmetric encryption mechanism. The SMS 120 receives the signed message from the service installer 110A. At operation 204, the SMS 120 determines whether the service installer 110A is authorized to have an account of the SMS 120 based at least in part on the service installation certificate. The determination at operation 204 can include determining that the signature of the received message is valid based on the public key of the service installer 110A. The determination can also include determining that the service installer 110A is authorized to obtain an account in the distributed ledger of the SMS 120 based on the service installation certificate.

[0036] In response to determining that the service installer is not authorized to have an account at the SMS, the SMS 120 denies the account creation. In some embodiments, the SMS 120 can send a response to the service installer 110A with an indication of the denial of the account creation.

[0037] ​Alternatively, in response to determining that service installer 110A is authorized to have an account at SMS 120, the operational flow moves to operations 206-210. At operation 206, SMS 120 creates a service installer 110A account in the distributed ledger. The account is identified with a service installer account identifier that is unique to service installer 110A. In some embodiments, the service installer account identifier can be a public key of service installer 110A or a hash of the public key of service installer 110A. In other embodiments, other types of unique identifiers can be used to uniquely identify service installers 110A-N in SMS 120. For example, the service installer account identifier can be a random string of characters that is generated to serve as an identifier of the service installer account.

[0038] At operation 208, SMS 120 records the service installer account identifier and the public key of service installer 110A in the distributed ledger. In some embodiments, SMS 120 can record a hash of the service installer account identifier in the distributed ledger. In other embodiments, the hash of the service installer account identifier is not recorded in the distributed ledger. In some embodiments, at operation 210, SMS 120 can perform a hash operation on the service installer account identifier, can store the service installer's account information in the distributed ledger, and use the hash of the service installer account identifier as a key to identify the account information. SMS 120 sends the service installer account identifier to service installer 110A at operation 212. Upon receiving the service account identifier, service installer 110A securely stores the service installer account identifier at operation 214. Service installer 110A can use the service installer account identifier to request installation of service images in one or more cloud computing systems managed via SMS 120.

[0039] Figure 2B A block diagram illustrating example operations for authorizing installation of service images is shown, in accordance with some embodiments. After creating an account and obtaining a service installer account identifier from SMS 120, service installer 110A is operable to install one or more service images on a cloud computing system. The example service installer 110A and cloud computing storage system 131A will be used to describe these operations. In some embodiments, service installer 110A can request service installation on any of a plurality of cloud computing systems 130A-L.

[0040] At operation 220, the service installer 110A sends a first signed message, the first signed message including a request to authorize installation of a service image. The first signed message includes the request to authorize installation, a service image identifier, a service installer account identifier, and one or more hashes of the service image. In some embodiments, the hashes of the service image are generated from a hash operation performed on one or more files that form code that, when executed on a server of the cloud computing system, causes the application to provide the service to the user. The files can include configuration files used to configure the service image. The configuration of the service image based on the files is performed prior to the hash operation on the image files and the generation of the hashes. The service image identifier identifies a version of the service image for which installation authorization is sought. In some embodiments, the service installer 110A can have multiple active versions of the service image installed or to be installed in the cloud computing system. In some embodiments, the signed message further includes a public key of the service installer 110A. In other embodiments, the signed message can not include the public key of the service installer 110A, e.g., when the service image identifier is the public key of the service installer 110A. The first signed message is signed with a private key of the service installer 110A.

[0041] The SMS 120 receives the first signed message. At operation 222, the SMS 120 determines whether the service installer 110A is authorized to install the service image identified by the service image identifier in the cloud computing system based on the service installer account identifier and the distributed ledger. In some embodiments, to determine whether the service installer is authorized to install the service image, the SMS 120 can determine whether the service installer account identifier is associated with a legitimate account in the distributed ledger, and the SMS 120 can further determine whether a public key corresponding to the service installer account identifier stored in the distributed ledger verifies the signature of the signed message in which the request to authorize installation is received. In some embodiments, upon determining that the service installer account identifier included in the request is associated with a legitimate account in the distributed ledger and that the public key of the service installer 110A associated with the service image identifier can be used to verify the signature of the signed message, the SMS 120 determines that the service installer 110A is authorized to install the service image. In other embodiments, upon determining that the service installer account identifier included in the request is not associated with a legitimate account in the distributed ledger or that the public key of the service installer 110A associated with the service image identifier cannot be used to verify the signature of the signed message, the SMS 120 determines that the service installer 110A is not authorized to install the service image.

[0042] Upon determining that the service installer 110A is not authorized to install the service image, the SMS 120 rejects the image service installation. In some embodiments, the SMS 120 can send a message to the service installer 110A that includes a rejection of the image service installation. In other embodiments, no message is sent. In some embodiments, when the service installation is rejected, the SMS 120 can report the identity of the service installer 110A and / or record in a blacklist as a malicious service installer.

[0043] Upon determining that the service installer 110A is authorized to install the service image, the SMS 120 performs operations 224-226. At operation 224, the SMS 120 records the hash of the service image in the list of valid service images of the distributed ledger. At operation 225, the SMS 120 also generates and records in the distributed ledger a service installation token associated with the service installer identifier and the service image identifier. The SMS 120 sends a second message to the service installer 110A that includes the service installation token and the service image identifier at operation 226. The service installation token enables the service installer 110A to install the service image in the cloud computing system.

[0044] Upon receiving the service installation token, the service installer 110A sends a request to install the service image to the cloud computing system at operation 228. The request includes the service installation token, the service image, the service image identifier, and the hash of the service installer account identifier. The request is sent to the cloud computing storage system 131 A in which the service image is to be installed. In some embodiments, the request to install the service is sent in a message signed with the private key of the service installer 110A. Upon receiving the request, the cloud computing storage system 131 A determines the validity of the service installation token at operation 230. In some embodiments, determining the validity of the service installation token can include sending a request to the SMS 120 to check the service installation token against data recorded in the distributed ledger for the service installer 110A and the service image identifier. The SMS 120 can retrieve from the distributed ledger the stored service installation token for the service installer 110A identified by the service installer identifier and for the service image identified by the service image identifier. In some embodiments, determining the validity of the service installation token can further include determining that the message received from the service installer 110A can be used to authenticate the service installer 110A, e.g., that the signed message including the request is valid. In response to determining that the service installation token is valid, the cloud computing storage system 131 A installs the image having the associated service image identifier at operation 232. The cloud computing storage system 131 A also records the hash of the service installer account identifier. Upon determining that the installation is complete, the cloud computing storage system 131 A sends an installation confirmation to the service installer 110A at operation 234. In some embodiments, the cloud computing storage system 131 A can determine that the service installation token is not a valid token and reject the installation of the service image at operation 236. In some embodiments, the cloud computing storage system 131 A can send a reject service image installation message to the service installer 110A to indicate that the service image was not installed at operation 238.

[0045] Figure 2C A block diagram illustrating example operations for authorizing uninstallation of a service image is shown in accordance with some embodiments. In some embodiments, the service installer 110A can need to uninstall one or more service images installed in any of the cloud computing systems 130A-L. As described with reference to the operations of Figure 2C

[0046] ​At operation 240, the service installer 110A sends a signed message to the SMS 120, the signed message including a request to authorize uninstallation of a service image previously installed in the cloud computing system. The signed message includes the request to authorize uninstallation, a service image identifier that uniquely identifies the service image to be uninstalled, and a service installer account identifier that uniquely identifies the service installer 110A in the distributed ledger of the SMS 120. In some embodiments, the service installer 110A can have multiple active versions of the service image installed and can send the request with one or more identifiers for uninstallation of these service images. The service installer 110A can request uninstallation / deletion of one or more versions of the service image. The signed message is signed with the private key of the service installer 110A.

[0047] The SMS 120 receives the signed message. At operation 242, the SMS 120 determines, based on the service installer account identifier and the distributed ledger, whether the service installer 110A is authorized to uninstall the service image identified with the service image identifier. In some embodiments, to determine whether the service installer is authorized to uninstall the service image, the SMS 120 can determine whether the service installer account identifier is associated with a legitimate account in the distributed ledger, and the SMS 120 can further determine whether the public key corresponding to the service installer account identifier stored in the distributed ledger verifies the signature of the signed message in which the request to uninstall is received. In some embodiments, upon determining that the service installer account identifier included in the request is associated with a legitimate account in the distributed ledger and that the public key of the service installer 110A associated with the service installer account identifier can be used to verify the signature of the signed message, the SMS 120 determines that the service installer 110A is authorized to uninstall the service image. In other embodiments, upon determining that the service installer account identifier included in the request is not associated with a legitimate account in the distributed ledger or that the public key of the service installer 110A associated with the service installer identifier cannot be used to verify the signature of the signed message, the SMS 120 determines that the service installer 110A is not authorized to uninstall the service image.

[0048] Upon determining that the service installer 110A is not authorized to uninstall the service image, the SMS 120 denies the image service uninstallation. In some embodiments, the SMS 120 can send a message to the service installer 110A including a denial of the image service installation. In other embodiments, no message is sent. In some embodiments, when the service installation is denied, the SMS 120 can report and / or record the identification of the service installer as a malicious service installer in a blacklist.

[0049] After determining that service installer 110A is authorized to uninstall the service image, SMS 120 performs operations 244-246. At operation 244, SMS 120 deletes the hash of the service image from the list of valid service images of the distributed ledger. At operation 245, SMS 120 also generates and records in the distributed ledger a service uninstall token associated with the service installer identifier and the service image identifier. SMS 120 sends a message including the service uninstall token to service installer 110A at operation 246. The service uninstall token enables service installer 110A to uninstall the service image in the cloud computing system.

[0050] Upon receiving the service uninstall token, service installer 110A sends a request to cloud computing storage system 131 A to uninstall the service image at operation 248. The request includes the service uninstall token and the service image identifier. The request is sent to the cloud computing storage system 131 A in which the service image is to be uninstalled. In some embodiments, the request to uninstall the service is sent in a message signed with the private key of service installer 110A. Upon receiving the request, cloud computing storage system 131 A determines the validity of the service uninstall token at operation 250. In some embodiments, determining the validity of the service uninstall token can include sending a request to SMS 120 to check the service uninstall token against data recorded in the distributed ledger for service installer 110A and the service image identifier. SMS 120 can retrieve from the distributed ledger the stored service uninstall token for service installer 110A identified by the service installer identifier and for the service image identified by the service image identifier. In some embodiments, determining the validity of the service uninstall token can also include determining that the message received from service installer 110A can be used to authenticate service installer 110A, e.g., that the signed message including the request is valid. In response to determining that the service uninstall token is valid, cloud computing storage system 131 A uninstalls the image identified by the service image identifier at operation 252. Cloud computing storage system 131 A also records the hash of the service installer account identifier. Upon determining that the uninstallation is complete, cloud computing storage system 131 A sends an uninstallation confirmation to service installer 110A at operation 254. In some embodiments, cloud computing storage system 131 A can determine at operation 256 that the service uninstall token is not a valid token and reject the uninstallation of the service image. In some embodiments, cloud computing storage system 131 A can send a message to service installer 110A at operation 258 rejecting the uninstallation of the service image to indicate that the service image was not uninstalled.

[0051] Figure 2DA block diagram illustrating example operations for secure execution of a service image according to some embodiments is shown. Once a service image is stored in a cloud computing system (e.g., in cloud computing storage system 131 A) and a hash of the service image and a service installer account identifier are recorded in the distributed ledger, the service image can be securely uploaded and executed by one or more service image executors. For example, a service image executor 133 A (which can be part of cloud computing system 130 A or external to the cloud computing system) can need to fetch the service image from cloud computing storage system 131 A and verify the service image prior to execution of the service image. In some embodiments, the verification of the service image is performed based on the operations of Figure 2D FIG. 2.

[0052] At operation 262, service image executor 133 A sends a request for the service image to cloud computing storage system 131 A. The request includes the service name and the service image identifier. Cloud computing storage system 131 A fetches the service image based on the image service identifier and the service name at operation 264. Cloud computing storage system 131 A sends the service image and the hash of the service installer account identifier to service image executor 133 A at operation 266. Upon receiving the service image, service image executor 133 A generates a second set of one or more hashes of the received service image at operation 268.

[0053] Service image executor 133 A sends a request to SMS 120 to verify the service image prior to execution of the service image at operation 270. SMS 120 receives the request from the service image executor to verify the service image. The request includes the hash of the service installer account identifier and the second set of one or more hashes of the service image fetched by the service image executor from the cloud computing system. At operation 272, SMS 120 determines whether the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger based on the hash of the service installer account identifier. In response to determining that the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger, SMS 120 sends a confirmation that the service image can be executed to the service image executor at operation 274. Upon receiving the confirmation, service image executor 133 A can securely execute the service image at operation 276.

[0054] In some embodiments, the determination of the service image's hash can be performed based on the mechanism of the Trusted Platform Module (TPM) in the service image executor 133A. The TPM creates a certificate based on the service image's private key and the service image's hash, and signs the certificate with the proof identification key SKAIK. In these embodiments, the service image executor can also send the certificate generated by the TPM to the SMS 120 to enable service image verification. The SMS 120 verifies the certificate and the service image's hash received from the service image executor based on information for the service image recorded in the distributed ledger. After determining that the certificate is valid and the service image's hash matches the recorded hash, the service image is verified for execution at the service image executor 133A.

[0055] Reference Figures 1-2D The operations in the flowchart are described using exemplary embodiments. However, it should be understood that the operations in the flowchart may be performed by embodiments of the invention other than those discussed with reference to the other accompanying drawings, and the embodiments of the invention discussed with reference to these other accompanying drawings may perform operations different from those discussed with reference to the flowchart.

[0056] Figure 3A A flowchart illustrating exemplary operations for obtaining a service installer account, according to some embodiments, is shown. Figure 3A The operations can be performed by SMS 120. In one example, when SMS 120 is implemented as multiple SMS nodes, Figure 3A The operation can be performed by an SMS node (e.g., SMS node 121A of DLT) that is part of SMS 120. In operation 302, the service management system (e.g., SMS 120) receives a signed message from a service installer (e.g., service installer 110A). The signed message includes a request for an account at SMS 120, a service installation certificate, and the service installer's public key. In operation 304, SMS 120 determines, at least in part, whether the service installer is authorized to have an account at SMS 120 based on the service installation certificate. The determination at operation 304 may include determining the validity of the signature of the received message based on the public key of service installer 110A. This determination may also include determining, based on the service installation certificate, that the service installer is authorized to access the account in SMS's distributed ledger.

[0057] In response to determining that the service installer is not authorized to have an account at SMS 120, SMS 120 rejects account creation in operation 306. In some embodiments, SMS 120 may send a response with a rejection account creation indication to the service installer 110A.

[0058] Alternatively, in response to determining that the service installer is authorized to have an account at the service management system, the operational flow moves to operations 308-312. At operation 308, the SMS 120 creates an account for the service installer in the distributed ledger. The account is identified with a service installer account identifier that is unique to the service installer. In some embodiments, the service installer account identifier can be a public key of the service installer or a hash of the public key of the service installer. In other embodiments, other types of unique identifiers can be used to uniquely identify the service installer 110A-N. For example, the service installer account identifier can be a randomly generated string that serves as an identifier of the service installer account.

[0059] At operation 310, the SMS 120 records the service installer account identifier and the public key in the distributed ledger. In some embodiments, at operation 311, the SMS 120 can perform a hash operation on the service installer account identifier and can store account information for the service installer in the distributed ledger, using the hash of the service installer account identifier as a key to identify the account information. At operation 313, the SMS 120 sends the service installer account identifier to the service installer.

[0060] Figure 3B A flow diagram illustrating example operations for authorizing installation of a service image is shown in accordance with some embodiments. At operation 312, the SMS 120 receives a first signed message from the service installer 110A, the first signed message including a request to authorize installation of a service image, a service image identifier, a service installer account identifier, and one or more hashes of the service image. In some embodiments, the hashes of the service image are produced by performing a hash operation on one or more files that form code that, when executed on a server of a cloud computing system, causes an application to provide a service to a user. The files can include configuration files that are used to configure the service image. Configuration of the service image based on the files is performed prior to the hash operation on the image files and generation of the hashes. The service image identifier identifies a version of the service image for which installation authorization is sought. In some embodiments, the service installer 110A can have multiple active versions of the same service image that are installed or to be installed in the cloud computing system. In some embodiments, the signed message also includes a public key of the service installer 110A. In other embodiments, the signed message can not include the public key of the service installer 110A, e.g., when the service image identifier is the public key of the service installer 110A.

[0061] At operation 314, the SMS 120 determines whether the service installer is authorized to install the service image identified by the service image identifier in the cloud computing system based on the service installer account identifier and the distributed ledger. In some embodiments, the SMS 120 determines whether the service installer account identifier is associated with a legitimate account in the distributed ledger at operation 316. The SMS 120 also determines whether the public key corresponding to the service installer account identifier stored in the distributed ledger verifies the signature of the signed message in which the request to authorize installation is received at operation 318. In some embodiments, upon determining that the service installer account identifier included in the request is associated with a legitimate account in the distributed ledger and that the public key of the service installer 110A associated with the service installer identifier can be used to verify the signature of the signed message, the SMS 120 determines that the service installer is authorized to install the service image. In other embodiments, upon determining that the service installer account identifier included in the request is not associated with a legitimate account in the distributed ledger or that the public key of the service installer 110A associated with the service installer identifier cannot be used to verify the signature of the signed message, the SMS 120 determines that the service installer 110A is not authorized to install the service image.

[0062] Upon determining that the service installer 110A is not authorized to install the service image, the SMS 120 denies the image service installation at operation 324. In some embodiments, the SMS 120 can send a message to the service installer 110A including the denial of the image service installation. In other embodiments, no message is sent. In some embodiments, when the service installation is denied, the SMS 120 can report and / or record the identification of the service installer as a malicious service installer in a blacklist.

[0063] Upon determining that the service installer 110A is authorized to install the service image, the SMS 120 performs operations 320-322. At operation 320, the SMS 120 records one or more hashes of the service image in the list of valid service images of the distributed ledger. At operation 321, the SMS 120 also generates and records a service installation token associated with the service installer identifier and the service image identifier in the distributed ledger. The SMS 120 sends a second message including the service installation token and the service image identifier to the service installer at operation 322. The service installation token enables the service installer 110A to install the service image in the cloud computing system.

[0064] Figure 3CA flowchart showing exemplary operations performed by a service installer, in accordance with some embodiments, is shown. The service installer 110A sends a signing message to the SMS 120 at operation 332. The signing message includes a request for an account, a service installation certificate, and a public key of the service installer 110A. The message is signed with the private key of the service installer. The private and public keys of the service installer 110A are a pair of public / private encryption keys determined based on an asymmetric encryption mechanism. The service installer 110A receives a service account identifier for the service installer in the distributed ledger of the service management system at operation 334. Upon receiving the service account identifier, the service installer 110A securely stores the service installer account identifier at operation 336. The service installer 110A can use the service installer account identifier to request installation of a service image in one or more cloud computing systems managed via the SMS 120.

[0065] At operation 340, the service installer 110A sends a first signed message including a request to authorize installation of a service image. The first signed message includes a request to authorize installation, a service image identifier, the service installer account identifier, and one or more hashes of the service image. In some embodiments, the hashes of the service image are generated from performing a hash operation on one or more files that form code that, when executed on a server of a cloud computing system, causes an application to provide a service to a user. The files can include configuration files used to configure the service image. Configuration of the service image based on the files is performed prior to the hash operation on the image files and generation of the hashes. The service image identifier identifies a version of the service image for which installation authorization is sought. In some embodiments, the service installer 110A can have multiple active versions of a service image installed or to be installed in a cloud computing system. In some embodiments, the signed message also includes a public key of the service installer 110A. In other embodiments, the signed message can not include the public key of the service installer 110A, e.g., when the service image identifier is the public key of the service installer 110A. The first signed message is signed with the private key of the service installer 110A.

[0066] The service installer receives a second message including a service installation token and the service image identifier at operation 342. The service installation token enables the service installer 110A to install the service image in the cloud computing system.

[0067] Upon receiving the service installation token, the service installer 110A sends a request to the cloud computing system to install the service image at operation 344. The request includes the service installation token, the service image, the service image identifier, and a hash of the service installer account identifier. The request is sent to the cloud computing storage system 131 A in which the service image is to be installed. Upon receiving the request, the cloud computing storage system 131 A determines the validity of the installation token. In response to determining that the service installation token is valid, the cloud computing storage system 131 A installs the image with the associated service image identifier. The cloud computing storage system 131 A also records the hash of the service installer account identifier. Upon determining that the installation is complete, the service installer 110A receives a confirmation of the installation at operation 346. In some embodiments, the cloud computing storage system 131 A can determine that the service installation token is not a valid token and deny installation of the service image. In some embodiments, the cloud computing storage system 131 A can send a deny service image installation message to the service installer 110A to indicate that the service image was not installed. In these embodiments, instead of receiving a confirmation of the installation, the service installer 110A can receive a deny installation message from the cloud computing system.

[0068] Figure 3D A flowchart illustrating example operations for authorizing uninstallation of a service image is shown in accordance with some embodiments. At operation 352, the SMS 120 receives a signed message from the service installer 110A that includes a request to authorize uninstallation of a service image that was previously installed in the cloud computing storage system. The signed message also includes a service image identifier and a service installer account identifier. The service image identifier identifies a version of the service image for which uninstallation authorization is sought. In some embodiments, the service installer 110A can have multiple active versions of the service image installed and can send one or more identifiers of the service image to request uninstallation.

[0069] At operation 354, the SMS 120 determines whether the service installer is authorized to uninstall the service image identified by the service image identifier based on the service installer account identifier and the distributed ledger. In some embodiments, the SMS 120 determines whether the service installer account identifier is associated with a legitimate account in the distributed ledger (operation 356). The SMS 120 also determines whether the public key corresponding to the service installer account identifier stored in the distributed ledger verifies the signature of the signed message in which the request to authorize installation was received (operation 358). In some embodiments, upon determining that the service installer account identifier included in the request is associated with a legitimate account in the distributed ledger and that the public key of the service installer 110A associated with the service installer identifier can be used to verify the signature of the signed message, the SMS 120 determines that the service installer 110A is authorized to uninstall the service image. In other embodiments, upon determining that the service installer account identifier included in the request is not associated with a legitimate account in the distributed ledger or that the public key of the service installer 110A associated with the service installer identifier cannot be used to verify the signature of the signed message, the SMS 120 determines that the service installer 110A is not authorized to uninstall the service image.

[0070] Upon determining that the service installer 110A is not authorized to uninstall the service image, the SMS 120 denies the image service uninstall at operation 364. In some embodiments, the SMS 120 can send a message including the denial of the image service installation to the service installer 110A at operation 366. In other embodiments, no message is sent. In some embodiments, when the service installation is denied, the SMS 120 can report and / or record the identification of the service installer as a malicious service installer in a blacklist.

[0071] Upon determining that the service installer 110A is authorized to uninstall the service image, the SMS 120 performs operations 360-362. At operation 360, the SMS 120 deletes the hash of the service image from the list of valid service images of the distributed ledger. At operation 361, the SMS 120 also generates and records a service uninstall token associated with the service installer identifier and the service image identifier in the distributed ledger. The SMS 120 sends a message including the service uninstall token to the service installer 110A at operation 362. The service uninstall token enables the service installer 110A to uninstall the service image in the cloud computing system.

[0072] Figure 3EA flow diagram illustrating example operations for requesting uninstallation of a service image according to some embodiments is shown. At operation 370, service installer 110A sends a signed message including a request to authorize uninstallation of a service image. The first signed message includes the request to authorize uninstallation, a service image identifier, and a service installer account identifier. The service image identifier identifies a version of the service image for which installation authorization is sought. In some embodiments, service installer 110A can have multiple active versions of a service image installed in the cloud computing system. In some embodiments, the request can include more than one service image identifier identifying multiple service images to be uninstalled. The signed message is signed with a private key of service installer 110A.

[0073] The service installer receives a message including a service uninstall token and a service image identifier at operation 372. The service uninstall token enables service installer 110A to uninstall a service image in the cloud computing system. Upon receiving the service uninstall token, service installer 110A sends a request to uninstall the service image to the cloud computing storage system 131A at operation 374. The request includes the service uninstall token, the service image identifier, and a hash of the service installer account identifier. The request is sent to the cloud computing storage system 131A in which the service image is to be uninstalled. Upon receiving the request, cloud computing storage system 131A determines the validity of the service uninstall token. In response to determining that the service uninstall token is valid, cloud computing storage system 131A uninstalls the image associated with the service image identifier. Upon determining that the uninstallation is complete, service installer 110A receives a confirmation of the uninstallation at operation 376. In some embodiments, cloud computing storage system 131A can determine that the service uninstall token is not a valid token and deny uninstallation of the service image. In some embodiments, cloud computing storage system 131A can send a deny service image uninstallation message to service installer 110A to indicate that the service image was not uninstalled. In these embodiments, instead of receiving a confirmation of the uninstallation, service installer 110A can receive a deny uninstallation message from the cloud computing system.

[0074] Figure 3F A flow diagram illustrating example operations for securely executing a service image according to some embodiments is shown. Once a service image is stored in a cloud computing system (e.g., cloud computing storage system 131A) and a hash of the service image and a service installer account identifier are recorded in a distributed ledger, the service image can be securely uploaded and executed by one or more service image executors. For example, service image executor 133A (which can be part of cloud computing system 130A or external to the cloud computing system) can need to fetch the service image from cloud computing storage system 131A and validate the service image prior to execution of the service image. In some embodiments, based on the service image being stored in the cloud computing storage system 131A and the hash of the service image and the service installer account identifier being recorded in the distributed ledger, the service image executor 133A can be able to validate the service image without having to download the service image from the cloud computing storage system 131A. For example, the service image executor 133A can be able to validate the service image by verifying the hash of the service image and the service installer account identifier recorded in the distributed ledger. Figure 3Fto perform verification of the service image.

[0075] The service management system receives, at operation 380, a request from the SMS 120 to verify a service image prior to execution of the service image. The request includes a hash of the service installer account identifier and a second set of one or more hashes of the service image retrieved by the service image executor from the cloud computing system. At operation 382, the SMS 120 determines, based on the hash of the service installer account identifier, whether the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger. In response to determining that the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger, the SMS 120 sends, at operation 384, a confirmation to the service image executor that the service image can be executed. Upon receiving the confirmation, the service image executor 133A can securely execute the service image. In some embodiments, in response to determining that the second set of hashes of the service image does not correspond to the hashes of the service image stored in the distributed ledger, the SMS 120 confirms, at operation 386, that the service cannot be executed. In some embodiments, the SMS 120 can send a message to the service image executor indicating that the service image cannot be executed. In alternative embodiments, the SMS 120 can not send a message.

[0076] Architecture:

[0077] Electronic devices use machine-readable media (also known as computer-readable media) to store and transmit (both internally and to and from other electronic devices over networks) code (which includes software, and is sometimes referred to as computer program code or computer programs) and / or data, machine-readable media including, for example, machine-readable storage media (e.g., magnetic disks; optical disks; solid state drives; read-only memory (ROM); flash memory devices; phase-change memory) and machine-readable transmission media (also referred to as carrier waves) (e.g., electrical, optical, radio, acoustic, or other form of propagated signals - such as carrier waves, infrared signals, etc.). Thus, an electronic device (e.g., a computer) includes hardware and software, e.g., a set of one or more processors (e.g., where the processor(s) are microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application specific integrated circuits, field programmable gate arrays, other electronic circuits, combinations of the foregoing, or the like) coupled to one or more machine-readable storage media to store code for execution on the set of processors and / or to store data. For instance, an electronic device can include non-volatile memory including code because, even when the electronic device is turned off (when power is removed), the non-volatile memory can retain the code / data, and when the electronic device is turned on, portions of the code to be executed by the processor(s) of the electronic device are typically copied from the slower non-volatile memory of the electronic device into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) for execution by the processor(s) of the electronic device. A typical electronic device also includes a set of one or more physical network interfaces (NIs) to establish network connections with other electronic devices (to transmit and / or receive code and / or data using propagated signals). For example, the set of physical NIs (or the set of physical NIs in combination with the set of processors executing code) can perform any formatting, encoding, or converting to allow the electronic device to transmit and receive data (whether through wired and / or wireless connections). In some embodiments, the physical NIs can include radio circuitry capable of receiving data from and / or emitting data to other electronic devices via wireless connections. The radio circuitry can include a transmitter, a receiver, and / or a transceiver suitable for radio frequency communications. The radio circuitry can convert digital data into radio signals having appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signals can then be transmitted to the appropriate recipient via an antenna. In some embodiments, the set of physical NIs can include a network interface controller (NIC), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC can facilitate connecting the electronic device to other electronic devices, allowing them to communicate via wires by plugging cables into physical ports connected to the NIC. Different combinations of software, firmware, and / or hardware can be used to implement one or more parts of embodiments of the present invention.

[0078] A network device (ND) is an electronic device that is communicatively coupled to other electronic devices (e.g., other network devices, end-user devices) on a network. Some network devices are "multiple services network devices" that provide support for multiple network functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, quality of service, and / or user management), and / or provide support for multiple application services (e.g., data, voice, and video, etc.).

[0079] Figure 4 A block diagram of a network device in which verification of a service image can be performed is shown in accordance with some embodiments. According to one embodiment, network device 430 includes hardware 405. Hardware 405 includes network communication interface 460 coupled with computer-readable storage medium 412. Computer-readable storage medium 412 can also include service management code 434. Service management code 434, when executed on one or more processors 414, causes the network device to perform the operations of the service management system described in reference to one or more of Figures 1-3F

[0080] ​While one embodiment does not implement virtualization, alternative embodiments can use different forms of virtualization. For example, in one such alternative embodiment, virtualization layer 420 represents a kernel of an operating system (or a shim executing on a base operating system) that allows creation of multiple instances (referred to as software containers, which can each be used to execute one (or more) of the sets of applications); where the multiple software containers (also referred to as virtualization engines, virtual private servers, or jails) are user spaces (typically virtual memory spaces) that are separate from each other and from a kernel space in which the kernel of the operating system runs; and where the set of applications running in a given user space cannot access the memory of other processes unless explicitly allowed. In another such alternative embodiment, virtualization layer 420 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications run on top of a guest operating system within an instance 440 referred to as a virtual machine running on top of the hypervisor (which in some cases can be considered a form of software container with strict isolation)— the guest operating system and applications can not know that they are running on a virtual machine rather than on a "bare metal" host electronic device, or through para-virtualization, the operating system and / or applications can know of the presence of virtualization for optimization purposes. In other alternative embodiments, one, some or all of the applications are implemented as unikernels, which can be generated by directly using an application to compile only a limited set of libraries that provide only the specific OS services needed by the application (e.g., a library operating system (LibOS) that includes drivers / libraries of OS services). Because unikernels can be implemented to run directly on hardware 705, to run directly on a hypervisor (in which case the unikernels are sometimes described as running within LibOS virtual machines), or in software containers, embodiments can be implemented entirely using unikernels running directly on a hypervisor represented by virtualization layer 420, unikernels running within software containers represented by instances, or as a combination of unikernels and the above-described techniques (e.g., unikernels and virtual machines both running directly on a hypervisor, unikernels and sets of applications running in different software containers).

[0081] The instantiation of one or more applications in one or more sets and virtualization (if implemented) is collectively referred to as a software instance. Each set of applications, the corresponding virtualization construct (if implemented), and the portion of the hardware on which they are executing (hardware dedicated to that execution and / or time-slices of hardware temporarily shared) form a separate virtual network element.

[0082] Although the flow diagrams in the Figures show a particular order of operations, it is understood that the order of operations can be changed as an alternative embodiment can perform operations in a different order, combine certain operations, overlap certain operations, etc.

[0083] Although the present application has been described in accordance with numerous embodiments, one skilled in the art will recognize that the present application can be practiced without one or more of the details of the above-described embodiments, or with other techniques. Herein, this description and the examples have been meant to be illustrative and not intended to limit the scope of the application.

Claims

1. A method performed by a network node of a service management system, the method comprising: receiving (312), from a service installer, a first signed message comprising a request to authorize installation of a service image, a service image identifier, a service installer account identifier, and one or more hashes of the service image, wherein the service installer account identifier identifies an account of the service installer in a distributed ledger; and in response to determining (314), based on the service installer account identifier and the distributed ledger, that the service installer is authorized to install the service image identified with the service image identifier in a cloud computing system, performing the following operations: recording (320), in a list of valid service images of the distributed ledger, the one or more hashes of the service image; and sending (322), to the service installer, a first message comprising a first service installation token and the service image identifier, wherein the first service installation token causes the service installer to install the service image in the cloud computing system.

2. The method of claim 1, wherein, the performing further comprises: recording (321), in the distributed ledger, the first service installation token.

3. The method of any one of claims 1-2, further comprising: receiving (380), from a service image enforcer, a request to validate a service image, the request comprising a hash of the service installer account identifier and a second set of one or more hashes of the service image retrieved by the service image enforcer from the cloud computing system; determining (382), based on the hash of the service installer account identifier, whether the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger; and in response to determining that the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger, sending (384), to the service image enforcer, a confirmation that the service image can be executed.

4. The method of any one of claims 1-2, wherein, the determining (314), based on the service installer account identifier and distributed ledger, that the service installer is authorized to install a service image comprises: determining (316) that the service installer account identifier is associated with a legitimate account in the distributed ledger; and determining (318) that a public key corresponding to the service installer account identifier stored in the distributed ledger verifies a signature of the first signed message.

5. The method of any of claims 1-2, further comprising: prior to receiving (312) the request to authorize installation of a service image, receiving (302), from a service installer, a second signed message comprising a request for an account at the service management system, a service installation certificate, and a public key of the service installer; and in response to determining (304), based at least in part on the service installation certificate, that the service installer is authorized to have an account at the service management system, performing the following operations: creating (308), in a distributed ledger, an account for the service installer identified with a service installer account identifier, recording (310), in the distributed ledger, the service installer account identifier and the public key of the service installer, and sending (313) the service installer account identifier to the service installer.

6. The method of any of claims 1-2, further comprising: receiving (352), from a service installer, a third signed message including a request to authorize uninstallation of a service image, the service image identifier, and the service installer account identifier; and in response to determining (354), based on the service installer account identifier and the distributed ledger, that the service installer is authorized to uninstall the service image identified with the service image identifier from the cloud computing system, performing the following operations: removing (360) the one or more hashes of the service image from the list of valid service images of the distributed ledger, and sending (362) a third message including a service uninstall token and the service image identifier to the service installer, wherein the service uninstall token causes the service installer to uninstall the service image from the cloud computing system.

7. A machine-readable medium storing computer program code which, when executed by a computer, performs the method steps of any of claims 1-6.

8. A network node of a service management system, the network node comprising: one or more processors; and a non-transitory computer-readable storage medium storing instructions that, when executed by the one or more processors, cause the network node to: receive (312), from a service installer, a first signed message including a request to authorize installation of a service image, a service image identifier, a service installer account identifier, and one or more hashes of the service image, wherein the service installer account identifier identifies an account of the service installer in a distributed ledger; and in response to determining (314), based on the service installer account identifier and the distributed ledger, that the service installer is authorized to install a service image identified with the service image identifier in a cloud computing system, performing the following operations: recording (320) the one or more hashes of the service image in a list of valid service images of the distributed ledger, and sending (322) a first message including a first service install token and the service image identifier to the service installer, wherein the first service install token causes the service installer to install the service image in the cloud computing system. the performing further comprising:

9. The network node of claim 8, wherein, recording (321) the first service install token in the distributed ledger. the network node further performing the following operations:

10. The network node of any of claims 8-9, wherein, ​ receive (380), from a service image enforcer, a request to validate a service image, the request including a hash of the service installer account identifier and a second set of one or more hashes of the service image retrieved by the service image enforcer from the cloud computing system; determine (382), based on the hash of the service installer account identifier, whether the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger; and in response to determining that the second set of one or more hashes of the service image corresponds to the one or more hashes of the service image stored in the distributed ledger, send (384) a confirmation to the service image enforcer that the service image can be executed.

11. The network node of any of claims 8-9, wherein, determine (314), based on the service installer account identifier and a distributed ledger, that the service installer is authorized to install a service image includes: determine (316) that the service installer account identifier is associated with a legitimate account in the distributed ledger; and determine (318) that a public key corresponding to the service installer account identifier stored in the distributed ledger verifies a signature of the first signed message.

12. The network node of any of claims 8-9, wherein, The network node further performs the following operations prior to receiving (312) the request to authorize installation of a service image: receive (302), from a service installer, a second signed message including a request for an account at the service management system, a service installation certificate, and a public key of the service installer; and in response to determining (304), based at least in part on the service installation certificate, that the service installer is authorized to have an account at the service management system, perform the following operations: create (308), in a distributed ledger, an account for the service installer identified with a service installer account identifier, record (310), in the distributed ledger, the service installer account identifier and the public key of the service installer, and send (313) the service installer account identifier to the service installer.

13. The network node of any of claims 8-9, wherein, The network node further performs the following operations: receive (352), from a service installer, a third signed message including a request to authorize uninstallation of the service image, the service image identifier, and the service installer account identifier; and in response to determining (354), based on the service installer account identifier and the distributed ledger, that the service installer is authorized to uninstall the service image identified with the service image identifier from the cloud computing system, perform the following operations: remove (360), from the active service image list of the distributed ledger, the one or more hashes of the service image, and send (362), to the service installer, a third message including a service uninstallation token and the service image identifier, wherein the service uninstallation token causes the service installer to uninstall the service image from the cloud computing system.

Images