Patent Description:
Rather, this background is only provided to illustrate one exemplary technology area where some embodiments describe herein may be practiced. <CIT> describes systems and methods for providing computer system monitoring as a service of a computing resource service provider, monitoring capacity computer system of a customer of the computing resource service provider, and based on the request, launching a monitoring agent in a protected execution environment in which the monitoring agent is configured to generate an assessment of the computer system and provide the assessment of the computer system. <CIT> describes methods and systems for instantiating an enclave according to a request, the enclave being instantiated at a determined location of a set of locations in a computing environment of a computing resource service provider hosting a set of computing resources. The enclave further being instantiated with executable code specified by a customer for processing network traffic in accordance with the executable code in a computing environment.

The principles described herein relate to a host computing system that runs a security component and a container such that code running within the container cannot access data and resources running on the host computing system except through one or more predetermined locations that are visible from within the container. As an example, that predetermined location could be a container file system - a file system that is visible to code running within the container. Thus, even untrusted code (code that has not passed a compliance review process designated by an entity) can be safely run on a host computing system of that entity.

The security component helps provide this safety by facilitating input of input data to the container, and by facilitating output of output data from the container. To facilitate the input to the container, the security component checks whether code running within the container is authorized to have access to the input data, and if so, provides the input data into one or more predetermined input locations visible to the container (e.g., one or more folders of the container file system). To facilitate the output from the container, the security component reads the output data from one or more predetermined output locations visible to the container (e.g., one or more folders of the container file system), performs one or more security checks on the output data, and if the output data passes the one or more security checks, provides the output data external to the container.

Such containers and host security components may similarly operate on multiple host computing systems. An overlay network may be present over multiple of such containers to thereby allow the code within containers to communicate with each other, even if the code is running on different computing systems, so long as the code is running within the overlay network. The overlay network permits communication while still allowing the safe communication of data to and from each container.

Thus, network workloads can be emulated while keeping their respective host computing systems safe. Accordingly, code does not have to be subject to compliance review each time a small change is made. Instead, code that has more minor changes can still be used even though a compliance check has not been performed since that change. This makes the process of developing code much more efficient since time-consuming compliance checks may be performed with less frequency without sacrificing security.

Such containers and host security components may similarly operate on multiple host computing systems. An overlay network may be present over multiple of such containers to thereby allow the code within containers to communicate with each other, even if the code is running on different computing systems, so long as the code is running within the overlay network. The overlay network permits communication while still allowing the safe communication of data to and from each container. Accordingly, the principles described herein allow for more dangerous code to run within a container whilst still being able to communicate with other non-compliant code running within another container.

<FIG> illustrates a system <NUM> in which the principles described herein may operate. The system <NUM> includes one or more host computing system including the host computing system <NUM>, amongst potentially other host computing systems as represented by the ellipsis <NUM>. Although not required, in the illustrated embodiment, the system <NUM> also includes a data source <NUM>. The host computing system <NUM> may be a virtual computing system (e.g., a virtual machine). In this case, the host computing system <NUM> emulates the behavior of a physical computing system, such as the computing system <NUM> described below with respect to <FIG>. Alternatively, the host computing system <NUM> may be a physical computing system, such as the computing system <NUM> described below with respect to <FIG>.

The host computing system <NUM> includes a container <NUM> and a security component <NUM>. Code <NUM> runs within the container <NUM>. However, the host computing system <NUM> also has code <NUM> running outside of the container <NUM>. In addition, the host computing system <NUM> also has data <NUM> and other resources <NUM> external to the container <NUM>. The container <NUM> is configured to prevent the internal code <NUM> having access to data (e.g., data <NUM>) and resources (e.g., resources <NUM>) on the host computing system except through one or more locations that are visible to the container. In one embodiment, the code <NUM> running inside the container <NUM> is non-compliant code that has not passed a set of compliance reviews that code <NUM> running outside of the container has passed. Accordingly, the container <NUM> protects the host computing system <NUM> from potential harm caused by non-compliant code.

The security component <NUM> facilitates input of data to the container <NUM> as represented by the arrow 113A, and facilitates output of data from the container <NUM> as represented by arrow 114A. In particular, the security component <NUM> provides appropriate input data 113B into one or more predetermined input locations 113C that are visible to the container <NUM>. In addition, the security component <NUM> reads output data 114B that was placed into one or more predetermined output locations 114C, and if appropriate, provides that output data external to the container <NUM>. Thus, the security component <NUM> has an opportunity to inspect the input data 113B prior to providing the input data to the container <NUM>, and inspect the output data 114B prior to externally providing the output data from the container <NUM>.

In one embodiment, the one or more predetermined input locations 113C are one or more folders within a file system that is visible to code (e.g., code <NUM>) running within the container <NUM>. Such a file system will be referred to herein as a "container file system. " These one or more input folders may be read-only folders. Additionally, the one or more predetermined output locations 114C may also be one or more folders (also called herein "output folder") within the container file system. These one or more output folders may be read-write folders or perhaps even write-only folders.

<FIG> illustrate flowcharts of methods performed in conjunction with appropriately interfacing with the container hosted on the host computing system <NUM>. <FIG> illustrates a flowchart of a method <NUM> for causing a container to run internal code, and represents how the host computing system creates an appropriate environment in which input data is securely provided to the container (as in <FIG>), and in which output data is securely drawn from the container (as in <FIG>). The methods of <FIG> will each be described with frequent reference to the system <NUM> of <FIG>.

The method <NUM> includes running a container on the host computing system (act <NUM>). As an example, in <FIG>, the host computing system <NUM> runs the container <NUM>. If there are multiple containers that are to communicate one with each other, then the method <NUM> also includes determining whether there are multiple containers (decision block <NUM>). In the illustrated case of <FIG>, there is only one container within the system ("No" in decision block <NUM>). In this case, the container runs the code internal to the container (act <NUM>). If there had been multiple containers that are to communicate (as will be described with respect to the system <NUM> of <FIG>) ( "Yes" in decision block <NUM>), then an overlay network is established to include all of the containers that are to communicate (act <NUM>), and then the code is run within the container (act <NUM>).

<FIG> illustrates a flowchart of a method <NUM> for facilitating input of data to code running in a container running on a host computing system, in accordance with the principles described herein. The method <NUM> may be performed in the context of the system <NUM> of <FIG>. For example, arrow 113A represents an example of such input. Accordingly, the method <NUM> will now be described with frequent reference to the system <NUM> of <FIG> by way of example.

The method <NUM> includes accessing input data to be provided to code running inside the container (act <NUM>). Referring to <FIG>, the host computing system <NUM> accesses data 113B. In one embodiment, the security component <NUM> maps locations (e.g., location <NUM>) within a data source (e.g., data source <NUM>) as containing data that is pre-authorized for access within the container <NUM>. In <FIG>, the mapping between location <NUM> and the container <NUM> input path is represented by dashed-lined arrow <NUM>. Thus, when data is placed within the location <NUM> of the data source <NUM>, that data might automatically be accessed by the host computing system <NUM> to provide to the container <NUM>. The data source <NUM> could be, for example, a network storage, a cloud storage, or a store service, or any other data source.

The security component then checks whether the code running within the container is authorized to have access to the input data (decision block <NUM>). In one embodiment, the very fact that the data was found within the location <NUM> may be a sufficient assurance that the input data 113B is authorized for access within the container <NUM>. Alternatively, or in addition, the security component <NUM> may follow rule-based and machine-learning based logic to determine whether access should be granted from within the container. The check could include verifying that the target code owns the data, where the data was generated and perhaps what generated the data, access privileges, whether the data is marked as sensitive, and so forth.

If the code is authorized to be provided to the container (Yes in decision block <NUM>), the security component provides the input data into the predetermined input locations (act <NUM>). As an example, in <FIG>, the security component <NUM> provides the input data 113B into the input locations 113C, which can then be accessed by the code <NUM> within the container <NUM>. For example, the input locations 113C may be one or more read-only folders in a container file system. On the other hand, if the code is not authorized to be provided to the container ("No" in decision block <NUM>), the data is blocked from being provided to the container <NUM> (act <NUM>).

<FIG> illustrates a flowchart of a method <NUM> for facilitating output of data from code running in a container running on a host computing system, in accordance with the principles described herein. The method <NUM> may be performed in the context of the system <NUM> of <FIG>. For example, arrow 114A represents an example of such output. Accordingly, the method <NUM> will now be described with frequent reference to the system <NUM> of <FIG> by way of example.

The method <NUM> includes reading output data from one or more predetermined output locations (act <NUM>). Referring to <FIG>, the host computing system <NUM> reads the output data 114B from the output locations 114C. The security component then performs one or more checks on the output data to determine whether the output data satisfies those checks (decision block <NUM>). If the output data passes the security checks ("Yes" in decision block <NUM>), the security component allows the output data to be provided external to the container (act <NUM>). As an example, in <FIG>, the output data 114B is provided external to the container <NUM>. Otherwise ("No" in decision block <NUM>), the security component prevents or blocks the output data from being provided outside the container. An example of a check on such output data might include verifying that the data does not include an executable or instruction that could be executed by the host computing system.

In one embodiment, the security component <NUM> maps locations (e.g., location <NUM>) within a data source (e.g., data source <NUM>) as a target for providing any output data provided from the container. In <FIG>, the mapping between location <NUM> and the container <NUM> output path is represented by dashed-lined arrow <NUM>. Thus, when code within the container places data within the location 114C, the security component <NUM> may automatically perform a security check on that data, and if that data passes the security checks, provide that data to the location <NUM> of the data source <NUM>.

<FIG> illustrates a system <NUM> that is similar to the system <NUM> of <FIG> in that it includes the host computing system <NUM>, the data source <NUM>, and the mappings <NUM> and <NUM>. However, the system <NUM> also includes another host computing system <NUM>. The second host computing system also includes a container <NUM>, input locations 213C, output locations 214C, and security component <NUM>, which may have similar functions as described for the respective container <NUM>, input locations 113C, output locations 114C and security component <NUM> of <FIG>.

That is, the container <NUM> operates to prevent code <NUM> running therein from harming the data <NUM> and resources <NUM> of the host computing system <NUM>. Instead, the container <NUM> only can access data via the input location(s) 213C and provide data via the output location(s) 214C. The security component <NUM> likewise performs checks on the input data 213B and ensures secure providing of the pre-authorized data to the input location(s) 213C (as represented by arrow 213A), and the secure channeling of the output data 214B from the output location(s) 214C (as represented by arrow 214A). Furthermore, the code <NUM> may be code that has not complied with a compliance protocol whereas the code <NUM> running outside of the container <NUM> has complied with the compliance protocol. Also, the data source <NUM> includes an additional location <NUM> that maps (according to mapping <NUM>) to the input channel 213A, and a location <NUM> that maps (according to mapping <NUM>) to the output channel 214A.

In one embodiment, code <NUM> within the container <NUM> and code <NUM> within the container <NUM> are to communicate one with another. In this case, an overlay network <NUM> encompasses the first container <NUM> and the second container <NUM>. This overlay network allows code within each container <NUM> and <NUM> to communicate with each other, notwithstanding their respective containers preventing them from being able to otherwise change the data or resources running on their respective host computing systems. The overlay network <NUM> may be a component that allows for code from one container to discover and address the code within the other container.

The overlay network ensures that when the code <NUM> provides data to the output location 114C that is addressed to the code <NUM>, that this data will be received at the input location 213C for consuming by the code <NUM>. Likewise, the overlay network ensures that when the code <NUM> provides data to the output location 214C that is addressed to the code <NUM>, that this data will be received at the input location 113C for consuming by the code <NUM>. There may likewise be three or more containers encompassed by an overlay network, and any of the code within these containers may communicate with the aid of the overlay network.

The overlay network <NUM> uses an actual network <NUM> that connects the host computing systems <NUM> and <NUM>. For instance, if the host computing systems <NUM> and <NUM> were physical computing systems, the network <NUM> would be a physical network. If the host computing systems <NUM> and <NUM> were virtual computing systems (e.g., virtual machines), the network <NUM> would be a virtual network. Alternatively, the host computing systems could be a mix of virtual machine and physical computing system. For instance, host computing system <NUM> might be a virtual machine, whereas host computing system <NUM> might be a physical computing system, and vice versa.

Accordingly, the principles described herein allow for more dangerous code to run within a container whilst still being able to communicate with other non-compliant code running within another container. Thus, network workloads can be emulated while keeping their respective host computing systems safe. Accordingly, code does not have to be subject to compliance review each time a small change is made. Instead, code that has more minor changes can be permitted to be used, leaving compliance checks to be performed later. This makes the process of developing code much more efficient since time-consuming compliance checks may be performed with less frequency without sacrificing security.

Because the principles described herein are performed in the context of a computing system, some introductory discussion of a computing system will be described with respect to <FIG>.

As illustrated in <FIG>, in its most basic configuration, a computing system <NUM> includes at least one hardware processing unit <NUM> and memory <NUM>. The processing unit <NUM> includes a general-purpose processor. Although not required, the processing unit <NUM> may also include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. In one embodiment, the memory <NUM> includes a physical system memory. That physical system memory may be volatile, non-volatile, or some combination of the two. In a second embodiment, the memory is non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system <NUM> also has thereon multiple structures often referred to as an "executable component". For instance, the memory <NUM> of the computing system <NUM> is illustrated as including executable component <NUM>. The term "executable component" is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods (and so forth) that may be executed on the computing system. Such an executable component exists in the heap of a computing system, in computer-readable storage media, or a combination.

One of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure may be computer readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term "executable component".

While not all computing systems require a user interface, in some embodiments, the computing system <NUM> includes a user interface system <NUM> for use in interfacing with a user. The user interface system <NUM> may include output mechanisms 612A as well as input mechanisms 612B. The principles described herein are not limited to the precise output mechanisms 612A or input mechanisms 612B as such will depend on the nature of the device. However, output mechanisms 612A might include, for instance, speakers, displays, tactile output, virtual or augmented reality, holograms and so forth. Examples of input mechanisms 612B might include, for instance, microphones, touchscreens, virtual or augmented reality, holograms, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing order. Furthermore, the outlined operations are only provided as examples, and some of the operations may be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

Claim 1:
A system (<NUM>, <NUM>) comprising:
a host computing system (<NUM>, <NUM>, <NUM>) comprising one or more processors (<NUM>); and one or more computer-readable media having thereon computer-executable instructions (<NUM>) that are structured so as to configure the host computing system to instantiate the following in response to the one or more processors executing the computer-executable instructions:
a container (<NUM>, <NUM>) configured to prevent access to data (<NUM>, <NUM>) and resources (<NUM>, <NUM>) on the host computing system except through one or more locations (113C, 114C, 213C, 214C) that are visible to the container; and
a security component (<NUM>, <NUM>) that is configured to do the following:
facilitate input (113A, 213A) of input data (113B, 213B) to the container by:
mapping a location (<NUM>) within a data source (<NUM>) as containing data that is pre-authorized for access within the container;
checking (<NUM>) whether code (<NUM>, <NUM>) contained within the container is authorized to have access to the input data by checking that the input data is found within the mapped location; and
if the code contained within the container is so authorized, providing (<NUM>) the input data into one or more predetermined input locations (113C, 213C) visible to the container; and
facilitate output (114A, 214A) of output data (114B, 214C) from the container by:
reading (<NUM>) the output data from one or more predetermined output locations (114C, 214C) visible to the container, and
performing (<NUM>) one or more security checks on the output data, and
if the output data passes the one or more security checks, providing (<NUM>) the output data external to the container, wherein performing one or more security checks comprises verifying that the data does not include an executable or instruction executable by the host computing system.