Optimizing container image encryption

Abstract

An example method includes packaging a containerized application as at least two images. A first image can include a main application and a second image includes a decryptor. Sensitive information associated with the application is encrypted and included in the second image. The decryptor operates separately from the main application. The main application is run after the decryptor successfully completes. The main application can include a copy program layer to copy any data decrypted by the decryptor into the main application.

Description

Technical Field

[0001] Embodiments of this invention generally relate to containerized applications, container security, and container orchestration security. More specifically, at least some embodiments of this invention relate to systems, hardware, software, computer-readable media, and methods for focused encryption and / or decryption of container images. Background Technology

[0002] Container images, such as Docker images, can be described in various ways. For example, an image can be described as a file or a set of files comprising multiple layers. An image can also be described as an ordered collection of changes (e.g., layers) to a root filesystem. Images can run on engines such as the Docker engine. Kubernetes (an example of a container orchestration platform) can be used to manage the deployment and scaling of containerized applications. Images can be deployed on any host and / or orchestration platform with an appropriate engine.

[0003] Docker images can be organized into logical layers defined in a file, which in the case of Docker container services may be called a Dockerfile. A Dockerfile is typically a text document containing commands to be executed to build the Docker image. The commands build the image when executed. The layers of an image may be readable by anyone with access to the image, and this could pose a threat to any sensitive data within any of the layers within the image.

[0004] While encrypting images can protect sensitive data from being read while the container is at rest, this approach can be problematic and inefficient. For example, the entire image could be encrypted and delivered as a 'blob' to the deployment site. However, this introduces management and performance issues. For instance, container startup time can be impacted when an instance is instantiated, as a fully encrypted image can be quite large. Another problem with encrypting images is that the deployment environment may need to be modified to support image decryption. Finally, depending on the image size, decryption can take a relatively long time and may also impact the performance of other components in environments with heavy deployments. Attached Figure Description

[0005] In order to describe the ways in which at least some of the advantages and features of the invention can be obtained, a more specific description of embodiments of the invention will be presented by reference to specific embodiments of the invention illustrated in the accompanying drawings. It should be understood that these drawings illustrate only typical embodiments of the invention and should therefore not be considered as limiting its scope. Embodiments of the invention will be described and explained more specifically and in detail using these drawings, in which:

[0006] Figure 1 Various aspects of the sample image have been made public;

[0007] Figure 2 Various aspects of the sample image and sample encrypted image, including sensitive information, have been disclosed.

[0008] Figure 3 Example methods for encrypting an image or a portion thereof have been disclosed.

[0009] Figure 4 Examples of related images were disclosed, one of which includes the main application, and another image includes a decryptor for sensitive layers;

[0010] Figure 5 Example methods for encrypting and / or running the image are disclosed;

[0011] Figure 6 An example of a packaged application is shown; and

[0012] Figure 7 Various aspects of the example computing system or environment have been disclosed. Detailed Implementation

[0013] Embodiments of this invention generally relate to containerized applications and container security. More specifically, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for centrally encrypting one or more container images or portions thereof. Embodiments of the invention also relate to encrypting and / or decrypting container images or layers thereof while eliminating operating system (OS) runtime dependencies on the decryption. More specifically, embodiments of the invention eliminate the decryptor's dependency on the container's operating system.

[0014] In general, embodiments of the present invention improve the security of containers / images or the data contained therein by constructing related but separate images (or by splitting an image into related images). The first image may include non-sensitive layers that may not require encryption. The first image may also contain the main application. The second image may include a decryptor layer and an encryption layer, which may include encrypted data or multiple encryption layers. During deployment or execution, the second image may be instantiated as a container and run first to decrypt sensitive data. Running the first image after the container including the decryptor is complete allows the now-decrypted layers to be incorporated into the runtime container of the main application. In one example, the decryptor and the encrypted sensitive layers are separated from the base image and the decryptor is run separately.

[0015] If the decryptor is inside the container image, it is part of the container runtime. If the decryptor is above the OS layer, it runs within the OS context of that runtime instance. Furthermore, when the decryptor is inside the container image, layers loaded or executed before the decryptor may contain malicious code that could be used to compromise the security of the system or container.

[0016] The embodiments of the present invention eliminate this OS dependency by moving the decryptor to a separate image and a separate runtime instance. When the decryptor is separated from the main image, it becomes a layer within its own image, eliminating OS dependency on the OS of other images. This eliminates the need to create different decryptors for different OS versions when the decryptor is simply included in the main image.

[0017] Furthermore, by placing the decryptor in a separate image, vulnerabilities and security issues within the main application container render the decryption key inaccessible. In other words, when the decryptor is included in the main application image, the application runs in the same memory as the decryptor. This can compromise application instances in various ways.

[0018] Embodiments of this invention can be integrated into and utilized by orchestration platforms such as Kubernetes. By separating the decryptor from the application container, OS dependency is eliminated from the decryptor's perspective. Additionally, layers of the image can be selectively encrypted. Furthermore, the decryption key is not provided through the main application container. Embodiments of this invention also ensure that nothing in the main application runs before the decryptor, ensuring that malicious code does not run before the decryptor.

[0019] Generally, exemplary embodiments of the present invention include an image encryption process that may encrypt only sensitive data (or layers) within the image. Sensitive layers may be combined into a single layer, which is then encrypted and stored encrypted at rest (e.g., in an image repository). Embodiments of the present invention may also propose adding a decryptor to an image separate from the main application image. The decryptor image runs before the main application image is run or instantiated, allowing the decryption process to occur at runtime and before the original application runs.

[0020] Compared to encrypting and decrypting the entire image, the encryption and decryption process can be significantly shorter. No changes to the deployment process or environment may be required, with possible exceptions being minor configuration changes and secret sharing. Similarly, example implementations can provide processes and mechanisms that can be used to easily select and encrypt the layers of an image file to be protected. In this way, trade-offs between image protection and runtime can be defined and tested relatively easily.

[0021] In particular, an advantage of at least some embodiments of the present invention is that when encrypting a portion of an image, the trade-off between image protection and runtime can be defined and tested relatively easily. Embodiments of the present invention can keep at-rest image data secure and therefore allow images to be securely deployed to public domains or backup sites. Embodiments of the present invention can propose selective encryption of images in a manner that has little or no impact on the associated deployment environment of the image. Embodiments of the present invention can implement selective encryption of images in a manner that the impact on the startup time of fully operational containers is not substantial. Selective encryption can be internal image encryption or can be achieved by encrypting sensitive data within a separate image.

[0022] The discussion herein may include references to images and containers in the context of Docker and Kubernetes. However, embodiments of the invention are not limited to these platforms and can be implemented in a variety of container or image platforms and container orchestration platforms. More generally, embodiments of the invention can be employed in conjunction with any container definition and deployment environment, orchestration platform, and associated images, files, and components. The following discussion is not intended to limit the scope of the invention in any way. For example, embodiments of the invention can be adapted to packaging and runtime methods of orchestration platforms such as Kubernetes.

[0023] In one example, embodiments of the present invention are configured to increase or enhance the security of container-related processes, including container or image formation, container deployment, layer encryption / decryption, container orchestration, etc. Users can control which layers or portions of the image are encrypted. Embodiments of the present invention can divide the decryptor (which may be a layer of the container image) into separate images and run the decryptor image independently of the main container itself. In addition to providing a modular and efficient solution, this also improves security.

[0024] Figures 1 to 3 Optimizations for encrypting / decrypting images are described. Specifically, Figures 1 to 3 The process of encrypting certain layers of an image and decrypting these layers at runtime is discussed. Figures 1 to 3This relates to an implementation for optimizing image encryption, wherein the decryptor is included in the same image as the application. Figures 4 to 5 A further example of optimized image encryption is shown, where the decryptor is separate from the main container image.

[0025] Generally speaking, and refer to Figure 1 For example, image 100, like a Docker image, can refer to files, or a combination of files / data divided into layers such as layers 102, 104, and 106. A command file, such as a Dockerfile, can contain commands that define image 100 and, when executed, build or assemble the layers within image 100.

[0026] Typically, a command file describes the base image and the additional layers that will make up the image. More specifically, a command file can be a text file containing commands used to assemble the image. Each command can produce one layer of the image. Commands that do not modify the image filesystem can be considered empty layers, and the metadata of the commands can be stored in the build history within the image configuration file. For example, each image can have an image configuration file describing various parameters of the image itself, such as the layers that make up the image and the identifier of the entry point. The identifier of the entry point refers to the command that runs after the container is instantiated.

[0027] The example implementation can be combined with an image registry, such as a Docker repository. Generally, an image registry can include layers that collectively form an image or a repository that stores images. Such a registry can store image configurations and layers in a compressed format as blobs containing plain text data. The registry can provide an application programming interface (API) for pushing and pulling images.

[0028] A repository stores a list of all images. This list can contain data about which image configurations are used, and the layers / commands used to build the image. For example, a Docker hub is a public-domain Docker repository that stores Docker images for public use. Many use cases and products can rely on this repository to store their production images, which can then be deployed on AWS, Azure, or any other platform.

[0029] Generally speaking, deployment refers to the process of instantiating an image to obtain a runtime environment on an image engine and running a containerized application. Deployment can be implemented on any host with a suitable engine or on any other platform that supports and / or orchestrates images. The deployment environment can copy images from a repository and store copies of images locally.

[0030] While mirroring offers useful functionality, it is vulnerable to threats. For example, any data stored in a database (DB), Artifactory, or local files, especially in a potentially compromised public domain, is at risk of theft. Additionally, risks exist in private environments as well. Data can be stolen when it is in a production environment or in some backup environments. The following is a more detailed discussion of some of the drawbacks of mirroring.

[0031] One characteristic that makes image mirrors potentially vulnerable (such as to unauthorized access) is that they may contain plain text files stored on a disk. Therefore, attackers who can gain access to the disk, corrupt the file system, or intercept the movement of the image from one location to another can obtain the data stored within the image.

[0032] Similarly, processes such as encryption and decryption of the image can often be relatively slow. This may be attributed to the use of algorithms that rely on complex mathematical functions. Data modifications such as I / O operations and mechanisms to prevent brute-force attacks can also be relatively slow in the encryption / decryption process. Therefore, the decryption of the entire image can be slow and slow down the deployment of the system.

[0033] Additionally, containerized deployment environments can be performance-sensitive. For example, deployments using a microservices architecture are constantly scaling or instantiating new containerized services. Anything that slows down processes such as image encryption and decryption can adversely affect system recovery and / or system functionality. This, in turn, can lead to a poor user experience and / or a slow system.

[0034] Furthermore, conventional methods for securing images require modifications to the deployment environment in which the image is deployed. For example, encrypting the entire image or each layer individually requires support from the deployment environment. This support is not present in most existing deployment environments, and even if it is, it can complicate and slow down the deployment and operation process. If the deployment environment lacks decryption capabilities, the process can become even more complex, as the image may have to be sent to a third party for decryption, potentially causing delays in container deployment.

[0035] Finally, conventional methods for image decryption may require support from the deployment environment, especially orchestration support before the image is sent to the target host for execution. Therefore, if the host running the application receives an image in unencrypted form, sensitive data within the image may be vulnerable to host access attacks.

[0036] The following observations may relate to one or more example implementations. First, decrypting the entire image at the orchestrator or host involves storing the unencrypted and therefore vulnerable image. Similarly, decrypting the entire image may require modifications to the runtime environment. Additionally, a base image that may include an OS (operating system) or comprise it may not contain sensitive data, and therefore, encrypting the base image as a whole or as a layer may be of little value. The image may also include other layers where encryption may not be necessary or useful, and such layers may include, but are not limited to: Apache Tomcat, Java, routers / agents, databases, and / or other application-level services. Finally, the OS and underlying application services may collectively constitute a relatively large percentage of the overall size of the container image. Therefore, avoiding encryption of the OS and related services allows containers to run without requiring modifications to the deployment environment and can significantly reduce the size of the encrypted portion of the image.

[0037] Therefore, embodiments of the present invention can provide users with control over which image layers are encrypted, and can enable users to build mechanisms that only decrypt these layers without requiring deployment environment support. Thus, example embodiments include new secure images, such as Docker images, that encrypt only sensitive data. Therefore, relatively large base images or layers containing insensitive data can be preserved in plain text or raw format, but data considered sensitive can remain encrypted. The decryption process can be implemented at runtime by a decryptor added as a layer to the image and can decrypt the encrypted image data before executing the original application, of which the container is part.

[0038] Generally, some example implementations may involve marking data or layers to be encrypted. In the context of an image, this marking may involve modifying, for example, the image's command file (e.g., a Dockerfile) to mark one or more specific layers of the image to be encrypted. For example, within the command file, just above the layer(s) to be marked for encryption, a command can be inserted to indicate where encryption should begin. An example of such a command is:

[0039] RUN echo "==========START ENCRYPTION========="

[0040] Commands such as this one may result in the creation of an empty layer, which will save the command in the layer history within the image configuration file. A stop encryption signal may also be included in the command file.

[0041] It should be noted that this invention is not limited to the specific example string mentioned above. Any sequence indicating where encryption should begin can be used. It should also be noted that while 'RUN echo' results in the creation of an empty layer, various other commands can be used. Alternatively, commands that create layers that are not empty can be used. Thus, in general, any layer can be implemented as one of a group of one or more signal layers. However, the use of trivial empty layers, such as those created by the 'RUN echo' command, can be simple and can function without additional limitations.

[0042] During the image encryption process, the system can traverse the layers of the image or the commands in the command file until the command layer or the signal layer of the command, as mentioned above, is located. The system can then know to encrypt at least one of the layers following the signal layer. This method thus allows any one or more image layers to be marked for encryption and can help optimize the trade-off between data protection and runtime constraints.

[0043] Follow us now Figure 2 It provides details about the image configuration before and after encryption. For example... Figure 2 As shown, image 200 may include a combination of layers. Some layers, such as OS layer 202, as well as layers 204 and 206, may contain insensitive data and therefore may not require encryption. Therefore, these layers can be referred to as insensitive layers. A specific number or type of insensitive layers 202, 204, and 206 is not required. Image 200 may be referred to as a sensitive image when one or more of its included layers contain sensitive information.

[0044] It should be noted that in some implementations, a non-sensitive layer may include some sensitive information, but designating such a layer as non-sensitive reflects the judgment that the additional processing costs and / or other considerations required to protect the non-sensitive layer outweigh the potential risks of exposing the sensitive information. Similarly, the sensitive layers discussed below may include some non-sensitive information, but designating such a layer as sensitive reflects the judgment that encryption of the non-sensitive information is generally desirable because it may not impose any substantial processing burden on the system, and in any case, the need to protect the sensitive information in the sensitive layer may outweigh such a burden.

[0045] Mirror 200 may additionally include one or more layers containing sensitive information that may require encryption, such as sensitive layers 208, 210, and 212. A specific number or type of sensitive layers 208, 210, and 212 is not required. Whether specific data or information is sensitive can be defined by the user, administrator, or any other entity. Such an entity can be a human or a computing system. Generally, sensitive information includes any information that is expected to be kept confidential, or at least subject to limited dissemination and / or availability, for whatever reason(s). In some cases, sensitive information may include user-specific and / or system-specific information that cannot be publicly obtained. Sensitive information may include proprietary financial and technical information of a commercial enterprise.

[0046] Similarly, Figure 2 As indicated, mirror 200 may include one or more signal layers 214. Generally, signal layer 214 may indicate to the system that any one or more layers following signal layer 214 should be encrypted. Generally, signal layer 214 may serve as a notification indicating the start of one or more layers that will be considered sensitive. Thus, in some embodiments, one, some, or all layers before the signal layer may be insensitive, and one, some, or all layers after the signal layer may be sensitive. In some embodiments, the layers of the mirror may be considered to define at least two points in time: a point in time before the signal layer and a point in time after the signal layer. As mentioned elsewhere herein, some other embodiments propose mirrors having multiple signal layers and multiple groups of one or more insensitive layers and / or multiple groups of one or more sensitive layers. In some embodiments, signal layer 214 may have an identifier that marks the layer as a signal layer, such that signal layer 214 can be understood by the system as it traverses the layers of mirror 200. Although the example shown includes only one signal layer 214, it should be understood that there is no limitation on the number of signal layers 214 that can be employed in a mirror. For example, in an alternative image configuration, an unencrypted image may have the following top-down configuration: layer; layer; layer; signal layer; sensitive layer; sensitive layer; stop encryption layer; layer; layer; signal layer; sensitive layer; stop encryption layer. More generally, a sensitive unencrypted image may have any number of layers, signal layers, and stop encryption layers, as well as combinations thereof. Therefore, the example image configurations disclosed herein are provided by way of illustration only and are not intended to limit the scope of the invention in any way.

[0047] Continue to refer to Figure 2 And now they are turning their attention to Figure 3 This discloses an example method for selectively encrypting container images, with the total value represented by 300. For example... Figure 2 As shown and described below, the execution of method 300 can produce an encrypted Docker image 400.

[0048] Example method 300 may begin by inspecting an image in a repository (302), which may have an image name. The image can be located in the repository by searching for its name. Due to inspection (302), one or more signal layers (304) and / or one or more layers to be encrypted can be identified (304). Then, one or more layers to be encrypted (306) can be downloaded or accessed. The layers can be encrypted before downloading.

[0049] The downloaded layers (if more than one) can then be combined to create a single-layer file, such as a .TAR file 308. As used herein, a .TAR file refers to an archive that can be created by the Unix-based TAR utility. A .TAR file is an archive created by TAR, a Unix-based utility that operates to package files together. A .TAR file can contain multiple files that can be stored in an uncompressed format, and a .TAR file can also include metadata about the archive. A .TAR file can be compressed into a .GZ file using GNU Zip compression. However, the scope of the invention is not limited to .TAR files, and any other suitable file and platform used to create these files can be used alternatively. After the 308 .TAR file has been created, it can then be encrypted using any suitable encryption algorithm 310.

[0050] Next, a new image (312) can be created, including an encrypted .TAR file. The new image can also include one or more insensitive data layers, one or more signal layers, and a decryptor layer from the original unencrypted image. The entry point (314) of the original image can be modified so that the decryptor layer of the new image runs first when it is instantiated. After the decryptor layer has run, the original entry point can be invoked. After modifying the entry point (314), the new image can be stored in the production repository (316). At this point, the new image may be ready for use in the production environment.

[0051] Return to Figure 2 Image 400 is an example of a new image that can be created, such as through example method 300. Because image 400 may include one or more encryption layers, image 400 can be described as encrypted, but not all layers of image 400 may be encrypted.

[0052] exist Figure 2In the example, mirror 400 includes insensitive layers, such as OS layer 402 and layers 404 and 406, which may be copies or restores of OS layer 202 and layers 204 and 206 of mirror 200, respectively. Furthermore, mirror 400 may include a signal layer 408, which may be a copy or restore of signal layer 214. Signal layer 408 may instruct the system that encryption layer 410 should be decrypted by decryptor layer 412. Since decryptor layer 412 can be defined as an entry point, such as... Figure 2 As shown, the decryptor layer 412 can therefore be run first when image 400 is instantiated. After the decryptor layer 412 has been run, the original entry point as shown in image 200 can be invoked.

[0053] Therefore, an image 400, such as one generated from the original image 200 via method 300, may include a self-decryptable image or a decryptable layer. Thus, image 400 can decrypt sensitive information within image 400 or perform other functions on image 400 without relying on any external processes, entities, or services. Instead, image 400 performs its own decryption on its encryption layer 410. Furthermore, since sensitive information can remain encrypted before runtime, image 400 can provide guarantees regarding the security of that sensitive information.

[0054] During deployment, the system can use a new encrypted image 400 and provide the decryption key through standard secret processing. In Docker Swarm, for example, the system can use a secret mechanism, or in Kubernetes, it can use ETCD and a secret mechanism.

[0055] Stay tuned Figure 2 The example encrypted image 400 provides further details about decryptors such as the example decryptor layer 412. In some implementations, the decryptor layer comprises a decryptor application in the form of a small Linux-based executable file that decrypts the encrypted .TAR file to the container's local file system. The decryptor can also open the .TAR file to restore sensitive layers 208, 210, and 212 of the original image 200 to image 400. Before exiting, the decryptor can transfer control to the original entry point, which was given before the image was encrypted and is shown in example image 200. The operations of decryptor layer 412 decrypting encryption layer 410 and opening the .TAR file can be performed automatically after a new image is instantiated.

[0056] Since the decryptor can be part of the image, it does not require support from the runtime environment. Instead, the decryptor can run as part of the standard container initialization, and therefore can be transparent to the runtime system and the image layer itself. It should be noted that alternative implementations can support operating systems other than Linux in a similar manner.

[0057] As previously disclosed, an image like example image 400 can include multiple separate encryption layers, such as encryption layer 410. This configuration can be achieved by adding the following command:

[0058] The `RUN` echo "=========STOP ENCRYPTION========" identifies layers that may be plain text. Signal layers 408 and the stop signal layer can be repeated multiple times in a given image 400. In at least some implementations, only one decryptor executable layer may exist in the final image, regardless of the number of encryption layers. This decryptor layer can decrypt all encryption layers before invoking the original entry point. Care should be taken when using multiple layers, as plain text layers can be a source of leakage for sensitive information. That is, if encryption layers exist that are shared by multiple containers, these encryption layers can be shared in their encrypted form in this way to maintain bandwidth efficiency during download, even though the layers are encrypted.

[0059] While the OS layer of an image like example image 200 may not be encrypted in some implementations, there may be a need to encrypt the OS layer in other implementations. If encryption of the OS layer and / or other insensitive layers (such as layers 202, 204, and 206) is required, a bootloader layer can be added only to the OS layer to run the decryptor. The bootloader layer may only need to have sufficient functionality to run the decryptor, and nothing more. This approach still makes encryption and decryption transparent to the deployment environment, but runtime decryption may take longer because the OS, which is typically larger in size, is also decrypted before the image is instantiated. Furthermore, if the OS layer and / or other insensitive layers are encrypted, container environment variables used to pass runtime parameters to the application may need to be moved from the loader environment to a separate, decrypted OS.

[0060] As disclosed later herein, exemplary implementations particularly include the encryption and decryption of images, such as Docker images or portions thereof. Such implementations can simplify management using command files and embedded decryptors, and enable images to be ported to a variety of different runtime environments. Exemplary implementations of the invention may include various attributes such as relative ease of use, efficient instantiation at runtime, avoidance of the need to change or adapt to the runtime environment, and transparency to containers, runtime environments, and / or administrators. Some specific implementations may employ signal layers as markers to identify which layer(s) will be encrypted. Some implementations may embed a decryptor within the encrypted image, which can run prior to the original entry point specified for the unencrypted image. Some implementations may support multiple encryption layers. Finally, some implementations may provide encryption of the OS and / or other non-sensitive information.

[0061] In addition to things like... Figures 1 to 3 In addition to the described containers, embodiments of the invention also involve encrypting and / or decrypting an image or portions thereof in a manner that separates the decryptor from the main image or main container. Typically, embodiments of the invention use an initialization container (e.g., an init container in Kubernetes). An initialization container is a separately packaged container configured (and ensuring) to run before the application image or main image runs. If the initialization container fails, the application container will not run.

[0062] In some examples, the initialization container is used for various purposes of attaching device data. However, embodiments of the invention relate to an initialization container configured to manipulate other containers, including containers that are part of a pod. By way of example only, a pod may include one or more containers or images. Thus, the application container and the initialization or decryption container may be included in the same pod. Since the initialization or decryption container is separate from the main container or application container, only the device and parameters can be mapped to the initialization container.

[0063] Figure 4 An example of an image that has been split into multiple images is shown. In another example, Figure 4 This demonstrates how, when packaging or creating an image, two new images are created (or an existing image can be split). One image contains the main application, and the other contains the decryptor. This allows the decryptor to be separated from the main image.

[0064] When creating an image, it is not necessary to have a signal layer, because the location of the encryption layer can be predetermined in the image that includes the encryption layer / file and the decryptor.

[0065] Figure 4It can also correspond to a command file that generates a separate image during execution. Alternatively, a separate command file can be used to generate the various images discussed herein. Image 452 includes layers 454, 456, signal layer 458, sensitive layer 460, and sensitive layer 462. For example... Figure 4 As shown, image 452 is packaged or split into main image 470 and initialization image 480. In other words, image 452 represents the regular image. Main image 470 and initialization image 480 indicate that the main application and the decryptor are packaged separately as different but related images. Figure 4 The mirror image shown may have the same characteristics as the previous one. Figure 2 The same format as described.

[0066] For the purposes of discussion, just as splitting image 452 into separate images... Figure 4 The discussion has been conducted. However, as previously mentioned, embodiments of the present invention may have two related command files: one command file for assembling or packaging the main image including the main application, and one command file for assembling or packaging the decryptor image. The process will include a signal layer, enabling the packaging process to know which layers to encrypt.

[0067] Figure 4 The diagram shows that image 452 is split into a main image 470 (which includes, for example, the main application) and an initialization (or decryptor) image 480. Insensitive layers 454 and 456 are placed as layers 454 and 456 within the main image 470. A copyer layer 472 is added to the main image 470.

[0068] The initialization image 480 contains a decryptor layer 482, a signal layer 458, and an encryption layer 484. The encryption layer 484 is generated by encrypting / combining or combining / encrypting sensitive layers 460 and 462. However, in one example, sensitive layer 460 can be encrypted alone. The signal layer 458 in the initialization image 480 allows the decryptor layer 482 to locate the encryption layer 484 and perform decryption. However, the signal layer 458 can be removed, and the encryption layer 484 can be in a predefined position. In one example, the signal layer 458 is not needed in the initialization image 480.

[0069] In this example, each image is built separately and the pod specifications can be as follows:

[0070] apiVersion: v1

[0071] Type: Pod

[0072] Metadata:

[0073] Name: myapp-pod

[0074] Label:

[0075] Application: myapp

[0076] Specification:

[0077] container:

[0078] Name: myapp-container

[0079] Image: myapp_clean:1.1 (Main image 470)

[0080] init container:

[0081] - Name: init-myapp

[0082] Image: myapp_init:1.1 (Initialize image 480)

[0083] In this example, the pod consists of two containers, and the initialization container or image 480 is defined in this pod specification. The pod specification ensures that the initialization container, which performs decryption, can run and complete before the main container or image 470 runs.

[0084] Because the decryptor runs in a separate container from the main container, it does not depend on the OS associated with the main application. This illustrates how a decryptor can be independent of the application's OS.

[0085] Furthermore, because the initialization container can run from a different view of the file system or device than the main container or other containers in the same pod, the decryption key can be provided to the initialization container. The main application in the main container cannot access the decryption key.

[0086] Figure 5 An example of a container run sequence for a pod specification is shown. When the sequence begins, a 502 initializer container is run. As previously stated, the initializer container runs first and can continue running until completion. In one example, the main application container is not started or run unless the initializer container completes successfully.

[0087] Next, the decryptor locates the signal layer and uses it to pinpoint the 504 encryption layer or data. Alternatively, the decryptor can use a predetermined location where the encryption layer or data is stored.

[0088] Next, the decryptor decrypts the encrypted layers or data to a directory on the file system (e.g., / mainappdecrypted). This can be in the base directory, and in one example, each layer of the image can have its own directory under the base directory.

[0089] If the container initialization runs and completes successfully, the main application container runs (508). The application layer runs normally until the cloner layer is reached. The cloner layer runs (510). The cloner layer copies the unencrypted layer from the file system (e.g., from / mainappdecrypted) to its location in the layer root directory. Then the main application runs (512).

[0090] By placing the decryptor in a separate image or container, decryption is transparent to the main application or main image. This makes the solution both modular and more secure.

[0091] In some examples, multiple signal layers and stop signal layers may exist in the image. In some examples, signal layers may not be needed. Pre-defined locations can be used. In one example, a copyer layer is provided for each set of signal and stop signal layers. At runtime, each encrypted data layer is opened to a separate directory. The corresponding copyer layer is then copied from the specified layer or directory.

[0092] Embodiments of the invention also include additional initialization layers. In one example, the decryptor image is configured to run first and may be the first initialization image in the pod specification. If any initialization layers are placed before the decryptor image, in one example, these initialization layers should not contain any encryption layers. Furthermore, these layers may pose a security risk, as they could potentially attempt to manipulate the input to the decryptor image.

[0093] Figure 6 An example of a method for creating a pod or package is shown. Method 600 includes packaging a 602 application. Packaging the application may include, for example, splitting an image into at least two distinct images. This may require processing the initial image to evaluate layers in order to identify which layers are considered to contain sensitive information that may be encrypted. Alternatively, the application may be packaged as two images. In any example of one implementation, the package includes at least two images. One image includes the main application, and the other image includes a decryptor and layers containing encrypted sensitive data or other encrypted data. The image with the decryptor is executed first. Optional signal layers or predefined locations may be used to identify the location of encrypted sensitive data. After the decryptor image completes successfully, the other image may be executed. This image includes a copyer layer that allows the decrypted data to be copied into the main container instance.

[0094] When packaging the application, configure the image to return a 604 error so that the decryptor image is executed first.

[0095] The following are some additional exemplary embodiments of the present invention. These embodiments are presented by way of example only and are not intended to limit the scope of the invention in any way.

[0096] Implementation 1. A method comprising: packaging an application associated with sensitive data into at least a first image and a second image by: placing a first layer in the first image, the first layer including a copy program layer; placing a second layer in the second image, wherein the second layer includes a decryptor layer and an encryption layer including the sensitive data in an encrypted form; and configuring the second image to run prior to the first image.

[0097] Implementation Method 2. The method as described in Implementation Method 1, the method further includes running the second image as an initialization container, wherein the execution of the initialization container includes decrypting the encryption layer through a decryptor to obtain decrypted sensitive data.

[0098] Implementation method 3. The method as described in implementation method 1 and / or 2, the method further comprising storing the decrypted sensitive data in a directory of a file system.

[0099] Implementation 4. The method as described in Implementation 1, 2 and / or 3, further comprising running the first image as the main container after the initialization of the container is successfully completed.

[0100] Implementation 5. The method as described in Implementations 1, 2, 3 and / or 4, further comprising running the copying layer, wherein the copying layer copies the decrypted sensitive data in the directory to a location in the layer root directory associated with the main application.

[0101] Implementation 6. The method as described in Implementations 1, 2, 3, 4 and / or 5, the method further comprising generating a pod specification such that the second image runs and completes before the first image runs.

[0102] Implementation method 7. The method as described in implementation methods 1, 2, 3, 4, 5 and / or 6, the method further comprising generating the encryption layer by encrypting one or more sensitive layers of the sensitive data.

[0103] Implementation method 8. The method as described in implementation methods 1, 2, 3, 4, 5, 6 and / or 7, wherein packaging the application includes splitting an image into a first image and a second image, or constructing a command file for the first image and a command file for the second image.

[0104] Implementation 9. The method as described in Implementations 1, 2, 3, 4, 5, 6, 7 and / or 8, further comprising placing the decryptor layer in the second image such that the decryptor layer in the second image is independent of the operating system included in the first image.

[0105] Implementation 10. The method as described in Implementations 1, 2, 3, 4, 5, 6, 7, 8 and / or 9, wherein the second mirror includes a signal layer and a stop signal layer for identifying the position of the encryption layer in the second mirror.

[0106] Embodiment 11. A method for performing any of the operations, methods, or processes disclosed herein, or any part thereof, including any part as described in any of Embodiments 1 to 10.

[0107] Implementation 12. A non-transitory storage medium storing instructions that can be executed by one or more hardware processors to perform operations as described in any one or more of Implementations 1 to 11.

[0108] As discussed in more detail below, the embodiments disclosed herein may include the use of a dedicated or general-purpose computer comprising various computer hardware or software modules. The computer may include a processor and a computer storage medium carrying instructions that, when executed by the processor, and / or cause to be executed by the processor, perform any or more of the methods disclosed herein, or perform any one or more portions of any of the disclosed methods.

[0109] As indicated above, embodiments within the scope of this invention also include a computer storage medium, which is a physical medium for carrying or storing computer-executable instructions or data structures. Such a computer storage medium can be any available physical medium accessible by a general-purpose or special-purpose computer.

[0110] By way of example and not limitation, such computer storage media may include hardware memory such as solid-state drives / devices (SSDs), RAM, ROM, EEPROM, CD-ROM, flash memory, phase-change memory (“PCM”), or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other hardware storage device that can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to perform the functions disclosed in this invention. Combinations of the above should also be included within the scope of computer storage media. Such media are also examples of non-transitory storage media, and non-transitory storage media also include cloud-based storage systems and structures, but the scope of this invention is not limited to these examples of non-transitory storage media.

[0111] Computer-executable instructions include, for example, instructions and data that, when executed, cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a function or a set of functions. Therefore, some embodiments of the present invention may be downloadable, for example, from a website, mesh topology, or other source to one or more systems or devices. Furthermore, the scope of the present invention includes any hardware system or device that includes instances of applications comprising the disclosed executable instructions.

[0112] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions disclosed herein are disclosed as exemplary forms for implementing the claims.

[0113] As used herein, the terms "module" or "component" can refer to a software object or routine that executes on a computing system. The various components, modules, engines, and services described herein can be implemented as objects or processes that execute on a computing system, for example, as individual threads. While the systems and methods described herein can be implemented in software, implementations utilizing hardware or a combination of software and hardware are also possible and contemplated. In this invention, a "computing entity" can be any computing system as previously defined herein, or any module or combination of modules running on a computing system.

[0114] In at least some cases, a hardware processor is provided, operable to implement executable instructions to perform methods or processes, such as those disclosed herein. The hardware processor may or may not include other hardware, such as elements of the computing devices and systems disclosed herein.

[0115] Regarding the computing environment, embodiments of the present invention can be executed in a client-server environment (whether a network environment or a local environment) or in any other suitable environment. Suitable operating environments for at least some embodiments of the present invention include cloud computing environments, in which one or more of the client, server, or other machines can reside and operate in the cloud environment.

[0116] Now simply refer to Figure 7 ,Depend on Figures 1 to 3 Any or more of the entities disclosed or implied elsewhere herein may take the form of, include, be implemented on, or be hosted by a physical computing device, an example of which is represented by 700. Furthermore, where any of the foregoing elements includes or comprises a virtual machine (VM), the VM may constitute... Figure 4 Virtualization of any combination of physical components disclosed in the document.

[0117] exist Figure 7 In the example, the physical computing device 700 includes: a memory 702, which may include one, some, or all of the following: random access memory (RAM), non-volatile random access memory (NVRAM) 704, read-only memory (ROM), and persistent memory; one or more hardware processors 706; a non-transitory storage medium 708; a user interface (UI) device 710; and data memory 712. One or more of the memory components 702 of the physical computing device 700 may be in the form of solid-state drive (SSD) memory. Furthermore, one or more application programs 714 may be provided, which include instructions executable by one or more hardware processors 706 to perform any or part of the operations disclosed herein.

[0118] Such executable instructions may take various forms, including, for example, instructions executable to perform any method or part thereof disclosed herein, and / or instructions executable at any of any storage site (whether on-premises or cloud storage), client, data center, or backup server to perform any function disclosed herein. Furthermore, such instructions may be able to perform any other operations and methods disclosed herein, and any part thereof.

[0119] Embodiments of the invention, such as those disclosed herein, can be advantageous in various respects. For example, and as will be apparent from this disclosure, one or more embodiments of the invention can provide one or more advantageous and unexpected effects in any combination, some of which are set forth below. It should be noted that such effects are neither intended nor should be construed as limiting the scope of the claimed invention in any way. It should also be noted that nothing herein should be construed as an essential or indispensable element constituting any invention or embodiment. Rather, aspects of the disclosed embodiments can be combined in various ways to define additional embodiments. Such additional embodiments should be considered to be within the scope of this disclosure. Furthermore, embodiments included within the scope of this disclosure should not be construed as solving or being limited to solving any one or more particular problems. Nor should any such embodiments be construed as implementing or being limited to implementing any one or more particular technical effects or solutions. Finally, not every embodiment needs to achieve any of the advantageous and unexpected effects disclosed herein.

[0120] The following is a discussion of various aspects of exemplary operating environments for different embodiments of the present invention. This discussion is not intended to limit the scope of the invention or the applicability of the embodiments in any way.

[0121] Generally, embodiments of the present invention can be implemented in combination with systems, software, and components that individually and / or collectively enable and / or cause the creation, modification, encryption, and / or decryption of one or more container images. More generally, the scope of the present invention encompasses any operating environment in which the disclosed concepts may be useful.

[0122] Implementations of this invention may be used in conjunction with container-based platforms (such as Docker), but no specific platform is required in any implementation. Container-based platforms may involve or include deployment environments such as cloud computing environments. Example cloud computing environments that may be used in exemplary implementations of this invention include, but are not limited to, Dell EMC Cloud, Microsoft Azure, Amazon AWS, and Google Cloud. However, more generally, the scope of this invention is not limited to cloud computing environments employing any particular type or implementation.

[0123] The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments should be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than the foregoing description. All variations within the meaning and scope of the equivalent forms of the claims are to be included within the scope of the claims.

Claims

1. A method of optimizing container image encryption, the method comprising: packaging an application associated with sensitive data as at least a first image and a second image by placing a first layer in the first image, the first layer comprising a copy program layer configured to perform copying, and placing a second layer in the second image, wherein the second layer comprises a decrypter layer configured to perform decryption and an encryption layer comprising the sensitive data in encrypted form; configuring the second image to run before the first image; running the second image as an initialization container and running the first image as a main container after the initialization container successfully completes, wherein the initialization container decrypts the encryption layer by the decrypter to obtain decrypted sensitive data and stores the decrypted sensitive data in a directory of a file system; and running the copy program layer, wherein the copy program layer copies the decrypted sensitive data from the directory into the main container.

2. The method of claim 1, further comprising running the main container after the initialization container successfully completes.

3. The method of claim 1, further comprising producing a pod spec such that the initialization container runs and completes before the main container runs.

4. The method of claim 1, further comprising producing the encryption layer by encrypting one or more sensitive layers of the sensitive data.

5. The method of claim 1, wherein packaging the application comprises splitting a certain image into the first image and the second image, or constructing a command file for the first image and constructing a command file for the second image.

6. The method of claim 5, further comprising placing the decrypter layer in the second image such that the decrypter layer in the second image does not depend on an operating system included in the first image.

7. The method of claim 1, further comprising creating the first image and the second image.

8. The method of claim 1, wherein, the second image comprises a signal layer identifying a location of the encryption layer in the second image and a stop signal layer.

9. A non-transitory storage medium having stored therein instructions executable by one or more hardware processors to perform the method of any one of claims 1-8.

Images