Protecting container ecosystems

Abstract

Embodiments of the present disclosure relate to securing container ecosystems. Examples described herein relate to a security management system that secures a container ecosystem. In some examples, the security management system can secure one or more entities, such as a container management application, a container image, a container, and / or an executable application within a container. The security management system can utilize digital cryptography to generate digital signatures corresponding to one or more of these entities, and to verify them during execution, so that any compromised entity can be blocked from execution, and the container ecosystem can be protected from any malicious cyberattacks.

Description

Background Technology

[0001] A container is a virtual computing instance that bundles useful elements such as resource allocation (e.g., compute, storage, etc.), data, and instructions into a single executable unit to run an application in any suitable computing environment. Container management applications facilitate the creation, deployment, and management of container images and / or containers. Container images can be stored on a container image repository and can be used to create containers using container management applications such as container runtimes.

[0002] As described above, container management applications, container image repositories, and / or containers can be deployed on host platforms (e.g., host systems) within host network infrastructure spanning personal / home networks, private clouds, public clouds, and personal or shared data centers. As will be understood, these host platforms and host network infrastructures may or may not be adequately protected, allowing attackers or intruders to compromise and disrupt container management applications, newly built container images, container image repositories, and / or container images stored in container image repositories. In some cases, even the container runtime may be compromised, and attackers may also be able to modify executables within the containers. In certain situations, such malicious attacks could lead to large-scale service disruptions for customers running applications via these containers. Attached Figure Description

[0003] The features, aspects, and advantages of this specification will become better understood when the following detailed description is read with reference to the accompanying drawings, in which the same characters represent the same parts throughout the drawings.

[0004] Figure 1 This illustrates a container ecosystem in which various examples presented in this article can be implemented.

[0005] Figure 2 An example container image is shown.

[0006] Figure 3 An example signature store is shown.

[0007] Figure 4 An example security management system is shown to protect multiple entities in a container ecosystem.

[0008] Figure 5 A flowchart is shown for an example method for securely executing container-managed applications.

[0009] Figure 6 A flowchart is shown for another example method for securely executing container-managed applications.

[0010] Figure 7 A flowchart is shown for an example method used to verify the authenticity of a container management application.

[0011] Figure 8 A flowchart illustrating an example method for protecting a container image is shown.

[0012] Figure 9 A flowchart is shown as an example method for generating instruction-level digital signatures for container images.

[0013] Figure 10 A flowchart is shown for an example method used to verify a container image.

[0014] Figure 11 A flowchart is shown as an example method for protecting executable applications in a container image.

[0015] Figure 12 A flowchart is shown for another example method for generating an executable application digital signature for an executable application referenced in a container image.

[0016] Figure 13 A flowchart is shown for an example method used to verify an executable application in a container image.

[0017] Figure 14 A flowchart is shown of an example method for protecting a runtime executable application referenced in the read-write layer of a container.

[0018] It should be emphasized that the features in the accompanying drawings are not drawn to scale. In fact, the dimensions of the features have been arbitrarily increased or decreased in the accompanying drawings for clarity of discussion. Detailed Implementation

[0019] Containers have become a popular choice for enabling cloud-native applications on a small or large scale due to their high modularity and scalability. Containers are widely used in today's cloud-based distributed IT infrastructures for hosting applications. Containers isolate software and allow it to work independently across different operating systems, hardware, networking, and storage systems. For example, as a unit, a container can easily move and run on any operating system on any platform, from personal computers to large or small cloud environments (e.g., public or private clouds). Containers allow container-based applications to seamlessly transition between development, testing, and production environments. Because the operating system is not encapsulated within the container, each container uses minimal computing resources, making it lightweight and easy to install, and providing developers with an efficient way to deploy it in clusters where individual containers host individual components of complex applications.

[0020] Containers are managed by container management applications, which include container image building tools (e.g., Docker, Podman, Buildah), container runtimes (e.g., RunC, Containerd, Docker, or Windows Containers), and container orchestration tools (e.g., Kubernetes, Docker Swarm, and Apache Mesos). Specifically, as used herein, the term "container management application" refers to any application that performs the creation of container images, the creation of containers from container images, the management of container lifecycle actions, the scheduling of containers, and / or the migration of containers. A container image is a lightweight, standalone, executable software package that includes everything needed to run an application. Lifecycle actions can include the initialization of containers created using container images, the recovery of containers, the updating of containers, or a combination thereof. Container management applications, container image repositories storing container images, and / or the containers themselves are vulnerable to security threats if they are hosted on poorly protected or insecure host platforms and host network infrastructure.

[0021] Attackers or intruders can compromise the container management application itself and modify it by injecting malicious data and / or code. In some cases, newly built container images may be compromised before being uploaded to a container image repository. In some cases, the container image repository may be compromised, and the container images hosted on the repository may be compromised. In some other cases, a real (i.e., uncompromised) container image downloaded from the container image repository can be injected with malicious content before it is executed by the container runtime. In some cases, even the container runtime may be compromised. Furthermore, even during container execution, attackers can modify executables within the container. These threats can lead to the execution of malicious container workloads. In some cases, attackers may even be able to escalate privileges and hijack the host platform via container breaches. In some implementations, even the entire host platform cluster may be affected, resulting in large-scale service outages for customers.

[0022] Some existing solutions aim to protect the distribution of container images. Some existing solutions employ techniques involving signing the container image manifest and using that signature to verify the container image before downloading it from the container image repository. However, the cited existing solutions do not protect containers deployed based on container images, nor do they protect the container image itself during the time between its creation and loading into the container image repository. Some existing solutions require reporting of unexpected processes running within containers; however, they cannot inspect the integrity of the container image and the container itself, nor can they prevent the execution of security threats.

[0023] To protect the container ecosystem, detecting and reporting incidents may not be enough, because there is a time window before an operator shuts down a host platform running any compromised containers to execute tampered container workloads and cause damage.

[0024] Based on examples consistent with this disclosure, a security management system is proposed to address one or more of the aforementioned problems. Specifically, the proposed security management system is configured to protect multiple entities within the container ecosystem, thereby preventing further execution of any compromised container management applications, container images, containers, and / or executable applications within containers.

[0025] For example, a security management system can protect container management applications to ensure that compromised applications are prevented from executing, thereby protecting the host system from creating and executing any malicious containers. This is at least in part because the security management system can periodically or upon request look for any container management applications hosted on a given host platform (also known as the host system). When a container management application is found on the host system, the security management system can generate a Container Management Application Digital Signature (CMADS) based on the application. In some examples, the CMADS can be a cryptographic hash of the container management application's signature.

[0026] During host system operation, the security management system monitors any attempts to run a container management application and verifies the application using CMADS when such an attempt is detected. If the container management application is successfully verified using CMADS, the security management system may allow its execution. If the application is found to be compromised (i.e., if verification fails), the security management system blocks its execution. Furthermore, in some examples, the security management system may enable immutability for the container management application. Activating immutability prevents any modifications to the application. Therefore, if immutability is enabled, the security management system can not only detect and block the execution of compromised container management applications but also prevent modifications to them.

[0027] In some examples, security management systems protect container images to ensure that the use of compromised container images is prevented. Container images typically consist of multiple instruction layers, each of which comprises a set of objects (e.g., commands, files, executable applications, data, etc.). To protect the container image, the security management system iterates through the instruction layers of the container image and generates instruction layer digital signatures corresponding to the multiple instruction layers based on the respective set of objects. Specifically, for each instruction layer, the security management system calculates a first-level cryptographic hash of the object and a second-level cryptographic hash based on the first-level cryptographic hash. The management system can then sign the second-level cryptographic hash to generate an instruction layer digital signature (ILDS) for the corresponding instruction layer. Once an ILDS has been generated for each instruction layer in the container image, the security management system can upload the container image to a container image repository. Furthermore, the security management system can store the ILDS of the container image along with the container image identifier in a signature repository.

[0028] When a container image is downloaded by a user on a host system to create one or more containers, a security management system hosted on the host system can trigger verification of the container image to ensure it has not been tampered with. The security management system can verify the container image using an ILDS stored in a signature repository. As will be understood, verifying a container image using an ILDS not only helps establish the authenticity of the container image but also helps identify the compromised instruction layer. Furthermore, since the container image is uploaded after the ILDS is generated, any tampering with the container image during the time between ILDS generation and uploading the container image to the container image repository can also be detected, and the use of such tampered container images can be prevented.

[0029] In some examples, the security management system protects executable applications to ensure that containers containing any compromised executable applications are prevented from further execution. Specifically, the executable application can be verified when the container (a container created using a container image that references the executable application) is run. Verifying the executable application in addition to the container image (as described above) aims to effectively detect and prevent the execution of a tampered application, as there is an opportunity for the executable application to be tampered with during container execution. In some examples, to enable this security, the security management system can generate an executable application digital signature (EAPPDS) based on the cryptographic hash of the executable application referenced in the instruction layer of the container image. In some examples, the EAPPDS can be stored in a signature store and can be transferred to the container management application during the execution of the container created using the container image to verify the executable application.

[0030] The term "digital signature" as used in this article, or its specific variants such as CMADS, ILDS, and EAPPDS, can refer to a digital code of a predetermined length consisting of a string (including letters, numbers, symbols, and / or special characters). These digital signatures can be created by applying any appropriate predefined function (e.g., a mathematical / cryptographic algorithm) to the corresponding source data.

[0031] As will be understood, the proposed solutions implemented through a security management system provide multi-layered security for container technology and overcome several problems encountered in existing technologies. As mentioned above, in some examples, the proposed solutions help prevent compromised container management applications. In some examples, they can even prevent any modifications to the container management application. Furthermore, in some examples, container images can be protected at the instruction layer level. Not only is the use of compromised container images prevented, but tampered instruction layers can also be identified. This can facilitate easier and faster debugging of compromised container images. Moreover, in some examples, the proposed solutions minimize the chance of running compromised executables during container execution, thereby protecting the host platform from the host platform cluster and preventing further impact on the host platform cluster, thus reducing the impact on customer workloads.

[0032] The following detailed description refers to the accompanying drawings. It should be clearly understood that the drawings are for illustrative and descriptive purposes only. While several examples are described in this document, modifications, adjustments, and other implementations are also possible. Therefore, the following detailed description does not limit the disclosed examples. Rather, the appropriate scope of the disclosed examples may be defined by the appended claims.

[0033] Before describing in detail examples of the disclosed systems and methods, it is helpful to describe example network installations that can implement these systems and methods in various applications. Figure 1 A container ecosystem 100 is illustrated, in which various examples presented herein can be implemented. The container ecosystem 100 can be a networked system, which may include one or more of the following: a development host system 102, a runtime host system 104, a container image repository 106, and a signature repository 108, coupled to each other via a network 110. Figure 1 In the example implementation, for ease of illustration, a single instance of development host system 102, runtime host system 104, container image repository 106, and signature repository 108 is shown. In some examples, container ecosystem 100 may include more than one instance of one or more of development host system 102, runtime host system 104, container image repository 106, and signature repository 108. In one example implementation, container ecosystem 100 may include multiple runtime host systems configured to operate as a cluster.

[0034] In some examples, the container ecosystem 100 can be a distributed system in which one or more of the development host system 102, runtime host system 104, container image repository 106, and signature repository 108 are located in physically different locations (e.g., on different racks, on different enclosures, in different buildings, in different cities, in different countries, etc.) and are connected via network 110. In some other examples, the container ecosystem 100 can be a turnkey solution or integrated product. In some examples, the terms "turnkey solution" or "integrated product" can refer to an off-the-shelf packaged solution or product in which the development host system 102, runtime host system 104, container image repository 106, signature repository 108, and network 110 are all located within a common enclosure or rack.

[0035] Furthermore, in some examples, the container ecosystem 100 is implemented as an integrated product (e.g., a single compute system) performing the functions of one or more of the development host system 102, runtime host system 104, container image repository 106, and signature repository 108, and the network 110 can be used to connect the container ecosystem 100 to any other external compute system (not shown). Additionally, in some examples, the development host system 102 and runtime host system 104 can be implemented as a single compute system. Furthermore, in some examples, any form of container ecosystem 100, whether a distributed system, a turnkey solution, or an integrated product, can be reconfigured by adding or removing instances of the development host system, runtime host system, signature repository, and / or container image repository; and / or by adding or removing internal resources to these instances.

[0036] Examples of network 110 may include, but are not limited to, local area networks (LANs), wireless local area networks (WLANs), metropolitan area networks (MANs), wide area networks (WANs), storage area networks (SANs), personal area networks (PANs), cellular communication networks, public switched telephone networks (PSTNs), and the Internet, whether based on Internet Protocol (IP) or not. In some examples, network 110 may include one or more network switches, routers, or network gateways to facilitate data communication. Communication on network 110 may be performed according to various communication protocols, such as, but not limited to, Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), IEEE 802.11, and / or cellular communication protocols. Communication on network 110 may be via wired (e.g., copper cable, optical communication, etc.) or wireless (e.g., This can be achieved using communication technologies such as cellular communication, satellite communication, and Bluetooth. In some examples, network 110 can be enabled via a dedicated communication link, which includes, but is not limited to, communication links established via Bluetooth, cellular communication, optical communication, radio frequency communication, or wired (e.g., copper cable). In some examples, the dedicated communication link can be a direct communication link between development host system 102, runtime host system 104, container image repository 106, and signature repository 108.

[0037] Development host system 102 and runtime host system 104 can each be a computing device including a processor or microcontroller and / or any other electronic components, or a device or system that can facilitate computing and / or data storage for container management. Examples of development host system 102 and runtime host system 104 may include, but are not limited to, desktop computers, laptop computers, smartphones, servers, workstations, storage systems, converged or hyperconverged systems, etc. In some examples, development host system 102 and runtime host system 104 can be implemented as virtual computing resources such as virtual machines. Development host system 102 and runtime host system 104 can be configured to host container management applications, such as container management application 112A and container management application 112B, respectively. Container management applications 112A and 112B can be executed by processing the resources of development host system 102 and runtime host system 104, respectively. In some example implementations, each of the development host system 102 and runtime host system 104 can host both container management applications 112A and 112B.

[0038] Container management applications 112A and 112B are applications that facilitate one or more of the following operations: creating container images (e.g., container image 116), creating containers from container images, managing container lifecycle actions, scheduling containers, migrating containers, and / or any other operations involving containers or container images. Lifecycle actions may include initialization of containers created using container images, container recovery, container updates, or combinations thereof. Examples of container management applications 112A and 112B may include container builds (e.g., container builds from Docker, Podman, Buildah), container orchestrator (e.g., Kubernetes) control plane applications, and container orchestrator member node applications. Examples of container orchestrator control plane applications that can be used as container management applications 112A and 112B may include schedulers (e.g., kube-scheduler) and application programming interface (API) servers (e.g., kube-apiserver). In addition, container coordinator member node applications that can be used as container management applications 112A and 112B may include network agents (e.g., kube-proxy) for managing communication with containers, software agents (e.g., kubelet) for monitoring containers, and container runtimes (e.g., software responsible for creating and running containers).

[0039] For the purposes described below, container management application 112A is described as a container image building tool that can be used to create and manage a storage for container images (e.g., a container image). In some examples, a user can use container management application 112A to create a container image. Furthermore, once created, the container image can be stored in container storage 106. Additionally, for the purposes described below, container management application 112B is described as a container runtime for creating containers from container images and running containers.

[0040] To create and run containers on runtime host system 104, container images can be downloaded to runtime host system 104 from container image repository 106. In some examples, container image repository 106 may be a data repository hosted on a network node (not shown) accessible via network 110. Examples of network nodes hosting container image repository 106 may include desktop computers, laptops, smartphones, servers, workstations, storage systems, converged or hyperconverged systems, etc. In some examples, container image repository 106 may be hosted on a public cloud, private cloud, or hybrid cloud. In some other examples, container image repository 106 may be hosted locally on development host system 102 and runtime host system 104. In some examples, container image repository 106 may be implemented as a distributed data repository, where the contents of container images may be physically stored on multiple host systems, including development host system 102 and runtime host system 104.

[0041] Based on examples consistent with this disclosure, the development host system 102 and the runtime host system 104 may be configured with corresponding security management systems, such as security management systems 114A and 114B, to protect container management applications 112A and 112B, container images, and / or containers. Specifically, the proposed security management systems 114A and 114B are configured to prevent any compromised container management applications, container images, containers, and / or executable applications within containers from further execution. In some examples, security management systems 114A and 114B may be implemented as software applications, firmware, hardware modules, or combinations thereof. In some examples, security management systems 114A and 114B may be implemented as virtual computing resources, such as virtual machines, containers, pods, or combinations thereof.

[0042] In one example, security management systems 114A and 114B can be configured to prevent the execution of container management applications 112A and 112B if they are compromised. This protects the development host system 102 and / or the runtime host system 104 from creating container images and / or executing any malicious containers. For ease of illustration below, an example of protecting container management application 112A via security management system 114A is described. Security management system 114B can also be configured to protect container management application 112B in a similar manner.

[0043] Specifically, the security management system 114A can periodically or upon request search for any container management applications hosted on the development host system 102. When a container management application (e.g., ...) is found on the development host system 102... Figure 1When the container management application 112A is executed in the current implementation, the security management system 114A can generate a Container Management Application Digital Signature (CMADS) based on the container management application. In some examples, the CMADS can be a cryptographic hash of the signature of the container management application 112A. During operation, the security management system 114A can monitor any attempt to run the container management application 112A and verify the container management application 112A using CMADS when such an attempt is detected. If the container management application is successfully verified using CMADS, the security management system 114A can allow the container management application 112A to execute. If the container management application 112A is found to be compromised (i.e., if the verification of the container management application 112A fails), the security management system 114A blocks the execution of the container management application. Figures 5 to 7 The method described herein provides additional details for protecting container management applications 112A.

[0044] In addition, in some examples, security management system 114A protects container images, such as container image 116, to ensure that the use of compromised container images is prevented. Figure 2 An example container image is shown in (described later). Container images such as container image 116 typically include multiple instruction layers, each of which includes a set of objects (e.g., commands, files, executable applications, data, etc.). To protect container image 116, security management system 114A iterates through the instruction layers of the container image and generates instruction layer digital signatures (ILDS) corresponding to the multiple instruction layers based on the corresponding set of objects (see [link to documentation]). Figure 9 (Example method for generating ILDS). Once ILDS has been generated for each instruction layer in the instruction layer of container image 116, security management system 114A can upload container image 116 to container image repository 106 and upload the ILDS to signature repository 108. Figure 8 An example method for protecting container image 116 is described.

[0045] In some examples, the signature repository 108 can be implemented as a data repository hosted on a network node (not shown) accessible via network 110. Examples of network nodes hosting the signature repository 108 may include desktop computers, laptops, smartphones, servers, workstations, storage systems, converged or hyperconverged systems, etc. In some examples, the signature repository 108 may be hosted on a public cloud, private cloud, or hybrid cloud. In some other examples, the signature repository 108 may be hosted locally on development host system 102 and runtime host system 104. In some examples, the container image repository 106 can be implemented as a distributed data repository across multiple host systems, including development host system 102 and runtime host system 104. Figure 3 A sample signature store is described.

[0046] When container image 116 is downloaded by a user on runtime host system 104 to create one or more containers (e.g., container 118), the security management system 114B hosted on runtime host system 104 can trigger verification of container image 116 to ensure that container image 116 has not been tampered with. Security management system 114B can use ILDS stored on signature store 108 to verify the container image. Figure 10 A sample method for verifying container image 116 is described.

[0047] Furthermore, in some examples, security management systems, such as security management systems 114A and 114B, protect the executable application to ensure that a container (e.g., container 118) containing any compromised executable application is prevented from further execution. In some examples, to enable this security, security management system 114A may generate an executable application digital signature (EAPPDS) based on a cryptographic hash of the executable application referenced in the instruction layer of container image 116. In some examples, the EAPPDS may be stored in a signature store 108 and may be sent to runtime host system 104 to verify the executable application during the execution of container 118 created using container image 116.

[0048] Now for reference Figure 2 This illustrates an example container image, such as container image 116, with syntax 200(“synax”). For example, as... Figure 2 As shown, a container image 116 named "My Container Image" may include one or more instruction layers. For illustrative purposes, Figure 2 Each line in container image 116 shown is called an instruction layer. For example, Figure 2 The container image 116 shown is illustrated as having five instruction layers 120A, 120B, 120C, 120D, and 120E, hereinafter collectively referred to as instruction layers 120. Layers 120A, 120B, 120C, 120D, and 120E can be formed based on instructions 121A, 121B, 121C, 121D, and 121E (hereinafter collectively referred to as instructions 121) provided in an image build file (e.g., a Dockerfile). For illustrative purposes, instructions 121 are shown in container image 116; instructions 121 may not be included in container image 116. A container management application, such as container management application 112A, creates container image 116 based on the execution of instructions in the image build file. Container image 116 is envisioned to have more than Figure 2 The diagram shows more or fewer instruction layers. Additional instruction layers can be formed before or after any instruction layer 120.

[0049] Each instruction layer 120 may include a collection of objects. Objects may be commands, files (e.g., represented by corresponding filenames), executable applications (e.g., represented by corresponding application names), any text, special symbols, operators, or combinations thereof. For example, instruction layer 120A is shown as including objects 122A and 122B; instruction layer 120B is shown as including object 122A; instruction layer 120C is shown as including object 122B; instruction layer 120D is shown as including objects 122C and 122D; and instruction layer 120E is shown as including object 122E. As an example, objects 122A and 122B are the names of executable applications such as MyApp1 and MyApp2. It should be noted that, as... Figure 2 The content / syntax of container image 116 shown is for illustrative purposes. More specifically, the example content / syntax of container image 116 is presented to illustrate the structure of container image 116, including instruction layer 120 and objects 122A to 122E, rather than to specifically describe a particular use case or application. Furthermore, for illustrative purposes, in Figure 2 Objects 122A to 122E are shown in the diagram. Additional objects can be defined using at least a portion of the remaining information contained in the instruction layer; for example, "> / tmp / myapp1.out" contained in instruction layer 120B can be defined as an object.

[0050] Now turn to Figure 3 Example signature store 108 is shown. Figure 3 The signature store 108 can be a representation Figure 1 Examples of signature stores 108 are provided. In some examples, signature store 108 may include one or more signature repositories, such as Container Management Application Signature Repository (CMASS) 302, Container Image Signature Repository (CISS) 304, and / or Executable Application Signature Store (EASS) 306, collectively referred to below as signature stores. As described below, these signature repositories 304, 304, and 306 are collections of digital signatures and associated related information. Signature repositories 304, 304, and 306 may be updated and / or referenced by one or both of security management systems 114A and 114B to securely manage container management applications 112A and 112B; container images such as container image 116; and / or containers such as container 118. In some examples, signature repositories 304, 304, and 306 may represent logical separation of contents within signature store 108.

[0051] Specifically, CMASS 302 may include a digital signature for the container management application. For the example implementation of container ecosystem 100, CMASS 302 may include CMADS 310 for container management application 112A. Furthermore, CMASS 302 may also include an identifier (CMAID) for the container management application, such as CMAID 309 for container management application 112A. CMAID 309 may be a unique identifier value for container management application 112A (e.g., application name, serial number, etc.). Additionally, CMASS 302 may include a public encryption key (PUB.KEY 311), which corresponds to the private encryption key used by security management system 114A to create CMADS. Although not shown, in some examples, CMADS corresponding to container management application 112B may also be created by security management system 114B and stored in CMASS 302. Figure 5 and Figure 6 An example method for generating CMADS is described.

[0052] Furthermore, CISS 304 may include the ILDS of the container image. For the example implementation of container ecosystem 100, CISS 304 may include the ILDS corresponding to the instruction layer (e.g., instruction layer 120) of container image 116. For illustrative purposes, the CISS 304 shown in the figure stores instruction layer digital signatures ILDS 312A, ILDS 312B, ILDS 312C, ILDS 312D, and ILDS 312E (hereinafter collectively referred to as ILDS 312) corresponding to instruction layers 120A, 120B, 120C, 120D, and 120E, respectively. The instruction layer digital signatures ILDS 312A, ILDS 312B, ILDS 312C, ILDS 312D, and ILDS 312E may be signed values ​​of cryptographic hashes of the contents of instruction layers 120A, 120B, 120C, 120D, and 120E, respectively. Figure 9 An example method for generating ILDS is described.

[0053] In addition, CISS 304 may also include an identifier (IMAGE ID) 313 for the container image (e.g., container image 116). For example, IMAGE ID 313 may be a unique identifier for container image 116 (e.g., application name, serial number, etc.). Furthermore, CISS 304 may also include an identifier corresponding to each instruction layer 120 of the ILDS (hereinafter referred to as instruction layer identifier - ILID). For example, instruction layer identifiers ILID 314A, ILID 314b, ILID 314C, ILID 314D, and ILID 314E correspond to instruction layers 120A, 120B, 120C, 120D, and 120E, respectively. Furthermore, CISS 304 may include a public key (PUB.KEY 316), which corresponds to the private encryption key used by the security management system 114A to create the ILDS.

[0054] EASS 306 may include a digital signature of the executable application referenced in the container image, hereinafter referred to as an application digital signature (EAPPDS). For the example implementation of container ecosystem 100, EASS 306 may include EAPPDS 318A and EAPPDS 318B corresponding to executable applications, such as the executable applications “MyApp1” and “MyApp2” referenced in container image 116, respectively. Application digital signatures such as EAPPDS 318A and EAPPDS 318B may be signature values ​​of cryptographic hashes of the content (e.g., program code) of applications “MyApp1” and “MyApp2”, respectively. Figure 12 A sample method for generating EAPPDS is described.

[0055] In addition, EASS 306 may also include identifiers (APPIDs), such as APPID 320A and APPID 320B for executable applications “MyApp1” and “MyApp2”, respectively. The APPID can be a unique identifier for the executable application (e.g., application name, serial number, etc.). Furthermore, EASS 306 may also include a container identifier (e.g., IMAGE ID 313) that references the container image of the executable application. Additionally, in some examples, EASS 306 may include location information for executable applications “MyApp1” and “MyApp2”, such as PATH 322A and PATH 322B. Location information can identify the network storage path where the executable applications are stored. Furthermore, EASS 306 may include a public encryption key (PUB.KEY 324), which corresponds to the private encryption key used by the security management system 114A to create EAPPDS 318A and EAPPDS 318B.

[0056] In some examples, public encryption keys 311, 316, and 324 can be the same. In other examples, public encryption keys 311, 316, and 324 can be different.

[0057] Now turn to Figure 4 This illustrates an example security management system 400 configured to protect multiple entities within a container ecosystem (e.g., container ecosystem 100). When deployed in... Figure 1 In a container ecosystem of 100, Figure 4 The security management system 400 can be configured to operate as security management systems 112A and 112B, and can perform various operations described in one or more of the previous figures and one or more of the method flowcharts described below.

[0058] The security management system 400 may include a bus 402 or other communication mechanism for transmitting information (e.g., commands and / or data), a hardware processor also referred to as processing resource 404, and a machine-readable storage medium 406 coupled to the bus 402 for processing information. In some examples, the machine-readable storage medium 406 may be non-transient and is alternatively referred to as non-transient machine-readable storage medium 406. The machine-readable storage medium 406 may be any electronic, magnetic, optical, or other storage device capable of storing data and / or executable instructions. Examples of machine-readable storage medium 406 may include random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), storage drives, flash memory, magnetic disks, compact disc read-only memory (CD-ROM), etc. The machine-readable storage medium 406 may store data such as security policy 408 and / or one or more program instruction sets 410A, 410B, and 410C.

[0059] In some examples, processing resource 404 may include one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions in program instruction sets 410A, 410B, and / or 410C stored in machine-readable storage medium 406. For example, processing resource 404 may fetch, decode, and execute instructions to protect container ecosystem 100. As an alternative or supplement to retrieving and executing instructions, processing resource 404 may include one or more electronic circuits, including electronic components such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other electronic circuits for the function of executing one or more instructions. In some examples, when security management system 400 is implemented as a virtual resource (e.g., a VM, container, or software application), processing resource 404 and machine-readable storage medium 406 may respectively represent the processing resource and machine-readable storage medium of the host system (e.g., development host system 102 and runtime host system 104) hosting security management system 400 as a virtual resource.

[0060] In some examples, the security management system 400 may also include a network interface 416 coupled to bus 402. Network interface 416 provides bidirectional data communication coupling with one or more network links connected to one or more networks (e.g., network 110). For example, network interface 416 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem for providing data communication connections to a corresponding type of telephone line. As another example, network interface 416 may be a local area network (LAN) card or a wireless communication unit (e.g., a Wi-Fi chip / module).

[0061] Security policy 408, stored in machine-readable medium 406, can specify whether entities, such as container management applications, container images, containers, and / or executable applications, need to be protected. Specifically, security policy 408 can specify for each entity whether it needs to be protected via digital signature and verified during its execution. Table 1 presented below illustrates the configuration of an example security policy 408.

[0062] Container Management Application 112A yes Container Management Application 112B yes Container image 116 yes Executable application – "MyApp1" yes Executable application - "MyApp2" yes

[0063] Table 1 - Example Security Policy Configuration

[0064] The example security policy configuration shown in Table 1 indicates that all container management applications 112A and 112B, container image 116, and executable applications “MyApp1” and “MyApp2” are secure. Although not shown in Table 1, the security management system 400 can allow authorized users to update the protection status of entities. For example, an authorized user can define that executable application “MyApp2” is not protected by setting the protection status to “No”.

[0065] Program instruction sets 410A, 410B, and 410C may include instructions executable by processing resource 404 for performing... Figures 5 to 14 The method describes one or more operations. Specifically, instruction set 410A may store instructions that, when executed by processing resource 404, cause processing resource 404 to perform, for example, the execution of... Figure 5 , Figure 6 and Figure 7 The method describes one or more operations to protect a container management application, such as container management application 112A. Furthermore, instruction set 410B can store instructions that, when executed by processing resource 404, cause processing resource 404 to perform, for example, the execution of... Figure 8 , Figure 9 and Figure 10 The method describes one or more operations to protect the container image, such as container image 116. Furthermore, instruction set 410C can store instructions that, when executed by processing resource 404, cause processing resource 404 to perform, for example, the execution of... Figure 11 , Figure 12 , Figure 13 and Figure 14 The method describes one or more operations to protect executable applications, such as executable applications "MyApp1" and "MyApp2".

[0066] In the following description, we will use Figures 5 to 14 The flowcharts shown illustrate various operations performed by a security management system, such as security management system 112A or 112B. For illustrative purposes, [the flowcharts are] combined with [other methods]. Figure 1 Container ecosystem 100 and Figures 2 to 4 To describe the examples described in the text Figures 5 to 14 The flowchart, however Figures 5 to 14 The approach should not be interpreted as limited to the example configurations of the container ecosystem 100 and Figures 2 to 4 Examples are presented in the text. Figures 5 to 14The method may include multiple method blocks that can be executed by a processor-based system, such as security management system 400, representing an example of security management system 112A or 112B. Specifically, the operation at each of the multiple blocks can be executed by a processing resource, such as processing resource 404, by executing one or more of instruction sets 410A to 410C stored in machine-readable medium 406. Figures 5 to 14 The method shown can represent an example logical flow of some of the multiple operations performed by a security management system. However, in some other examples, Figures 5 to 14 The execution order of the method blocks may differ from the order shown. For example, operations at each block may be executed sequentially, in parallel, or in a combination of both.

[0067] Protect container management applications

[0068] In the following description, combined with Figures 5 to 7 The methods describe example operations for protecting container-managed applications. Specifically, Figures 5 to 7 The method describes how the proposed example security management system ensures that any compromised security management system container management is prevented from executing, thereby protecting the corresponding host system from the creation and execution of any malicious containers.

[0069] Now for reference Figure 5 This document presents a flowchart of an example method 500 for securely executing a container-managed application (e.g., container-managed application 112A). For the sake of brevity, this document does not repeat information regarding the combination of... Figure 1 This describes certain information about the operations performed at one or more boxes of method 500. Although method 500 is described with reference to security management system 114A for securely executing container management application 112A, the examples described herein are also applicable to security management system 114B for securely executing container management application 112B.

[0070] At box 502, security management system 114A can discover container management applications on a host system (e.g., development host system 102). Discovering container management applications may require scanning the contents of the host system to search for specific executables related to container management. Specifically, to discover container management applications, security management system 114A can periodically scan files stored on development host system 102 to identify files with one or more predefined file tags (e.g., metadata tags). Examples of predefined file tags that security management system 114A can look for may include SELinux tags equal to "container_runtime_exec_t" or "kubelet_exec_t". Any file with such a predefined file tag can be identified as a container management application. As an example, at box 502, security management system 114A can discover container management application 112A on development host system 102.

[0071] Furthermore, at box 504, for example, security management system 114A can generate CMADS based on container management application 112A. Specifically, security management system 114A can generate encrypted values ​​based on the content (e.g., program code) of container management application 112A to create CMADS (e.g., CMADS 310, see [link]). Figure 3 ). Combination Figure 6 Additional details regarding the generation of CMADS are described. In some examples, the security management system 114A may store CMADS 310 in the signature repository 108. In some examples, the security management system 114A may store CMADS 310 locally on the development host system 102.

[0072] During the operation of the development host system 102, the security management system 114A can be configured to allow the container management application 112A to run while keeping it undamaged / authentic. To provide this security, at box 506, the security management system 114A can detect attempts to run the container management application 112A. Typically, when an application executes on a computing system, it requests hardware resources (e.g., RAM, I / O devices, etc.) for use via the kernel of the operating system running on the computing system. The kernel is program code that is part of the operating system, and it acts as the interface between the user application (e.g., in this case, the container management application 112A) and the hardware components of the system (e.g., in this case, the development host system 102). According to the example presented herein, the security management system 114A can detect attempts to run the container management application 112A based on any interaction between the container management application 112A and the kernel of the operating system running on the development host system 102.

[0073] Upon determining that the container management application 112A has been attempted to run, at box 508, the security management system 114A can use CMADS to perform checks to verify the container management application 112A. Combined with Figure 7 Details of verifying container management application 112A are described. At box 508, if container management application 112A is successfully verified using CMADS, then at box 510, security management system 114A may allow execution of container management application 112A on host management system 102. However, at box 508, if verification of container management application 112A fails, then at box 512, security management system 114A may prevent execution of container management application 112A.

[0074] Now for reference Figure 6 This presents a flowchart of another example method 500 for securely executing a container-managed application (e.g., container-managed application 112A). Specifically, Figure 6 Method 600 is to represent Figure 5 Examples of method 500, and can include with Figure 5 Compared to the description herein, certain additional details and / or additional boxes are included. Although method 600 is described with reference to security management system 114A for securely executing container management application 112A, the examples described herein can also be applied to security management system 114B for securely executing container management application 112B. Furthermore, certain details of the operations performed at one or more boxes in method 600 have already been described in conjunction with the preceding figures and will not be repeated herein for the sake of brevity.

[0075] In some examples, at box 604, the security management system 114A can receive instructions to sign the container management application 112A. For example, a user can issue a signing command via a command-line interface (CLI) or a graphical user interface, which can instruct the security management system 114A. Command 1 presented below can be an example CLI command that can be used to sign the container management application 112A.

[0076] Discover SELinux label_Container_runtime_exec_t-sign... command (1)

[0077] In response to receiving an instruction to sign the container management application 112A, at box 602, the security management system 114A can discover the container management application on a host system, such as development host system 102. For example CLI command (1), the security management system 114A can scan files stored in development host system 102 to identify files with an SELinux tag equal to "container_runtime_exec_t".

[0078] Furthermore, at box 606, for example, security management system 114A can generate CMADS (e.g., CMADS 310) for container management application 112A. In one example, to create CMADS 310, at box 608, security management system 114A can first compute a cryptographic hash value for the container management application. Specifically, security management system 114A can select an executable file of container management application 112A (i.e., the executable file found at box 604) and apply a cryptographic hash function to the contents of the executable file. For example, security management system 114A can use cryptographic hash functions such as SHA-1, SHA-2, SHA-3, SHA-256, Whirlpool, BLAKE2, BLAKE3, and / or MD5 to generate the cryptographic hash value. It should be noted that the examples presented in this disclosure are not limited to performing any cryptographic operation using any particular cryptographic hash function. After applying a cryptographic hash function to any file or character set, a string (including letters, numbers, symbols, and / or special characters) can be generated, which is referred to as the cryptographic hash value. Therefore, by applying the cryptographic hash function to the executable file of container management application 112A, the cryptographic hash value of container management application 112A can be generated.

[0079] Furthermore, at box 610, the security management system 114A can use a private encryption key to sign the cryptographic hash value of the container management application 112A to generate a signed cryptographic hash value for the container management application 112A. The private encryption key may be a private encryption key associated with the development host system 102. The signed cryptographic hash value of the container management application 112A is CMADS 310.

[0080] In some examples, the security management system 114A may reference a security coprocessor chip (e.g., a Trusted Platform Module (TPM)) (not shown) on the development host system to sign the cryptographic hash value generated at box 608. The security coprocessor chip on the development host system 102 may conform to the Trusted Computing Group (TCG) specification. In some examples, the security coprocessor chip may include device-unique data, such as its private encryption key, which can be used for data encryption and decryption purposes. In some examples, an operating system running via the processing resources of the security management system 112A may request the security coprocessor chip to sign the cryptographic hash value of the container management application 112A to generate CMADS 310. The security management system 114A may store CMADS 310 in a signature repository 108 and / or locally on the development host system 102.

[0081] During the operation of host system 102, security management system 114A can be configured to allow container management application 112A to run while keeping it undamaged / real. To provide this security, at box 612, security management system 114A can detect attempts to run container management application 112A. To detect attempts to run container management application 112A, at box 614, security management system 114A can intercept kernel calls to identify the source of the kernel call. The kernel call can be a request for hardware resources made by a user application (e.g., container management application 112A) to the operating system kernel. Furthermore, at box 615, security management system 114A can determine the source of the kernel call (e.g., the initiator). The source of the kernel call can be the user application that initiated the kernel call.

[0082] For each kernel call, at box 616, security management system 114A can perform a check to determine whether the source of the kernel call is container management application 112A (i.e., the application discovered in box 604). At box 616, if it is determined that the source of the kernel call is not container management application 112A, security management system 114A can determine that the application issuing the kernel call is not container management application 112A, and control can be passed back to box 614. However, at box 616, if it is determined that the source of the kernel call is container management application 112A, security management system 114A can determine that container management application 112A has been attempted to run.

[0083] In response to the determination that an attempt to run container management application 112A has been made, at box 618, security management system 114A can use CMADS 310 to perform checks to verify container management application 112A. Combined with Figure 7Details of verifying container management application 112A are described. At box 618, if container management application 112A is successfully verified using CMADS, then at box 620, security management system 114A may allow execution of container management application 112A on host management system 102. However, at box 618, if verification of container management application 112A fails, then at box 622, security management system 114A may prevent execution of container management application 112A.

[0084] Furthermore, in some examples, security management systems 114A and / or 114B can implement immutability for container management applications 112A and 112B. When immutability is activated, the security management systems can prevent any modifications to container management applications 112A and 112B. For example, once the immutability of container management application 112A is activated, security management system 114A can monitor any attempts to edit the source code of container management application 112A (e.g., executable files / .exe files). If such an attempt to edit the source code of container management application 112A is detected, security management system 114A can block such an attempt and protect container management application 112A from any tampering. Therefore, if immutability is enabled, security management systems 112A and 112B can not only detect and prevent the execution of compromised container management applications 112A and 112B, but also prevent modifications to container management applications 112A and 112B.

[0085] Now turn to Figure 7 This presents an example method 700 for verifying the container management application 112A. Specifically, method 700 represents several operations performed at box 618 in method 600.

[0086] At box 702, the security management system 114A can calculate the runtime cryptographic hash value of the container management application 112A. This can be compared with... Figure 6 The runtime hash value is calculated in a similar manner to the instantaneous content hash value calculated in box 608 of the container management application 112A.

[0087] Furthermore, at box 704, the security management system 114A can use a public encryption key (e.g., public encryption key 311) associated with a private encryption key to decrypt CMADS (e.g., CMADS 310) to generate a decrypted signature. In an example where CMADS 310 and public encryption key 311 are not locally stored on the development host system 102, the security management system 114A can download CMADS 310 and public encryption key 311 from a signature store (e.g., signature store 108). Additionally, at box 706, the security management system 114A can perform a check to determine if the runtime cryptographic hash value (calculated at box 702) matches the decrypted CMADS (determined at box 704).

[0088] At box 706, if it is determined that the runtime cryptographic hash value matches the decrypted signature, then at box 708, the security management system 114A determines that the container management application 112A has been successfully authenticated, and therefore the container management application 112A is authentic / genuine. However, at box 706, if it is determined that the runtime cryptographic hash value does not match the decrypted signature, then at box 710, the security management system 114A determines that the authentication of the container management application has failed, and therefore the container management application 112A may have been tampered with.

[0089] Protect container images

[0090] In the following description, combined with Figures 8 to 10 The method describes example operations for protecting container images. For ease of explanation, it will be combined with... Figures 1 to 4 describe Figures 8 to 10 The method. Specifically, Figures 8 to 10 The method describes how to protect container images and prevent the use of any compromised container images, thereby protecting the corresponding runtime host system from creating and executing any malicious containers.

[0091] Now for reference Figure 8 The diagram presents a flowchart of an example method 800 for protecting a container image (e.g., container image 116). At block 802, security management system 114A can obtain container image 116. In one example, security management system 114A can retrieve container image 116 from local storage on development host system 102. Container image 116 may have been created on development host system 102 via container management system 112A or downloaded from an external source. As previously described, container image 116 may include multiple instruction layers (e.g., instruction layer 120, see...). Figure 2 Instruction layer 120 may include a collection of objects, such as objects 122A to 122E.

[0092] Furthermore, in block 804, the security management system 114A can generate ILDS (e.g., ILDS 312A to 312E) corresponding to multiple instruction layers (e.g., instruction layer 120) based on a corresponding set of objects. Specifically, to generate an ILDS for a given instruction layer, the security management system 114A can perform an encryption operation on the corresponding objects and sign the result of the encryption operation. Figure 9 The details of generating ILDS are described.

[0093] After creating the ILDS, at box 806, the security management system 114A can send ILDS 312A to 312E to the runtime host system, such as runtime host system 104. In some examples, to send the ILDS, the security management system 114A can store ILDS 312A to 312E in the signature store 108 (see [link to documentation]). Figure 3 In the example, ILDS 312A to 312E may be stored in the signature store 108 together with the container image identifier (e.g., image identifier 313), the identifier of the corresponding instruction layer (e.g., ILID 314A to 314E), and the public encryption key (e.g., public encryption key 316) corresponding to the private encryption key used to create ILDS 312A to 312E.

[0094] Furthermore, in some examples, at box 808, after the ILDS is generated, the security management system 114A can store the container image 116 in the container image repository 106. Therefore, any tampering with the container image during the time between the ILDS being generated and the container image being uploaded to the container image repository 106 can be detected, and the use of such tampered container images can be prevented.

[0095] Furthermore, in some examples, ILDS 312A to 312E can be sent from the signature store 108 to the runtime host system 104 in response to a download request from the container management system 112B of the runtime host system 104. Once downloaded by the runtime host system 104, the ILDS can be used by the security management system 114B on the runtime host system 104 to verify the container image during any lifecycle action of one or both of the container image 116 or the container (container 118) created using the container image 116. Figure 10 Details regarding the verification of container images are described.

[0096] Now turn to Figure 9 This document presents a flowchart of an example method 900 for generating ILDS (e.g., ILDS312A) for a container image (e.g., container image 116). Specifically, method 900 describes... Figure 8Method 900 comprises multiple sub-steps of method block 804. For illustrative purposes, method 900 is described with reference to ILDS 312A of instruction layer 120A. If container image 116 is used, execution can be performed for each instruction layer in instruction layer 120. Figure 9 Method 900.

[0097] Specifically, in box 902, for a given instruction layer (e.g., instruction layer 120A), the security management system 112A can generate a first-level cryptographic hash value (FLCHV) corresponding to each object in the corresponding object set (e.g., objects 122A and 122B). The security management system 112A can determine the FLCHV by applying a cryptographic hash function to objects 122A and 122B of instruction layer 120A. For example, the security management system 114A can use cryptographic hash functions such as SHA-1, SHA-2, SHA-3, SHA-256, Whirlpool, BLAKE2, BLAKE3, and / or MD5 to generate the FLCHV. After applying the cryptographic hash function to the objects of the instruction layer, a string (including letters, numbers, symbols, and / or special characters) can be generated, which is referred to as the FLCHV of the object. Formulas 1 and 2 presented below represent example first-level values ​​for objects 122A and 122b.

[0098] FLCHV1=CHF(MyApp1)...Formula (1)

[0099] FLCHV2=CHF(MyApp2)...Formula (2)

[0100] Here, FLCHV1 and FLCHV2 represent the FLCHVs of objects 122A and 122B, respectively, and CHF() is a cryptographic hash function.

[0101] Furthermore, in some examples, at box 904, the security management system 112A can sort the FLCVs sequentially (e.g., ascending or descending). In some examples, the sorting of FLCVs can be optional, and the security management system 112A can execute box 906 directly after executing box 902. At box 906, the security management system 112A can generate a sum of first-level cryptographic hash values ​​(∑FLCHV) after sorting. The example sum of FLCVs for instruction layer 120A can be determined using formula (3).

[0102] ∑(FLCHV_120A)=FLCHV1+FLCHV2...Formula (3)

[0103] Furthermore, at box 908, the security management system 112A can generate a second-level cryptographic hash value (SLCHV) for the instruction layer 120A based on the sum of the FLCHVs. The security management system 112A can apply a cryptographic hash function to the sum of the instruction layer's FLCHVs to generate the instruction layer's SLCHV. In one example, the cryptographic hash function used at box 908 can be the same as the cryptographic hash function used at box 902. In another example, the cryptographic hash function used at box 908 can be different from the cryptographic hash function used at box 902. An example SLCHV for the instruction layer 120A can be determined using formula (4).

[0104] SLCHV_120A=CHF(∑(FLCHV_120A))...Formula (4)

[0105] Furthermore, at box 910, the security management system 112A can sign the SLCHV using a private encryption key. In some examples, the security management system 114A can refer to the security coprocessor chip (e.g., TPM) of the development host system 102 to sign the SLCHV using a private encryption key. The value of the signed SLCHV can be referred to as ILDS. For example, the value of the signed SLCHV of instruction layer 120A could be ILDS 312A.

[0106] Similarly, by executing method 900 on each of the remaining instruction layers, the security management system 112A can generate ILDS 312B, ILDS 312C, ILDS 312D and ILDS 312E.

[0107] Now turn to Figure 10 This presents example methods for validating container images (e.g., container image 116). Figure 1 During the operation of the container ecosystem 100, container image 116 can be downloaded on runtime host system 104 to create and deploy containers using container image 116. The proposed example verification of container image 116 on runtime host system 104 can help prevent the use of container image 116 if it is found to be compromised or tampered with. Specifically, security management system 114B hosted on runtime host system 104 can, by executing... Figure 10 Method 1000 is used to verify container image 116. In some examples, security management system 114A can also be configured to perform verification of container image 116 for any use of container image 116 on development host system 102. For illustrative purposes, method 1000 is described as being performed by security management system 114B.

[0108] At box 1002, the security management system 114B can determine the image identifier of the container image received at the runtime host system 104. The image identifier can be listed as metadata of the container image 116. Therefore, the security management system 114B can analyze the metadata of the container image 116 to determine the image identifier based on the metadata associated with the container image 116. Furthermore, at box 1004, the security management system 114B can obtain the ILDS corresponding to the image identifier and the public encryption key from the signature store 108. For example, for container image 116, the security management system 114B can obtain ILDS 312A to 312E corresponding to the image identifier 313 and the public encryption key 316 from the signature store 108. Furthermore, at box 1006, the security management system 114B can use the public encryption key 316 to decrypt the ILDS to generate a decrypted ILDS (DILDS) corresponding to each ILDS in the ILDS.

[0109] Furthermore, the security management system 114B can verify the ILDS of each instruction layer corresponding to the instruction layer of the downloaded container image 116. For example, at box 1007, the security management system 114B can select the instruction layer of the container image. For the selected instruction layer in the container image, at box 1008, the security management system 114B can generate an object-specific cryptographic hash value (OSCHV) corresponding to each object in the selected instruction layer of the container image downloaded at the runtime host system 104. At box 1008, it can be compared with... Figure 9 The OSCHV is determined in a similar manner to that described in box 902 regarding the generation of FLCCV. The OSCHV can be a cryptographic hash value calculated based on the transient contents of the container image 116 downloaded at runtime host system 104. As will be understood, the OSCHV may differ from the corresponding FLCCV if the container image has been tampered with or corrupted. Example OSCHVs for objects 122A and 122B of the downloaded container images 116 can be represented as OSCHV1 and OSCHV2, respectively.

[0110] Furthermore, at box 1010, the security management system 114B can sort the OSCHVs sequentially. Specifically, it can be done according to... Figure 9 The OSCHVs are sorted in the same order as the FLCCVs in box 904. If the FLCCVs are not sorted in method 900 (i.e., box 904 is not executed), box 1010 can be omitted from method 1000. Furthermore, in box 1012, the security management system 114B can generate the sum of the OSCHVs of the selected instruction layer. An example sum of the OSCHVs of instruction layer 120A can be determined using formula (5).

[0111] ∑(OSCHV_120A)=OSCHV1+OSCHV2...Formula (5)

[0112] After calculating the sum of OSCHVs, at box 1014, the security management system 114B can generate a verification cryptographic hash value (VCHV) based on the sum of OSCHVs. Example SLCHV for instruction layer 120A can be determined using formula (6).

[0113] VCHV_120A=CHF(∑(OSCHV_120B))...Formula (6)

[0114] At box 1016, the security management system 114B can perform a check to determine whether the VCHV of the selected instruction layer matches the corresponding DILDS determined at box 1006 by comparing the VCHV with the corresponding DILDS. For example, for instruction layer 120A, the security management system 114B can compare VCHV_120A with the corresponding DILDS (i.e., the decrypted value of ILDS 312B) to determine whether VCHV_120A is the same as the corresponding DILDS. At box 1016, if it is determined that the VCHV of the selected instruction layer matches the corresponding DILDS, then at box 1018, the security management system 114B can perform another check to determine whether all instruction layers have been verified. If there are still remaining instruction layers to be verified ("No" at box 1018), then at box 1018, the security management system 114B can select one of the remaining instruction layers for verification, and control can move back to box 1008. However, at box 1018, if it is determined that all instruction layers of the downloaded container image have been verified ("Yes" at box 1018), then at box 1020, the security management system 114B can determine that the container image downloaded at the runtime host system 104 is real / genuine. Therefore, at box 1022, the security management system 114B can allow the lifecycle actions and / or use of advance for the downloaded container image 116.

[0115] Returning to box 1014, if it is determined that the VCHV of a given instruction layer does not match the corresponding DILDS, then in box 1024, the security management system 114B can determine that the container image downloaded at the runtime host system 104 is not real / genuine. Therefore, in box 1026, the security management system 114B can terminate the lifecycle actions and / or use of the downloaded container image 116.

[0116] As will be understood, the security management system 114A protects container images at the instruction level. Specifically, the ILDS 312A to 312E of container image 116 are stored together with the corresponding ILIDs 314A to 314E in the signature store 108. Therefore, not only is the use of compromised container images prevented, but tampered instruction levels can also be identified. This can potentially facilitate easier and faster debugging of compromised container images.

[0117] Protect executable applications

[0118] In the following description, combined with Figures 11 to 13 The method describes example operations for protecting container images. For ease of explanation, it will be combined with... Figures 1 to 4 describe Figures 11 to 13 The method. Specifically, Figures 11 to 13 The method describes how to prevent further execution of containers containing any compromised executable applications. In addition to container images (as described above), the purpose of verifying executable applications is to effectively detect and prevent the execution of tampered executable applications.

[0119] Now for reference Figure 11 The flowchart presents an example method 1100 for protecting an executable application in a container image (e.g., container image 116).

[0120] At box 1102, security management system 114A can obtain container image 116. Security management system 114A can retrieve container image 116 from local storage on development host system 102. As previously described, container image 116 may include multiple instruction layers (e.g., instruction layer 120, see...). Figure 2 One or more of these can reference one or more executable applications. For example, instruction layers 120A, 120B, and 120C of container image 116 reference executable applications "MyApp1" and "MyApp2", such as... Figure 2 As shown. For illustrative purposes, method 1100 is described with reference to the executable application "MyApp1" referenced in the instruction layer 120A of the protected container image 116. A similar process can be applied to the executable application "MyApp2" referenced in the protected instruction layer 120A.

[0121] At box 1104, the security management system 114A can generate EAPPDS based on the cryptographic hash of the executable application. For example, to generate EAPPDS 318A corresponding to the executable application "MyApp1", the security management system 114A can apply a cryptographic hash function to the executable application "MyApp1". Similarly, the security management system 114A can also generate EAPPDS 318B corresponding to the executable application "MyApp2". Combined with... Figure 12Additional details regarding the generation of EAPPDS 318A and 318B are described.

[0122] After generating EAPPDS 318A and 318B, at box 1106, security management system 114A can send EAPPDS 318A and 318B to a runtime host system, such as runtime host system 104. In some examples, to send EAPPDS 318A and 318B, security management system 114A can store EAPPDS 318A and 318B in a signature store 108 (see [link to documentation]). Figure 3 In one example, EAPPDS 318A and 318B may be stored in the signature store 108 along with the corresponding container image identifier (e.g., image identifier 313), storage path (e.g., path 322A and 322B), and public encryption key (e.g., public encryption key 324) corresponding to the private encryption key used to create EAPPDS 318A and 318B.

[0123] Furthermore, at box 1108, after generating EAPPDS 318A and 318B, the security management system 114A can store the container image 116 in the container image repository 106.

[0124] Now for reference Figure 12 This presents a flowchart of an example method 1200 for generating EAPPDS (e.g., EAPPDS 318A). For illustrative purposes, method 1100 is described with reference to the executable application "MyApp1" referenced in the instruction layer 120A of container image 116 (see [link to documentation]). Figure 2 ). Specifically, Figure 12 Method 1200 describes in Figure 11 Multiple operations are performed at box 1104. Method 1200 can be performed for each executable application that needs to be protected by the security policy (see Table-1).

[0125] At box 1202, the security management system 114A application can generate a cryptographic hash value corresponding to the executable application. Specifically, the security management system 114A can select an executable application (i.e., the .exe file of the executable application) and apply a cryptographic hash function to the selected executable application. For example, the security management system 114A can use cryptographic hash functions such as SHA-1, SHA-2, SHA-3, SHA-256, Whirlpool, BLAKE2, BLAKE3, and / or MD5 to generate a cryptographic hash value. After applying the cryptographic hash function to the executable application, a character set, string (including letters, numbers, symbols, and / or special characters), can be generated, which is referred to as the cryptographic hash value of the executable application. Therefore, by applying the cryptographic hash function to the executable application "MyApp1", a cryptographic hash value for the executable application "MyApp1" can be generated.

[0126] Furthermore, at box 1204, the security management system 114A can use a private encryption key to sign the cryptographic hash value of the executable application to generate a signed cryptographic hash value for the executable application. The private encryption key can be a private encryption key associated with the development host system 102. The signed cryptographic hash value of the executable application "MyApp1" is an EAPPDS 318A. The security management system 114A can reference the security coprocessor chip of the development host system 102 to sign the cryptographic hash value generated at box 1204.

[0127] Now turn to Figure 13 This paper presents an example method 1300 for verifying executable applications. For illustrative purposes, method 1300 is described with reference to the verification of executable application "MyApp1". Method 1300 can be executed for each executable application that needs to be protected by the security policy (see Table-1).

[0128] exist Figure 1 During the operation of the container ecosystem 100, for example, a container management system 112B hosted on a runtime host system 104 may create and / or run one or more containers created using container image 116. The executable application referenced in container image 116 may have been tampered with. By executing method 1300, the security management system 114B can determine whether an application has been tampered with and prevent the execution of any such compromised application. Therefore, workloads running via such containers and the runtime host system can be protected. Specifically, the security management system 114B can verify the executable application in a container (e.g., container 118) by executing method 1300. Method 1300 can be executed when container 118 is created and / or before any lifecycle operations are performed on container 118.

[0129] As previously described, when an application executes on a computing system, it requests hardware resources (e.g., RAM, input / output devices, etc.) for use by the kernel of the operating system running on the computing system. For example, when container 118 attempts to run an executable application (e.g., MyApp1), the executable application may issue a kernel call. According to the example presented herein, at box 1302, security management system 114B can intercept kernel calls, including those issued by the executable application. Furthermore, at box 1304, security management system 114B can determine the application identifier of the executable application based on the kernel call. Specifically, for a kernel call issued by the executable application "MyApp1", security management system 114B can determine that the APPID is APPID 320A based on the source data in the kernel call. Additionally, at box 1306, security management system 114B can obtain the EAPPDS and public encryption key corresponding to the executable application based on the application identifier. For example, for APPID 320A, the security management system 114B can obtain EAPPDS 318A and public encryption key 314 by performing a lookup in the signature store 108, wherein the private encryption key corresponding to the public encryption key 314 is used to create EAPPDS 318A.

[0130] In the following description, methods for determining whether an executable application is genuine or tampered with are described with the aid of boxes 1308, 1310, 1312, and 1314. Specifically, at box 1308, the security management system 114B can use the public encryption key 324 to decrypt EAPPDS (e.g., EAPPDS 318A) to generate a decrypted executable application digital signature (DEAPPDS) corresponding to the executable application “MyApp1”.

[0131] Furthermore, at box 1310, the security management system 114B can obtain the executable application. Specifically, the security management system 114B can identify the storage path of the executable application by performing a search using the APPID in the signature store 108. For example, path 322A can be identified for APPID 320A. The security management system 114B can retrieve the executable application "MyApp1" from path 322A.

[0132] Furthermore, in box 1312, the security management system 114B can generate a verification cryptographic hash value corresponding to the executable application (VCHVAPP). Specifically, to generate the VCHVAPP, the security management system 114B can apply a cryptographic hash function to the retrieved executable application. For example, the security management system 114B can use cryptographic hash functions such as SHA-1, SHA-2, SHA-3, SHA-256, Whirlpool, BLAKE2, BLAKE3, and / or MD5 to generate the VCHVAPP. After applying the cryptographic hash function to the retrieved executable application, a character set, string (including letters, numbers, symbols, and / or special characters), can be generated, which is referred to as the VCHVAPP of the executable application. Therefore, by applying the cryptographic hash function to the executable application "MyApp1", the VCHVAPP_MyApp1 of the executable application "MyApp1" can be generated.

[0133] Furthermore, at box 1314, the security management system 114B can perform a check to determine whether a VCHVAPP matches a corresponding DEAPPDS by comparing the VCHVAPP of a given executable application with the corresponding DEAPPDS determined in box 1308. For example, for the executable application "MyApp1", the security management system 114B can compare VCHVAPP_MyApp1 with the corresponding DEAPPDS (i.e., the decrypted value of EAPPDS 318A) to determine whether VCHVAPP_MyApp1 is the same as the corresponding DEAPPDS.

[0134] At box 1314, if it is determined that the VCHVAPP of the executable application matches the corresponding DEAPPDS, then at box 1316, the security management system 114B can determine that the executable application is authentic. Furthermore, at box 1318, the security management system 114B can allow the execution of the executable application. However, at box 1314, if it is determined that the VCHVAPP of the executable application does not match the corresponding DEAPPDS, then at box 1320, the security management system 114B can determine that the executable application is compromised or is not authentic. Furthermore, at box 1322, the security management system 114B can terminate the execution of the executable application and the container 118 containing the executable application. For example, for the executable application "MyApp1", based on the match between CHVAPP_MyApp1 and the corresponding DEAPPDS, the security management system 114B can allow or terminate the execution of the executable application "MyApp1" and the container 118. Specifically, if any executable application referenced in container 118 / container image 116 is identified as compromised, the security management system 114B can terminate the execution of container 118.

[0135] In some cases, during the operation of a container (e.g., container 118), the container management application 112B may dynamically (e.g., while container 118 is running) create one or more additional instruction layers within container 118 in response to any changes made to the executable application after container 118 has been created. Such additional layers included in container 118 are hereinafter referred to as read-write (R / W) layers, and the executable application updated after container 118 has been created is referred to as a runtime executable application. The runtime executable application can be referenced as a new, separate executable application within the R / W layer. In the following description, in conjunction with... Figure 14 Example operations for protecting runtime executable applications are described.

[0136] Now for reference Figure 14 The document presents a flowchart of an example method 1400 for protecting a runtime executable application referenced in the R / W layer of container 118. In some examples, after creating the R / W layer with the runtime executable application, at box 1402, the security management system 114B can generate a runtime digital signature (RDS) corresponding to the runtime executable application referenced in the R / W layer. To generate the RDS of the runtime executable application, the security management system 114B can perform actions similar to... Figure 12 Example method 1200. For example, security management system 114B can generate a cryptographic hash value corresponding to a runtime executable application by applying a cryptographic hash function. Security management system 114B can then (e.g., via a security coprocessor of runtime host system 104) sign the cryptographic hash value of the runtime executable application using a private cryptographic key to generate a signed cryptographic hash value for the executable application. The signed cryptographic hash value of the runtime executable application is an RDS. Once generated, at box 1404, security management system 114B can store the RDS in a signature store 108 or locally on runtime host system 104.

[0137] Furthermore, when the runtime executable application is executed, at box 1406, the security management system 114B can use RDS to perform checks to verify the runtime executable application. In some examples, the security management system 114B can perform verification of the executable application. Figure 13The operations described in [the document] are as follows. In box 1406, if the runtime executable application is successfully verified ("Yes" at box 1406), then in box 1408, the security management system 114B may allow the execution of the runtime executable application and container 118. However, in box 1406, if the verification of the runtime executable application fails ("No" at box 1406), then in box 1410, the security management system 114B may terminate the execution of the runtime executable application and container 118. Specifically, if any runtime executable application referenced in container 118 is identified as compromised (i.e., verification failed at box 1406), the security management system 114B may terminate the execution of container 118.

[0138] The terminology used herein is for the purpose of describing specific instances and is not intended to be restrictive. 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. The term “another” as used herein is defined as at least a second or more. Unless otherwise stated, the term “coupled” as used herein is defined as a connection, whether directly without any intervening element or indirectly connected to at least one intervening element. For example, two elements may be coupled mechanically, electrically, or communicatively through a communication channel, path, network, or system. Furthermore, the term “and / or” as used herein refers to and covers any and all possible combinations of the associated listed items. It should also be understood that although the terms first, second, third, etc., may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another, unless otherwise stated or indicated by the context. The term “based on” means at least partially based on.

[0139] While some implementations have been shown and described above, various changes in form and detail are possible. For example, some features and / or functions described with respect to one implementation and / or process may be relevant to other implementations. In other words, processes, features, components, and / or attributes described with respect to one implementation may be used in other implementations. Furthermore, it should be understood that the systems and methods described herein may include various combinations and / or sub-combinations of components and / or features from the different implementations described.

[0140] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may lack some or all of these details. Other implementations may include modifications, combinations, and variations of the foregoing details. Such modifications and variations are intended to be covered by the following claims.

Claims

1. A method comprising: Obtain a container image, the container image including a reference to an executable application, and the executable application being in the instruction layer of the container image; Generate a digital signature for the executable application based on the cryptographic hash of the executable application; The executable application's digital signature is transmitted to the runtime host system to verify the authenticity of the executable application during the execution of the container, which is created on the runtime host system using the container image. The instruction layer digital signature is transmitted to the runtime host system to verify the authenticity of the container image, wherein the instruction layer digital signature is generated based on a second-level cryptographic hash value, and the second-level cryptographic hash value is generated based on a first-level cryptographic hash value of the object set in the instruction layer. and The executable application is an object in the instruction layer.

2. The method according to claim 1, further comprising: After the executable application digital signature is generated, the container image is stored in the container image repository.

3. The method according to claim 1, further comprising: The executable application digital signature is stored in the signature store along with one or more of the following: container image identifier, storage path of the executable application, public encryption key corresponding to private encryption key, and application identifier of the executable application.

4. The method of claim 3, wherein the signature repository is accessible by the runtime host system, and wherein transferring the executable application digital signature comprises: The executable application digital signature is transferred from the signature store to the runtime host system.

5. The method of claim 4, further comprising verifying the authenticity of the executable application, wherein verifying the authenticity of the executable application further comprises: Intercept kernel calls issued by the executable application; The application identifier of the executable application is determined based on the kernel call; The executable application's digital signature and the corresponding public encryption key are obtained from the signature store based on the application identifier. as well as The executable application digital signature is decrypted using the public encryption key to generate a decrypted executable application digital signature.

6. The method of claim 5, wherein verifying the authenticity of the executable application further comprises: The executable application is obtained from the storage path; Generate a verification cryptographic hash value corresponding to the executable application; as well as The verification cryptographic hash value is compared with the corresponding decrypted executable application digital signature.

7. The method according to claim 6, further comprising: If the verification cryptographic hash value matches the decrypted executable application digital signature, then it is determined whether the executable application is authentic. In response to determining that the executable application is real, the execution of the container is permitted; as well as In response to determining that the executable application is not authentic, the execution of the container is terminated.

8. The method of claim 1, wherein the container includes a read-write layer dynamically created during the execution of the container, and wherein the method further comprises: Generate a runtime digital signature corresponding to the runtime executable application associated with the read / write layer of the container; as well as The runtime digital signature is stored together with the container identifier of the container created using the container image on a signature store.

9. The method according to claim 8, further comprising: The runtime digital signature is used to verify the authenticity of the runtime executable application.

10. The method of claim 1, wherein generating the executable application digital signature comprises: Generate a cryptographic hash value corresponding to the executable application; as well as The encrypted hash value is signed using a private encryption key.

11. A security management system, comprising: Machine-readable storage medium that stores executable instructions; A processing resource coupled to the machine-readable storage medium, wherein the processing resource is configured to execute one or more of the instructions to: Obtain a container image, the container image including a reference to an executable application, and the executable application being in the instruction layer of the container image; Generate a digital signature for the executable application based on the cryptographic hash of the executable application; The executable application's digital signature is transmitted to the runtime host system to verify the authenticity of the executable application during the execution of the container, which is created on the runtime host system using the container image. The instruction layer digital signature is transmitted to the runtime host system to verify the authenticity of the container image, wherein the instruction layer digital signature is generated based on a second-level cryptographic hash value, and the second-level cryptographic hash value is generated based on a first-level cryptographic hash value of the object set in the instruction layer. and The executable application is an object in the instruction layer.

12. The security management system of claim 11, wherein the processing resource is configured to execute one or more of the instructions to: store the container image in a container image repository after the executable application digital signature is generated.

13. The security management system of claim 11, wherein the processing resource is configured to execute one or more of the instructions to: store the digital signature of the executable application in a signature store along with one or more of the following: a container image identifier, a storage path of the executable application, a public encryption key corresponding to a private encryption key, and an application identifier of the executable application.

14. The security management system of claim 13, wherein the signature store is accessible by the runtime host system, and wherein the executable application digital signature is transferred from the signature store to the runtime host system.

15. The security management system of claim 11, wherein, in order to generate the digital signature of the executable application, the processing resource is configured to execute one or more of the instructions to: Generate a cryptographic hash value corresponding to the executable application; and The encrypted hash value is signed using a private encryption key.

Images