Patent Description:
The use of "container" technology has gained traction in cloud computing environments, in large part because containers have many of the benefits of virtual machines, such as reduced physical infrastructure costs and better scalability and flexibility, without operating system multiplication and correspondingly higher resource overhead associated with virtual machines. This specification uses the term "container" to describe an aspect of the technology herein, however it will be appreciated that other terms for containers are known in the industry. For example, containers are sometimes referred to as Open Container Initiative (OCI) containers, Kubernetes containers, Windows Server Containers, Hyper-V containers, Intel Clear Containers or Kata containers. Container technologies generally allow portable containers to run on one or more virtual machines or other operating systems. The containers are isolated and so cannot interfere with each other, and cannot access each other's resources without permission. The term "container" as used herein is not limited to any particular type of container.

This specification uses the term "container engine" to describe another aspect of the technology herein, however it will be appreciated that other terms for container engines are known in the industry. Container engines generally provide runtime environments for containers which isolate the containers. "Dockers" are an example widely used container engine. Container engines can generally include, inter alia, a container daemon which provides an Application Programming Interface (API) and other features for use by containers. Container engines can furthermore include execution logic responsible for starting, stopping, pausing, unpausing, and deleting containers. The term "container engine" as used herein is not limited to any particular type of container engine.

Containers are generally transmitted and stored as "container images," which can be stored in local or networked container registries. Container images can be tagged with any desired information. In some cases, a container image can be identified by its <NUM>-bit hash.

In some instances, containers can cooperate in a "swarm" of multiple cooperating containers. A swarm is a group of multiple cooperating containers. The swarm can include containers at each of a group of nodes collaborating over a network. A service can run on a swarm rather than a single container. Each swarm has managers that dispatch tasks to workers, and the managers can also serve as workers. The managers can select a leader which assigns tasks and re-assigns failed worker's tasks. Managers other than the leader can stand ready to elect a new leader if the previously selected leader fails. Using a swarm, services which employ containers can be scaled up and down as needed.

Containers employ a variety of security features. In general, container technologies provide container isolation so containers cannot interfere with each other, and cannot access each other's resources without permission. Furthermore, container images, or portions thereof, can be encrypted to protect container code and data while the container image is in storage in registries, or while the container image is being transmitted. However, once container images are downloaded to hosts with encryption keys, all container image content can be decrypted in plaintext and is susceptible to horizontal attacks and snooping of rogue administrators, that is, the root users of operating systems that run containers. Aspects of this disclosure provide security hardening measures which protect against such administrative access, thereby improving security of containers.

Containers are often hosted on servers in cloud computing environments. It is to be understood that although this disclosure includes a detailed description of cloud computing embodiments, implementation of the teachings recited herein are not limited to cloud computing environments. Rather, embodiments of the present disclosure are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

Therefore, there is a need in the art to address the aforementioned problem.

<CIT> discloses a hardware TPM, which enures a secure boot sequence up to a container runtime, before a virtual TPM is instantiated in each container and measures integrity of the containerized components. All container memory is encrypted with multi-key total memory encryption (MKTME).

In one or more embodiments described herein, systems, computer-implemented methods, apparatus and/or computer program products that facilitate security hardening of containers are described.

Viewed from a first aspect, the present invention provides a system for managing container security, comprising: a memory that stores computer executable components; a processor that executes computer executable components stored in the memory, wherein the computer executable components comprise: a boot component that performs at least a portion of a trusted boot sequence to securely boot the system to a defined secure state wherein one or more types of administrative access to a container memory are deactivated; a core service component started as a part of the trusted boot sequence and that securely obtains one or more decryption keys for use with the container memory, wherein the core service component securely obtains the one or more decryption keys using a Trusted Processing Module (TPM) remote attestation to a trusted third party service device; and a runtime decryption component that uses the one or more decryption keys to perform runtime decryption of one or more files accessed by an entrypoint process of a container associated with the container memory or a descendant of the entrypoint process.

Viewed from a further aspect, the present invention provides computer-implemented method for managing container security, the method comprising: performing, by a boot component operatively coupled to a processor, at least a portion of a trusted boot sequence to securely boot a computing system to a defined secure state wherein one or more types of administrative access to a container memory are deactivated; starting, by the boot component, as part of the trusted boot sequence, a core service component operatively coupled to the processor; securely obtaining, by the core service component, one or more decryption keys for use with the container memory, wherein the securely obtaining the one or more decryption keys employs Trusted Processing Module (TPM) remote attestation to a trusted third party service device; and using, by a runtime decryption component operatively coupled to the processor, the one or more decryption keys to perform runtime decryption of one or more files accessed by a container associated with the container memory.

According to an embodiment, a system can comprise a memory that stores computer executable components; and a processor that executes computer executable components stored in the memory. The computer executable components can comprise a boot component that performs at least a portion of a trusted boot sequence to securely boot the system to a defined secure state wherein one or more types of administrative access to a container memory are deactivated. A core service component started as a part of the trusted boot sequence can securely obtain one or more decryption keys for use with the container memory. A runtime decryption component can use the one or more decryption keys to perform runtime decryption of one or more files accessed by a container associated with the container memory.

According to an embodiment, a computer-implemented method can comprise performing, by a boot component operatively coupled to a processor, at least a portion of a trusted boot sequence to securely boot a computing system to a defined secure state wherein one or more types of administrative access to a container memory are deactivated. The boot component can start, as part of the trusted boot sequence, a core service component operatively coupled to the processor. The computer-implemented method can also comprise securely obtaining, by the core service component, one or more decryption keys for use with the container memory, and using, by a runtime decryption component operatively coupled to the processor, the one or more decryption keys to perform runtime decryption of one or more files accessed by a container associated with the container memory.

According to another embodiment, a computer program product facilitating container security can comprise a computer readable storage medium having program instructions embodied therewith. The program instructions can be executable by a processing component and cause the processing component to: perform at least a portion of a trusted boot sequence to securely boot a computing system to a defined secure state wherein one or more types of administrative access to a container memory are deactivated; and start, as part of the trusted boot sequence, a core service. The program instructions can also be executable to: securely obtain, by the core service, one or more decryption keys for use with the container memory, and use, by the processing component, the one or more decryption keys to perform runtime decryption of one or more files accessed by a container associated with the container memory.

According to a further embodiment, a computer-implemented method can comprise: instantiating, by a system operatively coupled to a processor, one or more containers by a docker component operatively coupled to a processor; and for at least one of the one or more containers, managing, by the system, one or more file accesses by the at least one of the one or more containers, wherein the runtime decryption component passes through one or more requests to access non-encrypted files, and wherein the runtime decryption component checks process identifiers (PIDs) of one or more processes requesting access to encrypted files to ensure the PIDs belong to an entrypoint process of the at least one of the one or more containers or a descendant process of the entrypoint process.

According to yet another embodiment, a computer-implemented method can comprise performing, by a boot component operatively coupled to a processor, at least a portion of a trusted boot sequence to securely boot a computing system, wherein the trusted boot sequence comprises: resetting one or more Trusted Processing Module (TPM) Platform Configuration Registers (PCRs), and running a series of boot components, wherein each boot component in the series measures a next boot component in the series and stores a corresponding PCR value. At least one of the boot components in the series of boot components can comprise a core service component. The computer-implemented method can also comprise performing, by the core service component operatively coupled to the processor, a TPM remote attestation to a trusted third party service device, and securely obtaining, by the core service component, one or more decryption keys for a container from the trusted third party service device, and storing the one or more decryption keys for the container in a container memory associated with the container.

The present invention will now be described, by way of example only, with reference to preferred embodiments, as illustrated in the following figures:.

One or more embodiments are now described with reference to the drawings, wherein like referenced numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth to provide a more thorough understanding of the one or more embodiments. It is evident, however, in various cases, that the one or more embodiments can be practiced without these specific details.

This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

As shown, cloud computing environment <NUM> includes one or more cloud computing nodes <NUM> with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone 54A, desktop computer 54B, laptop computer 54C, and/or automobile computer system 54N can communicate. Cloud computing nodes <NUM> can communicate with one another. They can be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof.

Virtualization layer <NUM> provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers <NUM>; virtual storage <NUM>; virtual networks <NUM>, including virtual private networks; virtual applications and operating systems <NUM>; and virtual clients <NUM>.

In one example, management layer <NUM> can provide the functions <NUM>-<NUM> described below. Functions <NUM>-<NUM> can include, for example, resource provisioning which provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing can provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. A user portal can provide access to the cloud computing environment for consumers and system administrators. Service level management can provide cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment can provide prearrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA. Furthermore, function <NUM> can provide a container engine which manages containers that execute in the workload layer <NUM>.

Workload layer <NUM> provides examples of functionality for which the cloud computing environment can be utilized. Examples of workloads and functions which can be provided from this layer include: mapping and navigation <NUM>; software development and lifecycle management <NUM>; virtual classroom education delivery <NUM>; data analytics processing <NUM>; transaction processing <NUM>; and containers <NUM>. Workload layer <NUM> can optionally host many containers <NUM>, which can be managed by the container engine provided by function <NUM>. Each container of containers <NUM> can include container code and data.

<FIG> illustrates a block diagram of an example, non-limiting computing environment in accordance with one or more embodiments described herein. Various aspects of the computing environment are hardware components while other aspects are software components. With reference to <FIG>, a suitable operating environment <NUM> for implementing various aspects of this disclosure can include a computer <NUM>. Computer <NUM> can comprise, e.g. a cloud computing node such as one of the cloud computing nodes <NUM> illustrated in <FIG>. As such, computer <NUM> can participate in the cloud computing environment <NUM> illustrated in <FIG>. In other embodiments, the computer <NUM> can implement aspects of this disclosure without participating in the cloud computing environment illustrated in <FIG> and <FIG>, as will be appreciated.

The computer <NUM> can include a processing unit <NUM>, a system memory <NUM>, and a system bus <NUM>. The system bus <NUM> couples system components, including but not limited to the system memory <NUM>, to the processing unit <NUM>. The processing unit <NUM> can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit <NUM>. The system bus <NUM> can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Firewire (IEEE <NUM>), and Small Computer Systems Interface (SCSI).

The system memory <NUM> can also include volatile memory <NUM> and nonvolatile memory <NUM>. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer <NUM>, such as during start-up, is stored in nonvolatile memory <NUM>. By way of illustration, and not limitation, nonvolatile memory <NUM> can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, or nonvolatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM). Volatile memory <NUM> can also include random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM.

Computer <NUM> can also include removable/non-removable, volatile/non-volatile computer storage media. <FIG> illustrates, for example, a disk storage <NUM>. Disk storage <NUM> can also include, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-<NUM> drive, flash memory card, or memory stick. The disk storage <NUM> also can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage <NUM> to the system bus <NUM>, a removable or non-removable interface is typically used, such as interface <NUM>.

In some embodiments, encrypted container images <NUM> can be retrieved by computer <NUM> from container registry <NUM> and stored in disk storage <NUM>. Because the encrypted container images <NUM> are transferred to computer <NUM>, and stored in disk storage <NUM> in encrypted format, there is little risk of a rogue administrator of computer <NUM> accessing the content of encrypted container images <NUM>. It should also be noted that encrypted container images <NUM> can be stored in the system memory <NUM> instead of, or in addition to, being stored in disk storage <NUM>.

<FIG> also depicts software that acts as an intermediary between users, applications, and containers, on one hand, and the computer <NUM> resources on the other. Such software can include, for example, an operating system <NUM>. Operating system <NUM>, which can be stored on disk storage <NUM>, acts to control and allocate resources of the computer <NUM>. In some embodiments, operating system <NUM> can be a virtual machine (VM), and the computer <NUM> can host multiple VMs. It is to be appreciated that this disclosure can be implemented with various operating systems or combinations of operating systems.

One or more boot components, such as boot component <NUM>, can be involved in booting the operating system <NUM>. Boot component <NUM> can interact with a Trusted Processing Module (TPM) <NUM> to securely boot the operating system <NUM>. In general, the TPM <NUM> securely stores hashes of trusted boot components in platform configuration registers (PCRs) <NUM>. Each boot component performs a hash of a next boot component in a trusted boot sequence, and uses TPM <NUM> to check the measured hash against the corresponding hash in PCRs <NUM>. A next boot component in a trusted boot sequence is loaded only if its hash is correct, thereby ensuring the boot component is trusted, and resulting in the computer <NUM> booting to a verifiably secure state.

A boot component <NUM> can place requirements on the secure state of computer <NUM>. For example, a boot component <NUM> can restrict or block certain operating system <NUM> functions. As will be described further herein, boot component <NUM> can, for example, deactivate one or more types of administrative access to a container memory, e.g., a portion of system memory <NUM> reserved for a container such as container <NUM>.

Furthermore, boot component <NUM> can ensure that a trusted core service component <NUM> is loaded as part of a trusted boot sequence. Core service component <NUM> can be responsible for securely obtaining decryption keys to decrypt encrypted container images <NUM>, or portions thereof. Core service component <NUM> can make use of TPM <NUM>, introduced above, to securely obtain decryption keys. Core service component <NUM> can employ a TPM <NUM> remote attestation to trusted third party service device <NUM>, to obtain decryption keys.

System applications <NUM> can take advantage of the management of resources by operating system <NUM> through program modules <NUM> and program data <NUM>, e.g., stored either in system memory <NUM> or on disk storage <NUM>. Similarly, container engine <NUM> can run on operating system <NUM>. Container engine <NUM> can, for example, load, start and/or stop containers such as <NUM>, <NUM> and <NUM>. Container engine <NUM> can isolate containers <NUM>, <NUM> and <NUM> so containers <NUM>, <NUM> and <NUM> cannot interfere with one another or access each other's data. As described further herein, container engine <NUM> can optionally provide further container security with runtime decryption component (RDC) <NUM>, which can manage encrypted file accesses by container <NUM>. Runtime decryption component <NUM> can make use of the decryption keys securely obtained by trusted core service component <NUM>.

Embodiments of this disclosure can prevent unwanted administrator snooping on container <NUM> code and data at least in part through the combination of (<NUM>) boot component <NUM> enforcing a defined state of computer <NUM> wherein certain types of administrative memory access are deactivated, (<NUM>) core service component <NUM> securely obtaining decryption keys for container <NUM> file accesses, and (<NUM>) runtime decryption component <NUM> making use of the decryption keys on behalf of container <NUM>. In some embodiments, the boot component <NUM>, core service component <NUM> and/or runtime decryption component <NUM> can be hardware components that can be added to the computer <NUM> and that have individual memory and/or processor components. In other embodiments, the boot component <NUM>, core service component <NUM> and/or runtime decryption component <NUM> may be able to a computer code designed with instructions to perform one or more different operations to facilitate performance of the trusted boot sequence. As a result of these measures, administrators of computer <NUM> cannot access unencrypted container <NUM> code and data in system memory <NUM>, and administrators of computer <NUM> cannot obtain the decryption keys to decrypt container <NUM> code and data.

In some instances, a user can enter commands or information into the computer <NUM> through input device(s) <NUM>. In other embodiments, any entity can enter commands or information into the computer <NUM>. The entities can include, but are not limited to, robots, artificial intelligence devices, computers or the like.

Input devices <NUM> include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit <NUM> through the system bus <NUM> via interface port(s) <NUM>. Interface port(s) <NUM> include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) <NUM> use some of the same type of ports as input device(s) <NUM>. Thus, for example, a USB port can be used to provide input to computer <NUM>, and to output information from computer <NUM> to an output device <NUM>. Output adapter <NUM> is provided to illustrate that there are some output devices <NUM> like monitors, speakers, and printers, among other output devices <NUM>, which require special adapters. The output adapters <NUM> include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device <NUM> and the system bus <NUM>. It should be noted that other devices and/or systems of devices provide both input and output capabilities.

Computer <NUM> can operate in a networked environment using logical connections to one or more remote computers, such container registry <NUM> and trusted third party service device <NUM>. The container registry <NUM> can include a server from which encrypted container images <NUM> are obtained. The trusted third party service device <NUM> can include a server from which decryption keys for encrypted container images <NUM> are obtained, e.g., by core service component <NUM> in conjunction with TPM <NUM>. Other remote computer(s) with which computer <NUM> can communicate include computers, servers, routers, network PCs, workstations, microprocessor based appliances, peer devices or other common network nodes and the like, and typically can also include many or all of the elements described relative to computer <NUM>.

Remote computer(s) such as <NUM> and <NUM> can be logically connected to computer <NUM> through a network interface <NUM> and then physically connected via communication connection <NUM>. Network interface <NUM> encompasses wire and/or wireless communication networks such as local-area networks (LAN), wide-area networks (WAN), cellular networks, etc. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL). Communication connection(s) <NUM> refers to the hardware/software employed to connect the network interface <NUM> to the system bus <NUM>. While communication connection <NUM> is shown for illustrative clarity inside computer <NUM>, it can also be external to computer <NUM>. The hardware/software for connection to the network interface <NUM> can also include, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

<FIG> illustrate block diagrams of an example, non-limiting systems that retrieve, store and run containers in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

<FIG> illustrates a weakly secured host machine <NUM>, which stands in contrast with the security hardened host machine <NUM> illustrated in <FIG>. In both <FIG>, the respective host machines <NUM>, <NUM>, can retrieve an encrypted container image <NUM> from a registry <NUM>. Registry <NUM> includes multiple encrypted container images <NUM>, <NUM>, <NUM>, and <NUM>.

Host machine <NUM> and registry <NUM> can provide, for example, cloud computing nodes among the cloud computing nodes <NUM> illustrated in <FIG>. Host machine <NUM> can be a server equipped to host containers without, for example, security features such as boot component <NUM>, core service component <NUM>, and runtime decryption component <NUM> illustrated in <FIG>. As such, host machine <NUM> can retrieve encrypted container image <NUM> securely from registry <NUM>. Key acquisition component <NUM> can furthermore acquire decryption keys to decrypt encrypted container image <NUM>.

Once the encrypted container image <NUM> is decrypted and loaded into system memory <NUM> as decrypted container image 401A, the code and data in the decrypted container image 401A may be no longer effectively protected. The code, data, and configuration a developer puts into encrypted container image <NUM> are exposed for administrators of host machine <NUM> to see, in plain sight or with a small amount of work. Indeed, in some instances, decrypted container image 401A can be stored as plaintext at host machine <NUM>.

Furthermore, in host machine <NUM>, any of a variety of administrative access functions <NUM> can be used to access decrypted container image 401A within system memory <NUM>. For example, administrative access to the container memory within system memory <NUM> can be accomplished through booting from a modified kernel, for example, in circumstances wherein host machine <NUM> is not booted using a trusted boot sequence. Administrative access to the container memory within system memory <NUM> can also be accomplished through loading additional kernel modules, in addition to kernel modules of a trusted kernel.

In some instances, administrative access to the container memory within system memory <NUM> can also be accomplished through one or more virtual memory management devices, e.g., using /dev/mem, /dev/kmem, and /proc/kcore virtual memory management devices. Administrative access to the container memory within system memory <NUM> can also be accomplished through one or more runtime debugging functions. Runtime debugging functions are generally functions which allow a process to attach to another process, and can, for example allow the root to pause running processes and peek at their memory. Examples of runtime debugging functions include ptrace and extended Berkeley Packet Filter (eBPF).

In some instances, administrative access to the container memory within system memory <NUM> can also be accomplished through pausing a running process to view a memory associated with the running process. Administrative access to the container memory within system memory <NUM> can also be accomplished or through kernel memory swap operations, in which a kernel writes portions of system memory <NUM> to disk to fee up space in system memory. Kernel memory swap can be triggered deliberately by loading excess data into system memory <NUM>.

In summary, while host machine <NUM> can retrieve encrypted container image <NUM> from registry <NUM> securely, the encrypted container image <NUM> may be vulnerable to rogue administrators after it is decrypted at host machine <NUM>. Occasionally encrypted container images such as <NUM> can include any of a wide variety of sensitive information such as proprietary code and algorithms, patient/health data, machine learning (ML) models, etc. As discussed below, host machine <NUM> implements a set of security hardening features which improve the security of encrypted container image <NUM> at host machine <NUM> to protect such sensitive information.

In some embodiments, host machine <NUM> can provide improved security. Like host machine <NUM>, host machine <NUM> can provide, e.g., a cloud computing node among the cloud computing nodes <NUM> illustrated in <FIG>, and host machine <NUM> can comprise a server equipped to host containers. However, in contrast with host machine <NUM>, host machine <NUM> can implement, e.g., the security features such as boot component <NUM>, core service component <NUM>, and runtime decryption component <NUM> illustrated in <FIG>. As such, host machine <NUM> can securely retrieve encrypted container image <NUM> from registry <NUM>, acquire decryption keys to decrypt encrypted container image <NUM>, and decrypt and run the encrypted container image <NUM>.

Boot component <NUM> can execute one or more operations to carry out a part of a trusted boot sequence at host machine <NUM> to securely boot the host machine <NUM> to a defined secure state wherein one or more types of administrative access to a container memory, within system memory <NUM>, are deactivated. In <FIG>, administrative access functions <NUM> are deactivated, and the arrow originating from decrypted container image 401A and facing administrative access functions <NUM> is blocked. In an implementation, system memory <NUM> can be protected from all users, including administrators or root users of host machine <NUM>, by using trusted boot to prevent kernel code, kernel configuration, and core services from tampering. Furthermore, certain kernel options and virtual devices that would allow particular users having a certain set of privileges (e.g., root users, which can have default access to various commands and files in a particular operating system) to peek into system memory <NUM> can be deactivated. Alternatively, secure hardware technologies can be used to secure system memory <NUM>.

Core service component <NUM> can be started as a part of the trusted boot sequence, and can implement the secure key acquisition <NUM> illustrated in <FIG>. Secure key acquisition <NUM> can securely obtain one or more decryption keys for use with the encrypted container image <NUM>, without allowing particular users of host machine <NUM> to access the decryption keys. For example, retrieved decryption keys can be stored in system memory <NUM>, which is protected from administrative access functions <NUM>.

In an example embodiment, core service component <NUM> can be started as a part of the trusted boot sequence using TPM <NUM> and PCRs <NUM>. When decryption keys are needed, core service component <NUM> can perform TPM remote attestation, using TPM <NUM>, to acquire the decryption keys from trusted third party service device <NUM>. If TPM remote attestation succeeds, one or more decryptions keys can be provided to secure key acquisition <NUM> by trusted third party service device <NUM>. The obtained decryption keys can be kept in system memory <NUM>, wherein the trusted boot sequence implemented by boot component <NUM> guarantees root users cannot acquire decryption keys from system memory <NUM>.

When a container is started at host machine <NUM>, e.g., a runtime decryption component <NUM> can use the decryption keys acquired by secure key acquisition <NUM> to decrypt the container image, e.g., to decrypt encrypted container image <NUM>, to thereby load decrypted container image 401A in system memory <NUM>. Runtime decryption component <NUM> can furthermore perform runtime decryption of files accessed by the decrypted container image 401A.

In some embodiments, runtime decryption component <NUM> can be implemented at least in part as a file system intermediary. When a container is started at host machine <NUM>, a file system intermediary can be placed on the root file system of the container, making all file accesses go through the file system intermediary. For non-encrypted files, file accesses can simply pass through the file system intermediary. When an encrypted file is accessed, the process identifier (PID) of the requesting process can be checked. If the PID belongs to the entrypoint process of the container or a descendant process of the entrypoint process, then the file can be decrypted. If the PID of the requesting process does not belong to the entrypoint process or a descendant of the entrypoint process, then decryption can be prevented.

In summary, with regard to <FIG>, host machine <NUM> can secure decrypted code and data of a container through several security hardening measures, which can be employed alone or in combination. The host machine <NUM> is booted to a secure state to ensure that the host machine <NUM> kernel can be trusted, and to deactivate any of a variety of administrative access functions <NUM> that otherwise enable access to system memory <NUM>. The host machine <NUM> can include secure key acquisition <NUM>, such as core service component <NUM>, to securely retrieve and store decryption keys in a location such as in system memory <NUM>, where the decryption keys cannot be accessed by users of host machine <NUM>. The host machine <NUM> can then securely decrypt container data at container runtime.

<FIG> illustrates a block diagram of an example, non-limiting system that employs modified docker technology to secure containers in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

The embodiment shown in <FIG> includes a modified docker-based system and method <NUM> for container runtime operations. Docker component <NUM> is a docker daemon, which provides a container engine. To run a container included in docker signed container image <NUM>, docker component <NUM> can call containerd component <NUM>, which provides a container daemon. As used herein, the term "containerd component" means the container daemon component. Docker component <NUM> also starts a docker advanced multi-layered unification filesystem (AUFS) component <NUM>. In some embodiments, docker signed container image <NUM> can be annotated using, for example, extended file attributes or special file names to indicate that docker signed container image <NUM> is subject to security hardening measures disclosed herein.

Containerd component <NUM> starts a container shim component <NUM>, which provides the runtime environment for an individual container <NUM>. After rootfs is mounted by a container storage driver, containerd component <NUM> can make a remote procedure call (RPC) to blackbox daemon component <NUM>.

In this example, blackbox daemon component <NUM> implements a core service component such as <NUM>, described in connection with <FIG>. Blackbox daemon component <NUM> can be initially started as a part of the trusted boot sequence, for example secured by PCR #<NUM> in PCRs <NUM>. At startup, blackbox daemon component <NUM> can perform TPM remote attestation, and afterwards, blackbox daemon component <NUM> can for example retrieve a list of sealed decryption keys from a trusted third party service device <NUM>. Blackbox daemon component <NUM> can unseal the retrieved decryption keys in memory. Blackbox daemon component <NUM> can call TPM_PCR_Extend PCR #<NUM> upon completion.

At container runtime, in response to the RPC call from containerd component <NUM>, and if the docker signed container image is signed, blackbox daemon component <NUM> can, for example, initiate the entrypoint process, and begin decrypting files on behalf of container <NUM> on an as-needed basis, while storing clear text or otherwise decrypted files only in memory that is protected from users such as root users (or other users with default access to various commands or files in an operating system).

Furthermore, blackbox daemon component <NUM> can start a blackbox filesystem in user space (FUSE) component <NUM>, to start a FUSE process with a decryption key for container <NUM>. Blackbox FUSE component <NUM> provides a runtime decryption component <NUM> in the embodiment of <FIG>. Blackbox FUSE component <NUM> sits above the rootfs of the container <NUM>, that is the docker AUFS component <NUM>, as an intermediary filesystem layer. Blackbox FUSE component <NUM> decrypts encrypted files if the requesting process is the entrypoint process (which in some instances may also be the init process) of the container <NUM> or a descendant process of the entrypoint (or init) process of the container <NUM>. Blackbox FUSE component <NUM> can also retrieve any unencrypted files for the requesting process.

<FIG> illustrates a high-level block diagram of an example, non-limiting boot component in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

Aspects of the boot component <NUM> can constitute machine-executable component(s) embodied within machine(s), e.g., embodied in one or more computer readable mediums (or media) associated with one or more machines. Such component(s), when executed by the one or more machines, e.g., computer(s), computing device(s), virtual machine(s), etc. can cause the machine(s) to perform the operations described. In an aspect, memory <NUM> can store computer executable components and instructions. Furthermore, the processor <NUM> can facilitate operation of the instructions (e.g., computer executable components and instructions) associated with the boot component <NUM>.

As shown in <FIG>, in some embodiments, the boot component <NUM> can include a processor <NUM>, a TPM <NUM>, and a memory <NUM>. In other embodiments, in lieu of having separate processor <NUM>, the boot component <NUM> can access and/or share a processor with one or more of processor <NUM> of core service component <NUM> (<FIG>), processor <NUM> of runtime decryption component <NUM> (<FIG>) and/or processing unit <NUM> (<FIG>). Accordingly, in the embodiment shown, boot component <NUM> is hardware, although boot component <NUM> can be implemented as computer code, or one or more operations of boot component <NUM> can be implemented via computer code, in some embodiments.

TPM <NUM> can include a defined secure state <NUM>, e.g., in a PCR of PCRs <NUM>. Memory <NUM> can include, e.g., a next component <NUM> and optionally a defined secure state <NUM>. In a non-limiting example, the elements of <FIG> are implemented in <FIG>. The boot component <NUM> provides an example of a boot component <NUM> incorporated into the computer <NUM>. Likewise, processor <NUM> can provide a processor <NUM>, memory <NUM> can provide system memory <NUM> or other memory included in computer <NUM>, and TPM <NUM> can provide the TPM <NUM> of <FIG>.

In certain implementations, as indicated by the arrow underneath the boot component <NUM>, the boot component <NUM> can be employed to carry out part of a sequence of operations noted as a trusted boot sequence for a system. The boot component <NUM> can perform at least a portion of the trusted boot sequence, and boot component <NUM> can then cause a next component <NUM> to operate or execute as part of the trusted boot sequence. The result of the trusted boot sequence is that such sequence of operations can securely boot a system to a defined secure state according to defined secure state <NUM>, wherein one or more types of administrative access to a container memory are deactivated.

In a non-limiting example, the boot component <NUM> can check next component <NUM> to ensure that next component <NUM> satisfies defined secure state <NUM>. Defined secure state <NUM> can include a state wherein one or more types of administrative access to container memory are deactivated. That is, after the computer <NUM> is fully booted according to defined secure state <NUM>, certain functions which commonly provide administrative access to particular system sections (e.g., system memory) can be deactivated.

For example, in an embodiment, next component <NUM> can comprise an operating system kernel. Defined secure state <NUM> can comprise a hash of a kernel wherein administrative access functions associated with certain types of administrative memory access are deactivated. Boot component <NUM> can perform a hash of next component <NUM>, or portions thereof, and boot component <NUM> can check that the measured hash matches the hash stored in defined secure state <NUM>. Boot component <NUM> can load next component <NUM> if the hashes match, or stop the trusted boot sequence if the hashes do not match.

TPM <NUM> can securely store the hash of the next component <NUM>, e.g., in a PCR of PCRs <NUM>. Boot component <NUM> can measure a hash of next component <NUM> and pass the hash value to TPM <NUM>. When the hash values match, TPM <NUM> can notify boot component <NUM> that the next component <NUM> can be safely loaded, and boot component <NUM> can load next component <NUM>. When the hashes do not match, TPM <NUM> can notify boot component <NUM> and boot component <NUM> can stop the trusted boot sequence.

In some instances, a core service component such as described in connection with <FIG> can comprise at least one aspect of defined secure state <NUM>. In such cases, the boot component <NUM> can guarantee both deactivated administrative access functions, and the presence of a core service component in the booted system. Boot component <NUM> can perform a hash of a core service component, an operating system kernel, or any other next component <NUM>, or combinations thereof.

Other approaches to specify a defined secure state <NUM> can be implemented in other embodiments. For example, defined secure state <NUM> can comprise a list of administrative access functions to be deactivated in next component <NUM>. Boot component <NUM> can read defined secure state <NUM> from memory <NUM>, and boot component <NUM> can inspect next component <NUM> to ensure the listed administrative access functions are deactivated. If the listed administrative access functions are deactivated, boot component <NUM> can load next component <NUM>. If the listed administrative access functions are not deactivated, boot component <NUM> can stop the trusted boot sequence.

<FIG> illustrates a high-level block diagram of an example, non-limiting core service component in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

Aspects of the core service component <NUM> can constitute machine-executable component(s) embodied within machine(s), e.g., embodied in one or more computer readable mediums (or media) associated with one or more machines. Such component(s), when executed by the one or more machines, e.g., computer(s), computing device(s), virtual machine(s), etc. can cause the machine(s) to perform the operations described. In an aspect, memory <NUM> can store computer executable components and instructions. Furthermore, the processor <NUM> can facilitate operation of the instructions (e.g., computer executable components and instructions) associated with the core service component <NUM>.

As shown in <FIG>, in some embodiments, the core service component <NUM> can include a processor <NUM>, a TPM <NUM>, a memory <NUM>, and a communication component <NUM>. In other embodiments, in lieu of having separate processor <NUM>, the core service component <NUM> can access and/or share a processor with one or more of processor <NUM> of boot component <NUM> (<FIG>), processor <NUM> of runtime decryption component <NUM> (<FIG>) and/or processing unit <NUM> (<FIG>). Accordingly, in the embodiment shown, core service component <NUM> is hardware, although core service component <NUM> can be implemented as computer code, or one or more operations of core service component <NUM> can be implemented via computer code, in some embodiments.

TPM <NUM> can include a sealed secret <NUM>. Memory <NUM> can include, for example, decryption keys <NUM>. Core service component <NUM> can optionally be started as a part of the trusted boot sequence described above with reference to the boot component <NUM>. Core service component <NUM> can securely obtain one or more decryption keys <NUM> for use with container memory. In a non-limiting example, the elements of <FIG> are implemented in <FIG>. The core service component <NUM> is an example of an embodiment of core service component <NUM> of <FIG>.

In some examples, the core service component <NUM> can obtain a package of decryption keys <NUM> at computer <NUM> startup, for use with multiple containers hosted at computer <NUM>. Core service component <NUM> can for example identify multiple container images stored at computer <NUM>, and core service component <NUM> can employ communication component <NUM> and TPM <NUM> to perform a TPM <NUM> remote attestation to trusted third party service device <NUM>. TPM <NUM> can for example provide a sealed secret <NUM> to the trusted third party service device <NUM>. Trusted third party service device <NUM> can authenticate the computer <NUM> using the sealed secret <NUM>. Trusted third party service device <NUM> can then return, for example, a bundle of requested decryption keys to core service component <NUM>. Core service component <NUM> can store the returned decryption keys as decryption keys <NUM> in memory <NUM>. The decryption keys can then be used in connection with decrypting container data for corresponding containers as appropriate.

In some examples, the core service component <NUM> can obtain decryption keys <NUM> for individual containers at container runtime. When a container is loaded at computer <NUM>, core service component <NUM> can employ communication component <NUM> and TPM <NUM> to perform a TPM <NUM> remote attestation to trusted third party service device <NUM>, as described herein. Trusted third party service device <NUM> can then return, for example, the requested decryption key to core service component <NUM>. Core service component <NUM> can store the returned decryption key as a decryption key of decryption keys <NUM> in memory <NUM>. The decryption key can then be used in connection with decrypting container data. Because decryption keys <NUM> are loaded in memory <NUM>, and memory <NUM> is protected from administrator view by the boot component <NUM>, the decryption keys <NUM> remain secure and inaccessible to decrypt container data without authorization.

<FIG> illustrates a high-level block diagram of an example, non-limiting runtime decryption component in accordance with one or more embodiments described herein. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

Aspects of the runtime decryption component <NUM> can constitute machine-executable component(s) embodied within machine(s), e.g., embodied in one or more computer readable mediums (or media) associated with one or more machines. Such component(s), when executed by the one or more machines, e.g., computer(s), computing device(s), virtual machine(s), etc. can cause the machine(s) to perform the operations described. In an aspect, memory <NUM> can store computer executable components and instructions. Furthermore, the processor <NUM> can facilitate operation of the instructions (e.g., computer executable components and instructions) associated with the runtime decryption component <NUM>.

As shown in <FIG>, the runtime decryption component <NUM> can include a processor <NUM>, a check PID component <NUM>, and a memory <NUM>. As shown in <FIG>, in some embodiments, the runtime decryption component <NUM> can include a processor <NUM>, a check PID component <NUM>, and a memory <NUM>. Accordingly, in the embodiment shown, runtime decryption component <NUM> is hardware, although runtime decryption component <NUM> can be implemented as computer code, or one or more operations of runtime decryption component <NUM> can be implemented via computer code, in some embodiments. In other embodiments, in lieu of having separate processor <NUM>, the runtime decryption component <NUM> can access and/or share a processor with one or more of processor <NUM> of boot component <NUM> (<FIG>), processor <NUM> of core service component (<FIG>) and/or processing unit <NUM> (<FIG>).

Memory <NUM> can include, e.g., decryption key <NUM>. Runtime decryption component <NUM> can use decryption key <NUM>, e.g., a decryption key retrieved by core service component <NUM>, to perform runtime decryption of one or more files accessed by a container <NUM> associated with a container memory within system memory <NUM>. In a non-limiting example, the elements of <FIG> are implemented in <FIG>. The runtime decryption component <NUM> can provide an example of a runtime decryption component <NUM> incorporated into the computer <NUM>. Likewise, processor <NUM> can provide a processor <NUM>, memory <NUM> can provide system memory <NUM> or other memory included in computer <NUM>.

In some examples, runtime decryption component <NUM> can receive file requests from a container <NUM>. The file requests can comprise, e.g., encrypted file request <NUM> and non-encrypted file request <NUM>. Encrypted file request <NUM> is a request for an encrypted file, and non-encrypted file request <NUM> is a request for a non-encrypted file. Runtime decryption component <NUM> can handle the requests <NUM>, <NUM> differently, however runtime decryption component <NUM> can ultimately return the requested files, e.g., as return <NUM>, corresponding to encrypted file request <NUM>, and return <NUM>, corresponding to non-encrypted file request <NUM>.

For encrypted file request <NUM>, runtime decryption component <NUM> can employ check PID component <NUM> to check a process identifier (PID) of the requesting process. Check PID component <NUM> can ensure the PID of the requesting process belongs to an entrypoint process of the container <NUM>, or a descendant process of the entrypoint process. If the PID does belong to the entrypoint process or a descendant, the runtime decryption component <NUM> can proceed to retrieve the requested file from filesystem <NUM>, decrypt the requested file using decryption key <NUM>, and return <NUM> the requested file. If the PID is not authorized, then the runtime decryption component <NUM> can throw an error.

For non-encrypted file request <NUM>, in an implementation, runtime decryption component <NUM> can pass through the request <NUM> to filesystem <NUM>. Filesystem <NUM> can return the requested non-encrypted file to runtime decryption component <NUM>, and runtime decryption component <NUM> can return the requested file to the requesting container at return <NUM>.

While <FIG>, and <FIG> depict separate components, namely boot component <NUM>, core service component <NUM> and runtime decryption component <NUM>, respectively, it is to be appreciated that two or more components can be implemented in a common component. Further, it is to be appreciated that the design of the boot component <NUM>, core service component <NUM> and runtime decryption component <NUM> can include other component selections, component placements, etc., to facilitate enhanced container security. Moreover, the aforementioned systems and/or devices have been described with respect to interaction between several components. It should be appreciated that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. Sub-components could also be implemented as components communicatively coupled to other components rather than included within parent components. Further yet, one or more components and/or sub-components can be combined into a single component providing aggregate functionality. The components can also interact with one or more other components not specifically described herein for the sake of brevity, but known by those of skill in the art.

<FIG> illustrates a flow diagram of an example, non-limiting computer-implemented method <NUM> that facilitates security hardening of a system which hosts containers in accordance with one or more embodiments described herein. The method of <FIG> is described with reference to the computer <NUM> illustrated in <FIG>. The computer-implemented method of <FIG> enhances security of containers such as <NUM> at a container server such as computer <NUM> by securing data associated with the container <NUM> from one or more types of administrative access to container memory during instantiation and runtime of the container <NUM> at the container server such as computer <NUM>.

At <NUM>, a boot component <NUM> operatively coupled to a processor <NUM> performs at least a portion of a trusted boot sequence to securely boot a computer <NUM> to a defined secure state wherein one or more types of administrative access to a container memory (a container memory portion of system memory <NUM>) are deactivated. Example types of administrative access to the container memory which are deactivated include, but are not limited to administrative access to the container memory through booting from a modified kernel which is modified with respect to a trusted kernel associated with the trusted boot sequence; administrative access to the container memory through loading additional kernel modules, in addition to kernel modules of the trusted kernel; administrative access to the container memory through one or more virtual memory management devices; administrative access to the container memory through one or more runtime debugging functions; administrative access to the container memory through pausing a running process to view a memory associated with the running process; and administrative access to the container memory through kernel memory swap operations. In an implementation, the trusted boot sequence can include performing a hash on computer code stored at, or accessible by, the core services component <NUM>, and storing a resulting core service component <NUM> hash value in a PCR of PCRs <NUM>.

At <NUM>, the boot component <NUM> starts, as part of the trusted boot sequence, a core service component <NUM> operatively coupled to the processor <NUM>. At <NUM>, in an implementation, the core service component <NUM> securely obtains one or more decryption keys for use with the container memory portion of system memory <NUM>. In an implementation, the securely obtaining the one or more decryption keys can employ TPM <NUM> remote attestation to a trusted third party service device <NUM>.

At <NUM>, it is determined, e.g., by runtime decryption component <NUM>, whether a file requested by container <NUM> is encrypted. If yes, at <NUM>, runtime decryption component <NUM> can check process identifiers (PIDs) of one or more processes requesting encrypted files to ensure the PIDs belong to an entrypoint process of the container <NUM>, or a descendant process of the entrypoint process. At <NUM>, runtime decryption component <NUM> can use the one or more decryption keys obtained by core service component <NUM> to perform runtime decryption of one or more files accessed by container <NUM>, the container <NUM> being associated with the container memory portion of system memory <NUM>. In some examples, the runtime decryption component <NUM> can initially employ the one or more decryption keys to decrypt an encrypted container image to instantiate the container <NUM>.

In response to a determination, by runtime decryption component <NUM> at <NUM>, that a file requested by container <NUM> is not encrypted, runtime decryption component <NUM> can pass through, at <NUM>, one or more requests for non-encrypted files.

<FIG> illustrates a flow diagram of another example, non-limiting computer-implemented method <NUM> that facilitates security hardening of a system which hosts containers in accordance with one or more embodiments described herein. The method of <FIG> is described with reference to the docker-based embodiment illustrated in <FIG>. At <NUM>, a docker component <NUM> operatively coupled to a processor (not shown in <FIG>) can instantiate one or more containers such as container <NUM>. In an implementation, instantiating the one or more containers <NUM> by the docker component <NUM> can comprise instantiating at least one first container daemon component <NUM> operatively coupled to the processor, instantiating, by the first container daemon component <NUM>, a runtime decryption component such as blackbox FUSE component <NUM>, and instantiating, by the blackbox FUSE component <NUM>, the at least one of the one or more containers <NUM>. In some instances, blackbox daemon component <NUM> can instantiate the container <NUM>.

At <NUM>, for at least one of the one or more containers <NUM>, a runtime decryption component such as blackbox FUSE component <NUM> can manage one or more file accesses by the at least one of the one or more containers <NUM>. At <NUM>, blackbox FUSE component <NUM> can determine whether a requested file is encrypted. If the requested file is encrypted, the blackbox FUSE component <NUM> comprises a filesystem intermediary which can, at <NUM>, check the PIDs of one or more processes requesting access to encrypted files to ensure the PIDs belong to an entrypoint process of the container <NUM> or a descendant process of the entrypoint process. If the PIDs are authorized, at <NUM> the blackbox FUSE component <NUM> can retrieve, decrypt and return the requested files. For example, as described with reference to <FIG>, blackbox daemon component <NUM> can start a blackbox filesystem in user space (FUSE) component <NUM>, to start a FUSE process with a decryption key for container <NUM>. Blackbox FUSE component <NUM> provides a runtime decryption component <NUM> in the embodiment of <FIG>. Blackbox FUSE component <NUM> sits above the rootfs of the container <NUM>, that is the docker AUFS component <NUM>, as an intermediary filesystem layer. Blackbox FUSE component <NUM> decrypts encrypted files if the requesting process is the entrypoint process (which in some instances may also be the init process) of the container <NUM> or a descendant process of the entrypoint (or init) process of the container <NUM>.

Blackbox FUSE component <NUM> can also retrieve any unencrypted files for the requesting process. If the requested file is not encrypted, at <NUM> the blackbox FUSE component <NUM> can pass through, to docker AUFS component <NUM>, one or more requests to access non-encrypted files.

<FIG> illustrates a flow diagram of another example, non-limiting computer-implemented method <NUM> that facilitates security hardening of a system which hosts containers in accordance with one or more embodiments described herein. The method of <FIG> is described with reference to <FIG>.

At <NUM>, a boot component <NUM> operatively coupled to a processor <NUM> can perform at least a portion of a trusted boot sequence to securely boot a computer <NUM>. The trusted boot sequence can comprise, for example, at <NUM>, resetting one or more PCRs <NUM>, and at <NUM>, running a series of boot components, wherein each boot component in the series performs a hash of computer code stored at, or accessible by, a next boot component in the series and stores a corresponding PCR hash value and/or uses TPM <NUM> to compare the next boot component hash value against a stored PCR hash value. The trusted boot sequence securely boots the computer <NUM> to a defined secure state wherein one or more types of administrative access to a container memory portion of system memory <NUM> are deactivated. As described herein, least one of the boot components in the series of boot components can comprises a core service component <NUM>, or the core service component <NUM> can be included in a trusted kernel loaded at the end of the trusted boot sequence.

At <NUM>, the core service component <NUM> operatively coupled to the processor <NUM> can perform a TPM <NUM> remote attestation to a trusted third party service device <NUM>. At <NUM>, the core service component <NUM> can securely obtain one or more decryption keys for a container <NUM> from the trusted third party service device <NUM>, and the core service component <NUM> can store the one or more decryption keys for the container <NUM> in a container memory associated with the container <NUM>.

At <NUM>, a runtime decryption component <NUM> operatively coupled to the processor <NUM> can manage one or more file accesses by the container <NUM>, at least in part by checking PIDs of one or more processes requesting access to encrypted files to ensure the PIDs belong to an entrypoint process of the container <NUM> or a descendant process of the entrypoint process, wherein the one or more decryption keys obtained at <NUM> are used to decrypt the encrypted files.

For simplicity of explanation, the computer-implemented methodologies are depicted and described as a series of acts. It is to be understood and appreciated that the subject innovation is not limited by the acts illustrated and/or by the order of acts, for example acts can occur in various orders and/or concurrently, and with other acts not presented and described herein. Furthermore, not all illustrated acts can be required to implement the computer-implemented methodologies in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the computer-implemented methodologies could alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, it should be further appreciated that the computer-implemented methodologies disclosed hereinafter and throughout this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such computer-implemented methodologies to computers. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media.

Moreover, because configuration of data packet(s) and/or communication between components is established from a combination of electrical and mechanical components and circuitry, a human is unable to replicate or perform the subject data packet configuration and/or the subject communication between processing components and/or an assignment component. For example, a human is unable to measure a hash of a next component in a boot process, or to decrypt an encrypted file, etc. Moreover, a human is unable to packetize data that can include a sequence of bits corresponding to information generated during the various container security processes, or transmit data that can include a sequence of bits corresponding to information generated during the security processes described herein, etc..

The present invention may be a system, a method, an apparatus and/or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium can also include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.

In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, to perform aspects of the present invention.

These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks. The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational acts to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

While the subject matter has been described above in the general context of computer-executable instructions of a computer program product that runs on a computer and/or computers, those skilled in the art will recognize that this disclosure also can or can be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive computer-implemented methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as computers, hand-held computing devices (e.g., PDA, phone), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of this disclosure can be practiced on stand-alone computers. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

As used in this application, the terms "component," "system," "platform," "interface," and the like, can refer to and/or can include a computer-related entity or an entity related to an operational machine with one or more specific functionalities. The entities disclosed herein can be either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In another example, respective components can execute from various computer readable media having various data structures stored thereon. The components can communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, which is operated by a software or firmware application executed by a processor. In such a case, the processor can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, wherein the electronic components can include a processor or other means to execute software or firmware that confers at least in part the functionality of the electronic components. In an aspect, a component can emulate an electronic component via a virtual machine, e.g., within a cloud computing system.

As it is employed in the subject specification, the term "processor" can refer to substantially any computing processing unit or device comprising, but not limited to, single-core processors; single-processors with software multithread execution capability; multi-core processors; multi-core processors with software multithread execution capability; multi-core processors with hardware multithread technology; parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), a discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Further, processors can exploit nano-scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, to optimize space usage or enhance performance of user equipment. A processor can also be implemented as a combination of computing processing units. In this disclosure, terms such as "store," "storage," "data store," data storage," "database," and substantially any other information storage component relevant to operation and functionality of a component are utilized to refer to "memory components," entities embodied in a "memory," or components comprising a memory. It is to be appreciated that memory and/or memory components described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or nonvolatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM). Volatile memory can include RAM, which can act as external cache memory, for example. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Additionally, the disclosed memory components of systems or computer-implemented methods herein are intended to include, without being limited to including, these and any other suitable types of memory.

Claim 1:
A system for managing container security, comprising:
a memory (<NUM>) that stores computer executable components;
a processor (<NUM>) that executes computer executable components stored in the memory, wherein the computer executable components comprise:
a boot component (<NUM>) that performs at least a portion of a trusted boot sequence to securely boot the system to a defined secure state wherein one or more types of administrative access to a container memory are deactivated;
a core service component (<NUM>) started as a part of the trusted boot sequence and that securely obtains one or more decryption keys for use with the container memory, wherein the core service component (<NUM>) securely obtains the one or more decryption keys using a Trusted Processing Module (TPM) (<NUM>) remote attestation to a trusted third party service device (<NUM>); and
a runtime decryption component (<NUM>) that uses the one or more decryption keys to perform runtime decryption of one or more files accessed by an entrypoint process of a container associated with the container memory or a descendant of the entrypoint process.