Creation and execution of secure containers

Abstract

A computer-implemented method for creating a secure software container may be provided. The method includes providing a first layered software container image, converting all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume including a set of blocks, wherein each layer includes an incremental difference to a next lower layer, encrypting each block in the set of blocks of a portion of the layer, and storing each encrypted set of blocks together with unencrypted metadata as a layer of an encrypted container image, the unencrypted metadata being used to reconstruct an order of the set of blocks equal to the order of the first layered software container image, thereby creating a secure encrypted software container.

Description

Technical Field

[0001] The present invention generally relates to secure computing, and more particularly to a computer-implemented method for creating a secure software container. The present invention further relates to a related secure container system and a computer program product for creating a secure software container. Background Art

[0002] Currently, cloud computing has been one of the hottest topics in the IT (Information Technology) industry. Individuals as well as small and medium-sized companies and large enterprises continue to outsource computing tasks to cloud computing providers that operate large cloud computing centers. On the other hand, one of the biggest concerns in the IT industry is data security. Therefore, in private computing environments (i.e., enterprise computing centers), security is an important topic, so that the relevance of data and computer security in cloud computing environments is pushed forward to large enterprises at the C-level.

[0003] Some data security issues can be addressed by encrypting the relevant data when transmitting it over a public network (e.g., the Internet) and / or when storing it on a storage device (especially in light of new government data security regulations such as GDPR (General Data Protection Regulation of the European Union)). However, if the data must be processed, the data as well as the programs may be more or less accessible to the administrator of the cloud computing center. This can be seen as an open door to data security vulnerabilities.

[0004] One attempt to address the potential conflict between higher usage of cloud computing resources on the one hand and higher data security and data privacy requirements on the other hand is to use secure virtual machines on a secure computing platform, for example, in the form of a trusted computing environment that uses a hardware security module (HSM) and allows encryption of data as well as applications and virtual machines (VMs) in a tight boundary.

[0005] On the other hand, one of the current technologies that virtual machine technology has advanced and is often used is "container computing", which can basically be viewed as multiple applications in a sandbox based on a certain scope of the operating system, without the full overhead of the operating system within each virtual machine of each container. As a result, many common services that are usually provided by the operating system and related middleware can be shared between different containers in one operating system. However, this may have the following consequences: from a security perspective, data and programs in containers may not be managed like other IT resources (like virtual machines).

[0006] One of the most commonly used platforms for software containers is the Docker Engine from Docker Inc. In Linux environments, it has quickly become the standard for packaging microservice applications, although the technology is not limited to microservices. Basically, it can be used to package of-the-shelf commercial and monolithic applications to provide isolation and portability.

[0007] In this context, a series of publications have appeared: Document US 2018 / 0309747 A1 discloses a computer system and method in which an agent execution program runs simultaneously with a security module, which obtains an agent API key from a user when initially executed. This key is transmitted to a grid computing system. When the API key is valid, an agent identity token is received from the grid, usually by a cryptographic token generation protocol, and stored in a secure data store associated with the agent execution program. Information for evaluating the integrity of the agent execution program is collected using an agent self-verification factor.

[0008] On the other hand, a method for securely managing a Docker image is known from document WO 2018 / 007213A1, comprising a secure storage area for storing data encrypted with a key set. The Docker image comprises a secure driver, and the method comprises a series of steps: (i) the secure driver retrieves the key set from a trusted storage only if the incoming credentials provided to the secure driver match the current credentials, (ii) the secure driver accesses the secure storage area and decrypts the data using the key set, and (iii) the secure driver sends the data outside the Docker image.

[0009] However, there still exists a gap between the sophisticated management of software containers on the one hand and security issues on the other hand. Thus, the proposed concept aims to provide increased security for data and applications in software containers. Summary of the invention

[0010] According to one aspect of the present invention, a computer-implemented method for creating a secure software container may be provided. The method may include providing a first layered software container image, and converting all files of each layer of the first layered software container image except for corresponding metadata into a volume. The volume may include a set of blocks, wherein each layer may include an incremental difference with the next lower layer. The method may further include: encrypting each block in the set of blocks of a partial layer; storing each encrypted set of blocks together with unencrypted metadata as a layer of an encrypted container image, and the unencrypted metadata is used to reconstruct the order of the set of blocks equal to the order of the first layered software container image. Thus, a secure encrypted software container can be created.

[0011] According to another aspect of the present invention, a secure container system for creating a secure software container may be provided. The secure container system may include a receiving unit for receiving a first layered software container image, a conversion unit for converting all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume including a block set, wherein each layer includes an incremental difference with the next lower layer, an encryption module for encrypting each block in the block set of a partial layer, and a storage unit for storing each encrypted block set together with unencrypted metadata as a layer of an encrypted container image, the unencrypted metadata being used to reconstruct an order of block sets equal to the order of the first layered software container image. Therefore, the secure container system may be enabled to create a secure encrypted software container.

[0012] The proposed computer-implemented method for creating a secure software container may provide multiple advantages and technical effects:

[0013] The proposed concept delivers against at least three key data and application security requirements. First, by using techniques to hide the contents of a virtual machine (including its memory) from privileged administrators (even hypervisor administrators), it is achieved that from the perspective of the container host and its privileged system administrators, no one can view and understand the contents of the container's image, i.e., the software container file. Moreover, when the container is executed in memory, access to the container can be prevented, resulting in confidential and secure execution of the container.

[0014] Secondly, the registry used to store the container image and any of its administrators are excluded from understanding what is going on within the container image. Likewise, the group of people who typically have (in many ways uncontrollable) access to the container image can be excluded from understanding the true content of the managed software container. For example, they cannot understand and see files or executable code or data. As a third core advantage, it can be mentioned that container image properties such as layering, deduplication methods used (e.g., CoW [copy on write], thin-provision), etc.) and typical processing (such as typical aspects of the management of software containers) can be retained. In addition to encrypting the container images used, the unchanged management and processing of containers allows the confidentiality level of existing solutions to be improved without changing the overall solution.

[0015] Thus, the proposed concept can allow running software container workloads in an environment that is accessible to normal privileged administrators, while keeping the confidentiality of the contents of the software container image secure. Thus, it is also possible to use non-trusted computing environments (e.g., where there is no trust in the system administrator) and still ensure that the program code, files and data (including its main memory / RAM during execution) cannot be seen by anyone other than the creator of the software container.

[0016] This concept goes beyond secure execution of virtual machines, possibly adding security keys only at the price of a higher degree of indirection and losing the operational advantages of software containers. In the context of virtual machines, until today it has been necessary to acknowledge that without secure execution the confidentiality of the contents of software containers cannot be guaranteed. The proposed concept is closing that gap and clearly goes beyond the protection of namespaces alone or even unprotected virtual machines to provide isolated workspaces for software containers.

[0017] In the following, additional embodiments of the inventive concept applicable to the method and the related system will be described.

[0018] According to a preferred embodiment of the method, storing each encrypted set of blocks may also include storing metadata of the first layered software container image. The metadata may include environment variables, commands, ports to be used, etc. The metadata may be encrypted or unencrypted. However, even if the metadata is not encrypted, unauthorized personnel cannot tell anything about the true contents of the secure software container.

[0019] According to an advantageous embodiment of the method, each of the layers stored in the encrypted container image (i.e., as a file) can have thin provisioning applied and can also include thin provisioning metadata, e.g., about which blocks have valid data. This can lead to the advantage of thin provisioning, where only those storage areas that actually hold valid, active data are actually occupied.

[0020] According to a useful embodiment of the method, the name of each file of the layer of the encrypted container image is a hash value of the content of the file. Thus, no additional metadata may be required. It can be assumed that by the entropy of the content on the file, a unique file name can be generated using this proposed method step.

[0021] According to an advantageous embodiment, the method may further include providing a virtual machine operating system, in particular a launcher for the secure software container, and a decryption key. The decryption key may correspond to an encryption key used to encrypt each block in the set of blocks. Thus, the secure software container may be unpacked, the layers may be brought to the original order, and the application included in the secure software container may be launched.

[0022] According to another advantageous embodiment, the method may also include providing a secure container execution environment that is capable of launching a virtual machine with a virtual machine operating system. In this way, a stack of components may be completed to actually begin executing an application encapsulated into a secure software container. Furthermore, the secure container execution environment may also be protected in a manner that is virtually impossible to compromise.

[0023] For reasons of completeness and according to a preferred embodiment of the method, starting the virtual machine may include decrypting the set of blocks of the encrypted container image using a decryption key. Only the owner of the application within the secure software container has access to the key. Thus, providing the decrypted version of the secure software container and starting the required environment can be performed automatically in one go.

[0024] According to a further preferred embodiment, the method may also include rebuilding the first layered software container image in the order of the layers of the first layered software container image. Metadata indicating the original order of the layers of the unencrypted software container may also be included to facilitate this method step.

[0025] According to one allowed embodiment of the method, the layers above the decrypted secure container image (i.e., the layers above the reconstructed first layered software container image) may allow read / write access, wherein the layers below the top layer allow read-only access. Thus, according to the thin provisioning model, write operations (according to the copy-on-write paradigm) may be performed only in the top layer where the deltas or differences from the previous version of the file are stored. A view vertically (in a virtual sense) from the top layer through all other layers towards the lowest layer will deliver all information to reconstruct the last version of the corresponding file.

[0026] Another advanced and advantageous embodiment of the method according to claim 5, wherein the secure container execution environment is protected by secure firmware (typically using a hardware security module (HSM), i.e., a cryptographic card), preventing privileged users and / or other processes from accessing the virtual machine, and wherein the virtual machine operating system, launcher, and decryption keys are also each encrypted.

[0027] Thus, according to another advantageous embodiment of the method, the secure firmware cooperates with a hardware security module. This technology can deliver the most secure execution environment for applications and data in virtual machines and related software containers. Such a security module is a necessary requirement for executing secure firmware. Without such a hardware-based device, none of the secure firmware, hypervisor, virtual machine, or software container's application(s) are executable.

[0028] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in conjunction with a computer or any instruction execution system. For purposes of this description, a computer-usable or computer-readable medium may be any device that may contain means for storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] It should be noted that embodiments of the invention are described with reference to different subject matters. In particular, some embodiments are described with reference to method type claims, while other embodiments are described with reference to apparatus type claims. However, a person skilled in the art will gather from the above and following description that, unless otherwise stated, any combination of features relating to different subject matters, in particular any combination of features of method type claims and features of apparatus type claims, in addition to any combination of features belonging to one type of subject matter, is deemed to be disclosed in this document.

[0030] The aspects defined above and further aspects of the invention are apparent from the examples of embodiment to be described hereinafter and are explained with reference to examples of embodiment, but to which the invention is not limited.

[0031] Preferred embodiments of the present invention will be described by way of example only and with reference to the following drawings:

[0032] Figure 1 A block diagram of an embodiment of a computer-implemented method of the present invention for creating a secure software container is shown.

[0033] Figure 2 A block diagram of a conversion process from an unencrypted software container to an encrypted software container storable in a container library is shown.

[0034] Figure 3 A block diagram illustrating an embodiment of a complete stack of involved elements for executing a secure software container is shown.

[0035] Figure 4 Thin provisioning and linking of blocks in secure software containers is shown.

[0036] Figure 5 An embodiment of a first portion of a flow chart for forming a secure software container is shown.

[0037] Figure 6 An embodiment of a second portion of a flow chart for forming a secure software container is shown.

[0038] Figure 7An embodiment of a first portion of a flow diagram for executing a secure software container is shown.

[0039] Figure 8 An embodiment of a second portion of a flow chart for executing a secure software container is shown.

[0040] Fig. 9 A block diagram of an embodiment of a secure container system is shown.

[0041] Fig.10 A block diagram of a computing system including a secure container system is shown. DETAILED DESCRIPTION

[0042] In the context of this specification, the following conventions, terms and / or expressions may be used:

[0043] The term "secure software container" may refer to a software container that is protected from unauthorized access by unauthorized personnel. Thus, the content of the software container can be encrypted so that unauthorized personnel cannot determine what is stored in the software container. Basically, the software container can be regarded as a sandbox provided by the operating system to determine the scope mechanism, which is used for applications. Applications in these sandboxes have no visibility to the rest of the operating system or other container sandboxes. Since all application sandboxes run on the same operating system instance, compared with running these applications directly as applications under the operating system, minimal overhead is created when running applications in container sandboxes. Specifically, virtualization overhead is not applied. Therefore, the software container (ultimately together with the relevant metadata) can be regarded as an application executed only in the container sandbox, that is, the core function that distinguishes one container sandbox from another container sandbox. In container technology, the container image describes an immutable encapsulation of an application including all files presented to the container instance. The "blueprint" of the application can be shared between container instances and can also be exchanged with other container hosts. A container instance is a running container that uses a container image as the starting point of its (root) file system. Docker can currently be regarded as a leading software container technology.

[0044] It may also be noted that not all layers of a secure software container have to be encrypted. Layers comprising common software components, such as components of an operating system (e.g., Ubuntu), may remain unencrypted. These components may be common to multiple containers, such that encryption may not be required, since their functionality is known anyway. However, the core application blocks and associated data may be considered as characterizing components of a software container. Therefore, these characterizing components may be encrypted as part of a secure software container. However, for reasons of completeness, it may be noted that all layers of a software container may of course be encrypted. It may also be possible to encrypt those parts that may be common to multiple software containers with another encryption method (e.g., only another key or a completely different encryption method) if compared to the core part of the container (i.e., the application).

[0045] The term "first layered software container image" may refer to a stack of layers by which a software container may be defined. The storage technology used for the different layers may be based on thin provisioning / sparse storage. An application may only have write access (and read access) to the top layer. Layers below the top layer may be read-only.

[0046] The term “metadata” may mean “data about data.” Here, the metadata may include information about different layers of the software container, and in particular, information about the correct order of the different layers in order to reconstruct the original software container after decrypting the block-based secure software container.

[0047] The term "volume" herein may refer to a storage system in the form of a virtual storage device. It consists of a collection of data blocks. If a volume is virtual, all of its data is backed up by the file serving as the virtual volume. When a thin provisioning mechanism is used, unused data blocks may be marked accordingly in the volume, which may result in reduced space consumption for the file serving the virtual volume.

[0048] The term "block set" may refer to a group of storage blocks, eg, a contiguous sequence of concatenated blocks of a storage device.

[0049] The term "delta difference" may denote the delta between two different layers of a secure software container. This concept may be generally used for the thin provisioning concept. If the sequence of different layers can be reflected for the sequence of new and / or updated data, the complete information (application as well as associated data) may be reconstructed. Using the delta difference concept makes it possible to use only the storage capacity that is really needed (i.e., thin provisioning), although the blocks of each layer may provide virtually more space (up to the storage limit of a specific layer or volume).

[0050] The term "portion of layers" may refer to a certain number of layers that may be less than the total number of layers of the software container. As described above, it may not be necessary to encrypt all layers of the software container. Some lower layers, including standard software components (e.g., a portion of an operating system), may remain unencrypted. However, in other embodiments, these layers may also be encrypted.

[0051] The term "encrypted container image" may refer to a sequence of layers of a secure software container, which may include information of a first layered software container image in encrypted form.

[0052] The term “order of a set of blocks” may refer to a sequence of blocks in order to rebuild different layers of a secure software container.

[0053] The term "secure encrypted software container" may refer to a secure software container herein. The fact that a secure software container includes an encryption layer may be considered as a given within this document.

[0054] The term "thin provisioning" may refer to the use of virtualization techniques to give the appearance of having more physical resources than are actually available. If the system always fully backs up virtualized resources, all capacity must be initially provisioned. The term thin provisioning may be applied to the disk layer, but may refer to an allocation scheme for any resource. For example, real memory in a computer can typically be thinly provisioned to running tasks using some form of address translation technology that performs virtualization. Each task can act as if it has real memory allocated. The sum of the allocated virtual memory can be assigned to a task, which may typically exceed the sum of the real memory. The same applies to layers and software containers. In some contexts, thin provisioning may also be referred to as "sparse volumes."

[0055] The term "hash value" may refer to the result of a hash function that can be used to map data of arbitrary size to data of fixed size. The value returned by a hash function is called a hash value, hash code, digest, or simply a hash. Hash functions are often used in conjunction with hash tables, which are common data structures used in computer software for fast data lookups. Hash functions speed up table or database lookups by detecting duplicate records in large files. One such application is finding similar stretches in DNA sequences. Because the calculation of a hash value is a one-way method, it may not be possible to uniquely determine the original value from the hash value. Therefore, this technique is widely used in cryptography.

[0056] The term "virtual machine operating system" may refer to an operating system that is a component of a virtual machine of a virtual server that is executed on a hypervisor. Different virtual machine operating systems may not affect other functions. This technology can be widely used in operating systems like Linux. However, mainframe and midrange operating systems can also use this technology.

[0057] The term "starter" may refer to a program that is capable of initiating the start of execution of a secure software container. The starter may also take over the initiation of the decryption process and reorder the decrypted blocks to reconstruct the original layers of the first layered software container.

[0058] The term "decryption key" may refer to a software component tool used to reset the encrypted context to its original context so that it can be read without any decryption function. So, it can be plain text.

[0059] The term "secure container execution environment" may refer to a software component that can accept a secure encrypted software container (or also a secure encrypted software container image) and run a container instance based on it. It may choose to run the container in a virtual machine that has just been created to run the container. The virtual machine may be secure so that a privileged administrator of the secure container execution environment (which also becomes a hypervisor when the virtual machine is started) may not be able to access data inside the virtual machine running the container. To achieve decryption of the secure encrypted software container (image), it may use a decryption key that may be provided to the (virtual machine) operating system and start a program during the startup of the container instance.

[0060] The term "hardware security module" (HSM) may refer to a physical computing device that can protect and manage digital keys for strong authentication and provide cryptographic processing. These modules may traditionally come in the form of a plug-in card or external device attached to a computer or network server or directly to the CPU.

[0061] The term "Docker container" may represent an instance of operating system-level virtualization (also known as containerization). It may represent an operating system feature in which the kernel may allow the existence of multiple isolated user space instances. Such instances (referred to as (software) containers, partitions, virtual environments (VEs), or jails (FreeBSD jails or chroot jails)) may look like real computers from the perspective of programs running in them. Computer programs running on ordinary operating systems can see all the resources of the computer (connected devices, files and folders, network shares, CPU power, quantifiable hardware capabilities). However, programs running in containers may only see the contents of the container and the devices assigned to the container. Therefore, containers may be isolated from each other, similar to virtual machines being isolated from each other. The concepts proposed here can be advantageously implemented using Docker containers.

[0062] In the following, a detailed description of the drawings will be given. All descriptions in the drawings are schematic. First, a block diagram of an embodiment of a computer-implemented method of the present invention for creating a secure software container is given. Afterwards, additional embodiments and embodiments of a secure container system for creating a secure software container will be described.

[0063] Figure 1 A block diagram of an embodiment of a computer-implemented method 100 for creating a secure software container (e.g., a secure Docker container) is shown. The method may include providing (102) a first layered software container image, specifically, an image including "delta-based" (i.e., thin-provisioned) layers.

[0064] The method 100 comprises: at 104, further converting all files of each layer of the first layered software container image except corresponding metadata into a volume (specifically, a volume including a file system). The volume comprises a set of blocks (specifically blocks managed by a storage disk), wherein each layer comprises an incremental difference to the next lower layer. It may also be mentioned that the metadata is especially all those metadata required to describe how to process the container (i.e., how the different layers are related to each other).

[0065] In addition, method 100 includes encrypting each block in the set of blocks for the portion of the layer (106). This may be performed using an encryption key known only to the creator of the secure container. It may also be noted that not all layers must be encrypted. In particular, those layers that are identical for all software containers may not need to be encrypted. An example may be a base operating system layer, e.g., an "Ubuntu layer".

[0066] Furthermore, the method 100 includes storing (108) each encrypted set of blocks as a layer of the encrypted container image, and (particularly, represented as a file) together with unencrypted metadata (e.g., having a pointer to the parent layer) for reconstructing an order of the set of blocks equal to the order of the first layered software container image. This may then result in the same number of block devices as the number of layers of the original software container (i.e., the first layered software container image). Thus, a secure encrypted layered software container is created.

[0067] Figure 2 A block diagram 200 of a conversion process from an unencrypted software container 202 to an encrypted software container that can be stored in a container repository is shown. A first layered software container image 202 (also shown as individual layers 204) is converted to a secure software container 208 that also includes different layers 210. The conversion is performed using a conversion tool 206 and is indicated by a bow-shaped arrow 206a. The software container 202 is unencrypted, while the secure software container 208 has encrypted layers 210. These can be stored in a container repository 212. Also here, a secure software container 208 with layers 210 is shown, with an example of the layers 210 in symbolic form.

[0068] Figure 3A block diagram of an embodiment of a complete stack 300 of the elements involved in executing a secure software container 208 is shown. Based on a secure execution platform 302 of a virtual machine (or alternatively, a secure container execution environment running a container in a virtual machine), a container engine 304 manages the basic requirements for operating a software container. For reasons of completeness, a secure software container 208 (not explicitly shown) is shown, which has its layer 210, specifically a top read / write layer and in encrypted form (e). The container engine 304 calls a container runtime environment 306 including a hypervisor 308. The hypervisor 308 then starts a kernel 310 (particularly an operating system kernel) in the layer of the software container 208. Arrow 312 can indicate the movement of a secure software container 208 with layer 210 from the container engine to a virtual machine 314, where the secure software container 208 is decrypted into an executable, decrypted (d) container layer stack 204 (d) (not explicitly shown) of the decrypted form of layer 204.

[0069] It may be noted that virtual machine 314 is a trusted environment if techniques for secure execution of virtual machines may be applied, like using a hardware security module, or any other technique for running virtual machines such that a privileged hypervisor administrator (e.g., a root user) may not be able to access the data of the virtual machine.

[0070] Figure 4 Shows thin provisioning and linking of blocks in a secure software container. Top left ( Figure 4 Layers 402, 404, 406, 408 on (a)) may be a sequence of layers of a software container image. The lowest layer 402 includes file 410A, while the next upper layer 404 includes file 412B. If file 410A is updated (changed), it is written to a new layer 406 as file 414A'. At this point in time, layer 406 may be the top layer that allows read and especially write access to layer 406. The complete raw content of the software container may be identified in 408, which essentially represents a vertical view through the different layers, starting from the top layer 406, via layer 414 to layer 402.

[0071] On the upper right side ( Figure 4 (b)), showing the mapping into sparse block devices 416, 418, 420, 422. The black boxes shown in the different layers may represent blocks carrying data of layers 402, 404, 406 in the sparse block devices, and may be encrypted with the client key. Thus, Figure 4The stack of (b) can represent the data of a secure software container. All encrypted block device files are written as files to the corresponding new container layer. These layers can contain three files. Their automatically generated names are based on the hash of the corresponding contents of the files: (i) content file (block-by-block encrypted sparse block loopback device file), (ii) parent file, which only includes the hash of the previous layer (i.e., ape pointing to the file name of the previous layer), (iii) metadata file (this can be optional), including container image metadata added to the relevant layer, like environment variables, port settings, etc. This last file can also be optionally encrypted.

[0072] If all layers are mounted on top of each other, all files will be visible. The sum parent firewall describes a dependency graph of layers that allows block device files to be mounted on top of each other in the correct order. This is done in Figure 4 (c) shows the arrows pointing to the hash address of the corresponding parent layer.

[0073] Figure 5 An embodiment of a first portion of a flowchart 500 for forming a secure software container is shown. First, a sparse loopback device file is created, 502. Then, a file system is created in the loopback device file, 504. Starting from the bottom of the layers of the software container, the next layer "L" of the image of the first (original) layered software component is identified before creating the sparse loopback device file "D" (508). The device mapper is used to add the loopback device file "D" on top of the previous stack of loopback device files, 510. Therefore, write operations will proceed to "D" and all read operations request it through the layer stack until a block is found at the requested offset (compare 512).

[0074] Then, a mount operation at the mount point is performed looping back the stack of device files, 514. Next, all the contents of "L" are added to the mount point (which will write these changes to "D"), 516. Last but not least, the mount point is unmounted, 518. Steps 506 to 518 are performed for all image layers.

[0075] Figure 6 A method for forming a secure software container is shown. Figure 5 500 . The flowchart continues by identifying 602 a sparse loopback device for "D", and starting at the bottom layer. Then, "D" is encrypted and an encrypted version "E" of "D" is created, 604. This is done for all image layers, as shown by the loopback arrows on the left side of the flowchart.

[0076] Then, the sparse loopback device file "D2" is identified, where the process also starts from the bottom layer (606). Next, a hash value "H" of "E" is created, 608. In the next step, again starting from the bottom layer, identification of layer "L" from the original image is performed, 610. At 612, a new container image layer "M" is created on top of any existing new container image layers. Then, a file in "M" is created by placing the contents of "E" into a new file called "H" content (614). And, a file in "M" is created by placing any metadata information of "L" into the new file "H" metadata, 616.

[0077] Next, at 618, it is determined whether "L" is the bottom layer. If this is not the case ("N"), a file in "M" is created by placing the previous hash value (i.e., the previous "H" of the previous "E") into a new file referred to as the parent of "H" (620). If determination 618 is true (case "Y"), the process loops back to step 606 where the sparse loopback device file "D" is identified and this loop is repeated for all image layers.

[0078] Figure 7 An embodiment of a first portion of a flowchart 700 for executing a secure software container is shown. First, at 702, the host's container engine mounts all layers "E" on top of each other to assemble a container file system. In the next step, the host's container engine mounts (704) null read / write to the container file system. The container file system then creates (706) a "secure execution" virtual machine before providing (708) the file system to the virtual machine. The container engine reads (710) the user-provided kernel and commands (such as initrd), init, and client keys to decrypt the encrypted software container (i.e., its contents).

[0079] The VM boots (712) the user-provided kernel / initrd ("initrd" stands for Initial RAM Disk, which is a temporary file system used by the Linux kernel during the boot process), and starts (714) the user-provided Init process, i.e., the initiating process / command. The flowchart then continues to Figure 8 .

[0080] Figure 8 A flowchart 700 for executing a secure software container is shown (cf. Figure 7) is an embodiment of a second portion 800 of the present invention. The init process recreates (802) the order of layers based on the "H" parent file, and the init process decrypts (804) all "H" content files on the fly (e.g., using "dm-crypt", a cryptographic module of the Linux kernel's device mapper) using a user-provided client key. In addition, the init process assembles (806) the decrypted sparse loopback device in the correct order, and assembles (808) the read-write sparse loopback device file on top of all other layers that are read-only.

[0081] In addition, the init process again uses the decryption key provided by the client to encrypt (810) the read-write loopback file into a new "H" content file. Last but not least, the init process encrypts a new "H" parent file pointing to the topmost read-only layer (812).

[0082] For reasons of completeness, Fig. 9 A block diagram of an embodiment of a secure container system 900 is shown. The system 900 includes a receiving unit 902 adapted to receive a first layered software container image, a converting unit 904 for converting all files except corresponding metadata in each layer of the first layered software container image into a volume including a set of blocks, wherein each layer includes an incremental difference with a next lower layer.

[0083] In addition, the system 900 includes an encryption module 906 for encrypting each block of the block set of the partial layer, and a storage unit 908 adapted to store each encrypted block set as a layer of the encrypted container image together with unencrypted metadata, the unencrypted metadata being used to reconstruct an order of the block set equal to the order of the first layered software container image, thereby creating a secure encrypted software container.

[0084] Embodiments of the invention may be implemented with nearly any type of computer, regardless of whether the platform is suitable for storing and / or executing program code. Fig.10 As an example, a computing system 1000 suitable for executing program code associated with the proposed method is shown.

[0085] The computing system 1000 is only one example of a suitable computer system and is not intended to impose any limitation on the scope of use or functionality of the embodiments of the invention described herein, regardless of whether the computer system 1000 can be implemented and / or perform any of the functions set forth above. In the computer system 1000, there are components that can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with the computer system / server 1000 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 consumer electronics, network PCs, small computer systems, large computer systems, and distributed cloud computing environments including any of the above systems or devices, etc. The computer system / server 1000 may be described in the general context of computer system executable instructions (e.g., program modules) executed by the computer system 1000. In general, a program module may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 1000 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are 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).

[0086] As shown, computer system / server 1000 is shown in the form of a general computing device. The components of computer system / server 1000 may include, but are not limited to, one or more processors or processing units 1002, system memory 1004, and a bus 1006 that couples different system components including system memory 1004 to processor 1002. Bus 1006 represents one or more of any bus structure in several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of various bus architectures. As an example and not limitation, such architectures include industrial standard architecture (ISA) bus, microchannel architecture (MCA) bus, enhanced ISA (EISA) bus, video electronics standard association (VESA) local bus, and peripheral component interconnect (PCI) bus. Computer system / server 1000 generally includes various computer system readable media. Such a medium can be any available medium that can be accessed by computer system / server 1000, and it includes both volatile and non-volatile media, removable and non-removable media.

[0087] The system memory 1004 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1008 and / or cache memory 1010. The computer system / server 1000 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 1012 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, and commonly referred to as a "hard drive"). Although not shown, a disk drive for reading from and writing to a removable non-volatile disk (e.g., a "floppy disk") may be provided, as well as an optical 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 an instance, each may be connected to the bus 1006 via one or more data media interfaces. As will be further depicted and described below, the memory 1004 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.

[0088] A program / utility having a set (at least one) of program modules 1016, as well as an operating system, one or more application programs, other program modules, and program data may be stored in memory 1004, by way of example and not limitation. Each or some combination of the operating system, one or more application programs, other program modules, and program data may include an implementation of a networking environment. As described herein, program modules 1016 generally perform the functions and / or methods of embodiments of the present invention.

[0089] The computer system / server 1000 may also communicate with one or more external devices 1018, such as a keyboard, a pointing device, a display 1020, etc.; one or more devices that enable a user to interact with the computer system / server 1000; and / or any device that enables the computer system / server 1000 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via an input / output (I / O) interface 1014. In addition, the computer system / server 1000 may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter 1022. As depicted, the network adapter 1022 may communicate with other components of the computer system / server 1000 via a bus 1006. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 1000. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0090] In addition, a secure container system 900 for creating secure software containers can be attached to the bus system 1006.

[0091] The description of different embodiments of the present invention has been presented for the purpose of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements to existing technologies on the market, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

[0092] The present invention may be embodied as a system, method and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to execute aspects of the present invention.

[0093] The medium can be an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system for propagating the medium. Examples of computer readable media may include semiconductor or solid-state memory, magnetic tape, removable computer disk, random access memory (RAM), read-only memory (ROM), rigid disk and optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read / write (CD-R / W), DVD and Blu-ray disc.

[0094] Computer readable storage medium can be a tangible device that can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, 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 stick, floppy disk, mechanical encoding device (such as punch card) or convex structure in groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as transient signal itself, such as radio wave or other free propagating electromagnetic wave, electromagnetic wave propagated by waveguide or other transmission medium (for example, light pulse by fiber optic cable), or electrical signal transmitted by wire.

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

[0096] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, and programming languages ​​include object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" programming language or similar programming languages. The computer-readable program instructions can be executed completely on the user's computer, partially as an independent software package on the user's computer, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can 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 can be connected to an external computer (for example, by using the Internet of an Internet service provider). In certain embodiments, electronic circuits (including, for example, programmable logic circuits, field programmable gate arrays (FPGAs) or programmable logic arrays (PLAs)) can be personalized by utilizing the state information of computer-readable program instructions to execute computer-readable program instructions, so as to perform aspects of the present invention.

[0097] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0098] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions are executed by the processor of the computer or other programmable data processing device to create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other equipment to function in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0099] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or another device, so that a series of operating steps are performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or another device implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0100] The flow chart and / or block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to different embodiments of the present invention.To this end, each box in the flow chart or block diagram can represent a part of a module, segment, or instruction, which includes one or more executable instructions for realizing the logical function of the specification.In some alternative implementations, the function marked in the box may not occur in the order marked in the figure.For example, depending on the function involved, the two boxes shown in succession can actually be performed substantially at the same time, or these boxes can sometimes be performed in reverse order.It will also be noted that each box in the block diagram and / or flow chart and the combination of the boxes in the block diagram and / or flow chart can be realized by a system based on special-purpose hardware, and the system based on special-purpose hardware performs a specified function or action or performs a combination of special-purpose hardware and computer instructions.

[0101] The terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the present invention. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that when the terms "comprises" and / or "comprising" are used in this specification, they specify the presence of stated features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or combinations thereof.

[0102] All devices or steps in the attached claims plus the corresponding structures, materials, actions and equivalents of the functional elements are intended to include any structure, material, or action for performing functions in conjunction with other claimed elements (such as specifically claimed). The description of the present invention is presented for the purpose of illustration and description, but is not intended to be exhaustive or limited to the present invention in the disclosed form. Without departing from the scope and spirit of the present invention, many modifications and variations will be apparent to those of ordinary skill in the art. These embodiments are selected and described in order to best explain the principles and practical applications of the present invention, and to enable those of ordinary skill in the art to understand the present invention for different embodiments with different modifications suitable for the specific purposes under consideration.

[0103] As an overview of the above, the general concepts of the present invention can be described in a series of clauses:

[0104] 1. According to clause 1, there is provided a computer-implemented method for creating a secure software container, the method comprising: providing a first layered software container image, converting all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume comprising a set of blocks, wherein each layer comprises an incremental difference to a next lower layer,

[0105] encrypting each block in the set of blocks of the layer of the portion,

[0106] Each encrypted set of said blocks is stored as a layer of an encrypted container image along with unencrypted metadata, said unencrypted metadata being used to reconstruct an order of said set of blocks equal to an order of said first layered software container image, thereby creating a secure encrypted software container.

[0107] 2. The method of clause 1, wherein storing each encrypted set of blocks further comprises:

[0108] Metadata of the first layered software container image is stored.

[0109] 3. The method of clause 1 or 2, wherein each of the layers stored in the encrypted container image uses thin provisioning and further includes thin provisioning metadata.

[0110] 4. The method according to any one of the above, wherein the name of each file of the layer of the encrypted container image is a hash value of the content of the file.

[0111] 5. The method according to any one of the above items further includes

[0112] A virtual machine operating system, a startup program, and a decryption key are provided, wherein the decryption key corresponds to an encryption key used for encrypting each block in the block set.

[0113] 6. The method according to clause 5, further comprising:

[0114] A secure container execution environment is provided for starting the virtual machine having the virtual machine operating system.

[0115] 7. The method of clause 6, wherein the starting of the virtual machine comprises:

[0116] The set of blocks of the encrypted container image are decrypted using the decryption key.

[0117] 8. The method according to clause 7, further comprising:

[0118] The first layered software container image is rebuilt in the order of layers of the first layered software container image.

[0119] 9. The method of clause 8, wherein layers on the decrypted secure container image allow read / write access, wherein the layers below the top layer allow read-only access.

[0120] 10. A method according to clauses 5 to 9, wherein the secure container execution environment is protected by secure firmware, which prevents privileged users and / or other processes from accessing the virtual machine, and wherein the virtual machine operating system, the startup program and the decryption key are each encrypted.

[0121] 11. The method of clause 10, wherein the security firmware cooperates with a hardware security module.

[0122] 12. A secure container system for creating a secure software container is also provided, the system comprising:

[0123] a receiving unit adapted to receive a first layered software container image, a converting unit adapted to convert all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume comprising a set of blocks, wherein each layer comprises an incremental difference to a next lower layer,

[0124] an encryption module adapted to encrypt each block of said set of blocks of said layer of part,

[0125] a storage unit adapted to store each encrypted set of said blocks as a layer of an encrypted container image together with unencrypted metadata for reconstructing an order of said set of blocks equal to an order of said first layered software container image,

[0126] This creates a secure encrypted software container.

[0127] 13. The system according to clause 12, wherein the storage unit is further adapted to:

[0128] Metadata of the first layered software container image is stored.

[0129] 14. The system of clause 12 or 13, wherein each of the layers stored in the encrypted container image uses thin provisioning and further includes thin provisioning metadata.

[0130] 15. The system of any one of clauses 12 to 14, wherein the name of each file of the layer of the encrypted container image is a hash value of the contents of the file.

[0131] 16. The system according to any one of clauses 12 to 15, further comprising a providing module adapted to provide a virtual machine operating system, a startup program, and a decryption key corresponding to an encryption key used for encrypting each block in the block set.

[0132] 17. The system according to clause 16, wherein the providing module is further adapted to:

[0133] A secure container execution environment is provided for starting the virtual machine having the virtual machine operating system.

[0134] 18. The system of clause 17, wherein the starting of the virtual machine comprises:

[0135] The set of blocks of the encrypted container image are decrypted using the decryption key.

[0136] 19. The system according to clause 18, further comprising:

[0137] A reconstruction unit is adapted to rebuild the first layered software container image in the order of the layers of the first layered software container image.

[0138] 20. The system of clause 19, wherein layers above the decrypted secure container image allow read / write access, wherein the layers below the top layer allow read-only access.

[0139] 21. The system of clause 16, wherein the secure container execution environment is protected by secure firmware that prevents privileged users and / or other processes from accessing the virtual machine, and wherein the virtual machine operating system, the launcher, and the decryption key are each encrypted.

[0140] 22. The system according to clause 21, further comprising

[0141] A hardware security module is adapted to cooperate with the security firmware.

[0142] 23. A computer program product for creating a secure software container, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to:

[0143] providing a first layered software container image, converting all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume comprising a collection of blocks, wherein each layer comprises an incremental difference to a next lower layer,

[0144] encrypting each block in the set of blocks of the layer of the portion,

[0145] Each encrypted set of said blocks is stored as a layer of an encrypted container image along with unencrypted metadata, said unencrypted metadata being used to reconstruct an order of said set of blocks equal to an order of said first layered software container image, thereby creating a secure encrypted software container.

Claims

1. A computer-implemented method for creating a secure software container, the method comprising: Provides first-layer software container images, converting all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume comprising a set of chunks, each layer comprising a content file, a parent file, and a metadata file, and each layer comprising a delta difference to a next lower layer, encrypting each block in the set of blocks of the layer of the portion, storing each encrypted set of said blocks as a layer of an encrypted container image along with unencrypted metadata for reconstructing an order of said set of blocks equal to an order of said first layered software container image, This creates a secure encrypted software container.

2. The method according to claim 1, characterized in that The storing of each encrypted set of blocks further comprises: Metadata of the first layered software container image is stored.

3. The method of any one of claims 1-2, wherein each of the layers stored in the encrypted container image uses thin provisioning and further includes thin provisioning metadata.

4. The method according to any one of claims 1-2, wherein the name of each file of the layer of the encrypted container image is a hash value of the content of the file.

5. The method according to any one of claims 1 to 2, further comprising A virtual machine operating system, a startup program, and a decryption key are provided, wherein the decryption key corresponds to an encryption key used for encrypting each block in the block set.

6. The method according to claim 5, further comprising: A secure container execution environment is provided for starting the virtual machine having the virtual machine operating system.

7. The method according to claim 6, wherein the starting of the virtual machine comprises: The set of blocks of the encrypted container image are decrypted using the decryption key.

8. The method according to claim 7, further comprising: The first layered software container image is rebuilt in the order of layers of the first layered software container image.

9. The method of claim 8, wherein the top layer of the decrypted secure container image allows read / write access, wherein the layers below the top layer allow read-only access.

10. The method of claim 5, wherein the secure container execution environment is protected by secure firmware that prevents privileged users and / or other processes from accessing the virtual machine, and wherein the virtual machine operating system, the startup program, and the decryption key are each encrypted. The method of claim 10 , wherein the security firmware cooperates with a hardware security module.

12. A secure container system for creating a secure software container, the system comprising: a receiving unit adapted to receive a first layered software container image, a conversion unit adapted to convert all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume comprising a set of chunks, each layer comprising a content file, a parent file and a metadata file, and each layer comprising an incremental difference to a next lower layer, an encryption module adapted to encrypt each block of said set of blocks of said layer of part, a storage unit adapted to store each encrypted set of said blocks as a layer of an encrypted container image together with unencrypted metadata for reconstructing an order of said set of blocks equal to an order of said first layered software container image, This creates a secure encrypted software container.

13. The system according to claim 12, wherein: The storage unit is also suitable for: Metadata of the first layered software container image is stored.

14. A system according to any one of claims 12 to 13, wherein: Each of the layers stored in the encrypted container image uses thin provisioning and also includes thin provisioning metadata.

15. The system of any one of claims 12 to 13, wherein the name of each file of the layer of the encrypted container image is a hash value of the content of the file.

16. The system according to any one of the preceding claims 12 to 13, further comprising a providing module adapted to A virtual machine operating system, a startup program, and a decryption key are provided, wherein the decryption key corresponds to an encryption key used for encrypting each block in the block set.

17. The system according to claim 16, characterized in that The providing module is also adapted to: A secure container execution environment is provided for starting the virtual machine having the virtual machine operating system.

18. The system of claim 17, wherein the starting of the virtual machine comprises: The set of blocks of the encrypted container image are decrypted using the decryption key.

19. The system of claim 18, further comprising: A reconstruction unit is adapted to rebuild the first layered software container image in the order of the layers of the first layered software container image.

20. The system of claim 19, wherein the top layer of the decrypted secure container image allows read / write access, wherein the layers below the top layer allow read-only access.

21. The system of claim 16, wherein the secure container execution environment is protected by secure firmware that prevents privileged users and / or other processes from accessing the virtual machine, and wherein the virtual machine operating system, the startup program, and the decryption key are each encrypted.

22. The system according to claim 21, further comprising A hardware security module is adapted to cooperate with the security firmware.

23. A computer program product for creating a secure software container, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to: Provides first-layer software container images, converting all files of each layer of the first layered software container image except corresponding metadata into a volume, the volume comprising a collection of chunks, each layer comprising a content file, a parent file, and a metadata file, and each layer comprising a delta difference to a next lower layer, encrypting each block in the set of blocks of the layer of the portion, storing each encrypted set of said blocks as a layer of an encrypted container image along with unencrypted metadata for reconstructing an order of said set of blocks equal to an order of said first layered software container image, This creates a secure encrypted software container.

24. The computer program product of claim 23, wherein each of the layers stored in the encrypted container image uses thin provisioning and further comprises thin provisioning metadata.

25. The computer program product of any one of claims 23 to 24, wherein the name of each file of the layer of the encrypted container image is a hash value of the contents of the file.

Images