Partial-privilege lightweight virtualization environment

Abstract

Fine-grained selectively privileged container virtual computing environments provide a vehicle by which processes involving modification of particular aspects of a host computing environment can be passed to and executed on the host computing environment while maintaining advantageous and desirable protections and isolation between the remaining aspects and portions of the host computing environment and the selectively privileged container computing environment. Such selective privilege is provided based on directly or indirectly described actions that are allowed and disallowed by processes executing in the selectively privileged container virtual computing environment on the host computing environment. Aspects of the host computing environment operating system, such as the kernel, are extended to interface to a container-centric mechanism to receive information as to which actions the kernel can allow or deny even if the process attempting such actions would otherwise have sufficient privilege.

Description

Background Technology

[0001] Traditional virtual computing environments, often referred to as "virtual machines," virtualize most or all aspects of a computing environment, thus presenting a computing environment very different from the host computing device hardware and operating system. Such virtual machine computing environments can virtualize the computing hardware itself. However, due to the need to virtualize most or all aspects of the host computing environment's hardware, traditional virtual computing environments can consume large amounts of memory, require significant processing resources, and may otherwise be inefficient. In some instances, lightweight virtual computing environments, often referred to as "containers," can provide many of the isolation benefits of traditional virtual computing environments in a more efficient way, such as by utilizing aspects of the host computing device hardware and operating system, rather than those aspects of the computing environment being virtualized. Such container virtual computing environments can virtualize only portions of the computing environment, such as only the file system, thus presenting different, isolated views of file data. Therefore, containers can be used to provide isolated computing environments, such as limiting the impact of potentially malicious instructions, providing raw computing environments, such as for testing or troubleshooting purposes, and other similar benefits.

[0002] In some instances, it may be desirable to allow processes executing within a container virtual computing environment to directly persist changes to the host computing environment. For example, a container virtual computing environment might leverage aspects of the host computing environment's operating system, such as its printer driver. A process executing within a container virtual computing environment could install a new printer driver within that environment, but because such changes traditionally only occur within the container virtual computing device itself and do not affect the host computing environment, processes executing in other virtual computing environments or within the host computing environment itself would not be able to access this new printer driver. Privileged containers can be provided with access to the underlying host computing environment.

[0003] Unfortunately, privileged containers can access the entire host computing environment, thus defeating many of the protection and isolation advantages of unprivileged traditional containers. Summary of the Invention

[0004] Fine-grained, selectable partially privileged container virtualization (VVMs) provide a vehicle through which processes involving modifications to specific aspects of the host computing environment can be passed to and executed on the host computing environment, while maintaining favorable and desired protection and isolation between the rest of the host computing environment and the partially privileged container computing environment. Such partial privileges are provided based on actions directly or indirectly described as allowing and disallowing actions on the host computing environment by processes executing in the partially privileged container virtualization environment. Various aspects of the host computing environment's operating system, such as the kernel, are extended to interface with container-centric mechanisms to receive information about which actions the kernel can allow or deny, even if the process attempting such an action would otherwise possess sufficient privileges. Conversely, blocked actions are executed in the context of the container virtualization environment as overlays, which can be documented in the host computing environment's sandbox according to traditional container virtualization methodologies.

[0005] This summary is provided to present, in a simplified form, the selected concepts further described in the detailed description section. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0006] Additional features and advantages will become apparent from the following detailed description with reference to the accompanying drawings. Attached Figure Description

[0007] The detailed implementation method described below can be better understood in conjunction with the accompanying drawings, wherein:

[0008] Figure 1 This is a system diagram of an exemplary non-privileged container virtual computing environment;

[0009] Figure 2 This is a system diagram of an exemplary privileged container virtual computing environment;

[0010] Figure 3 This is a system diagram of an exemplary privileged container virtual computing environment;

[0011] Figure 4 This is another exemplary system diagram of a partially privileged container virtual computing environment;

[0012] Figure 5 This is a system diagram of an exemplary nested virtual computing environment;

[0013] Figure 6 This is a system diagram of an exemplary mechanism for implementing partial privileges on a container virtual computing environment;

[0014] Figure 7This is a system diagram of an exemplary container-based node maintenance and transmission mechanism;

[0015] Figure 8 This is an exemplary implementation flowchart of certain privileges for a container virtual computing environment;

[0016] Figure 9 This is a flowchart illustrating the instantiation of an exemplary container; and

[0017] Figure 10 This is a block diagram of an exemplary computing device. Detailed Implementation

[0018] The following description pertains to fine-grained, optional partially privileged container virtual computing environments (VVMs) that enable mechanisms to allow processes involving modifications to specific aspects of the host computing environment to be passed to and executed on the host computing environment, while maintaining favorable and desired protection and isolation between the remaining aspects of the host computing environment and the partially privileged VVM. Such partial privileges are provided based on actions, directly or indirectly described, that are permitted and prohibited by processes executing within the partially privileged VVM on the host computing environment. Aspects of the host computing environment's operating system, such as the kernel, are extended to interface with container-centric mechanisms to receive information about which actions the kernel can allow or deny, even if the process attempting such an action would otherwise possess sufficient privileges. Conversely, prohibited actions are executed in the context of the VVM as overridden actions, which can be documented in the host computing environment's sandbox according to conventional VVM methodologies.

[0019] Although not required, the following description will be in the general context of computer-executable instructions (such as, for example, program modules) executed by a computing device. More specifically, unless otherwise indicated, the description will refer to the actions and symbolic representations of operations performed by one or more computing devices or peripheral devices. Thus, it should be understood that such actions and operations, sometimes referred to as computer-performed, include manipulation by a processing unit of electrical signals that represent data in a structured form. Such manipulation transforms or maintains the data in a memory location, reconfigures it in a manner well known to those skilled in the art, or otherwise alters the operation of the computing device or peripheral device. The data structure that maintains the data is a physical location having specific properties defined by the data format.

[0020] Typically, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will understand that computing devices are not limited to conventional personal computers, but include other computing configurations, including servers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframes, etc. Similarly, computing devices are not limited to standalone computing devices, as these mechanisms can also be implemented in distributed computing environments, where tasks are performed by remote processing devices linked via communication networks. In distributed computing environments, program modules can reside in both local and remote storage devices.

[0021] To provide context for the additional descriptions below, non-privileged and privileged virtualized computing environments are described. While this description is primarily made with reference to file system virtualization, virtualized computing environment implementations can be extended to many other aspects of the computing environment, such as access to computing environment settings, registry databases, control of executing processes, and other similar aspects. The following description details partially privileged container virtual computing environments. According to one aspect, such partial privileges are implemented in a database, such as in the registry, in which only certain registry entries or other similar database entries of the host computing environment may be affected by processes executing within the virtual computing environment, using the same methods detailed below. According to another aspect, such partial privileges are implemented as network firewall policies to provide only privileged and / or access to certain network endpoints of the host computing environment from within the virtual computing environment. In addition to the read / write operations detailed below, network virtualization may also include operations such as sending, receiving, modifying, forwarding, etc. According to yet another aspect, applications in the virtual computing environment may require license checks on the host computing environment and may only be granted partial access to licensed storage and / or databases on the host computer environment, such partial access depending on partial privileges.

[0022] refer to Figure 1 An exemplary system 100 is shown to provide context for the following description. Exemplary system 100 includes an exemplary host computing environment 110, which, for the purpose of providing context for the following description, hosts a virtualized computing environment in the form of an exemplary container 150. As used herein, the term "virtualized computing environment" refers to a virtualized computing environment that does not virtualize the underlying host computing hardware or devices, but rather virtualizes file systems and / or other operating system attributes, settings, extensions, registry, etc., thereby providing isolation between the host computing environment and the virtualized computing environment, such that changes made within the virtualized computing system do not similarly alter the host computing environment.

[0023] For example, such as Figure 1 As shown in the exemplary system 100, the exemplary host computing environment 110 has a host operating system running thereon, such as in the form of an exemplary host operating system 120. As part of the host operating system 120, one or more file system drives, filters, microfilters, and other similar file system components are typically... Figure 1 The host file system drive 130 is shown as obtaining structured data or more storage media, such as the exemplary storage media 111, from one or more file system drives and resolving this data into file structures that can be presented to applications and other processes running on the host operating system 120. For example, application 151 running on the host computing environment 110 may present multiple files, such as the exemplary files 141, 142, and 143, as part of the host file system 131. Similarly, a container operating system, such as the exemplary container operating system 160, is executed within the exemplary container 150. However, to provide file system virtualization, the exemplary container operating system 160 may present files different from those in the host file system 131.

[0024] According to one aspect, the file system of the exemplary container operating system 160 is a hierarchical file system that enables applications executing within the container environment 150, such as exemplary application 152, to access some or all files in the same file system of the host file system 131, such as exemplary files 141, 142, and 143, except that any changes or modifications to these files remain only within the container environment 150. For example, as Figure 1 As shown in the exemplary system 100, the exemplary container operating system 160 includes a hierarchical file system in the form of a container file system 171, which acts as a primary layer or "overlay," and this hierarchical file system is combined with a host file system 181 to act as a secondary layer or "underlay."

[0025] The file system referred to herein can be any known existing file system, such as the NT File System (NTFS), Apple File System (APFS), UNIX File System (UFS), etc., or other file systems. Similarly, the file system driver can be a corresponding driver, filter, mini-filter, and other similar driver that can implement such a file system. Thus, for example, if the host file system 131 is NTFS, then the host file system driver 130 is the associated NTFS driver. However, within the exemplary container environment 150, the host file system 181 is implemented in a slightly different manner to provide access to the host file system from within the virtualized computing environment. More specifically, according to one aspect, access to the host computing environment 110 from within the container environment 150 is via a container host connection, such as the exemplary container host connection 190. According to one aspect, the exemplary container host connection 190 is in the form of a virtualized network connection that emulates the container environment 150 as a computing device separate from the host computing environment 110, and the two computing devices are coupled via network communication. Other container host connections can be based on other communication protocols, such as peripheral interconnect protocols, etc. According to one aspect, the container host connection 190 appears as a block data device within the container environment 150. Accordingly, the host file system 181 within container environment 150 is implemented as, for example, a network file system, and correspondingly, driver 180 may include drivers, filters, mini-filters, and other similar structures. Driver 180 communicates with host computing environment 110 via container host connection 190 to implement such a network file system. Host computing environment 110 also includes file systems of the same type as host file system 131. For example, if host file system 131 is NTFS, then container file system 171 is also NTFS. In such a case, container file system driver 170 includes drivers, filters, mini-filters, and other similar structures as host file system driver 130. In fact, the same codebase, and even the same compiled binaries, can be used to implement container file system driver 170 and host file system driver 130.

[0026] According to one aspect, changes to files within the file system virtualization environment presented by container 150 are isolated from other file system virtualization environments and the host computing environment 110 itself. For example, if an exemplary application 152 executing within container environment 150 edits exemplary file 141, as shown in edit action 155, such a modification can cause file 144 (representing the edited version of file 141) to become part of container file system 171. The original file 141 will remain unchanged. However, from within container environment 150, the hierarchical file system will present the edited file 144 instead of the original file 141 from the host file system. In simpler terms, the edited file 144 will "block" or "mask" the presentation of the original file 141. If exemplary application 152 does not edit files 142 or 143, these files will still "pass through" the overlay file system and be presented to applications or processes executing within container 150, such as exemplary application 152.

[0027] The digital data representing the edited file 144 can be stored in a sandbox, such as the exemplary sandbox 149, which can be accessed by the container file system drive 170, as previously described, to create the container file system 171. As used herein, the term "sandbox" refers to one or more files, databases, structured storage, or other similar digital data repositories that store relevant data accessible only from within the isolated container virtual computing environment 150. For example, sandbox 149 could be a file or package within the host file system 131. In this way, the host computing environment 110 remains isolated from the edits performed within the container environment 150. Therefore, for example, if the edit 155 is a malicious action, the file 141 in the host computing environment 110 will remain isolated from and unaffected by such an action within the container environment 150.

[0028] Similarly, files installed or created by application 152 are also stored or mounted as part of the container file system 171. Therefore, for example, if application 152 wants to install a preferences file, such a preferences file will be stored as part of the container file system 171 and thus accessible to application 152 executing in the container virtual computing environment 150. However, the data in such a preferences file only increases the size of the sandbox 149 for the host computing environment 110 and will be invisible to application 151 executing in the context of the host computing environment 150. Therefore, the configuration of application 152 will be restricted to the container virtual computing environment 150.

[0029] As indicated, in some cases, it may be desirable to allow processes executing within container environment 150 to modify aspects of the underlying host computing environment 110, including modifying existing files, installing new files, changing settings (such as the current time), installing or removing drives, mini-filters, firmware, or other similar aspects of the underlying host computing environment 110. In such cases, privileged container virtual computing environments can be exploited.

[0030] Go to Figure 2 The exemplary system 200 shown illustrates a known privileged container in the form of an exemplary privileged container virtual computing environment 250. It can be seen that processes executing within a privileged container, such as the exemplary application 152, can directly access, modify, delete, and otherwise affect various aspects of the underlying host computing environment 110. More specifically, in the exemplary system 200, the container host connection takes the form of an exemplary container host connection 290, which can be a simpler connection than the previously described container host connection 190. For example, the exemplary container host connection 290 does not simulate a remote networking relationship between the privileged container computing environment 250 and the host computing environment 110. Instead, processes executing within the privileged container 250 are provided with access to the host file system 131, for example, by utilizing the same host file system drive 130. In this way, modifications made by application 152, such as editing file 141 to create a new version 241, also affect the host computing environment 110, because both application 151 executing within the host computing environment 110 and program 152 executing within the privileged container computing environment 250 can access the same underlying host file system 131. Therefore, modifying file 141 to create a new file 241 causes application 151 to no longer be able to access the previous version 141, but is only allowed to access the new version 241.

[0031] Although Figure 2 The exemplary system 200 illustrated depicts file modification by a process executing within a privileged container virtual computing environment 250. However, processes executing within privileged container 250 can modify other aspects of the host operating system 120 in a similar manner, including installing, updating, or removing drives, mini-filters, and other similar aspects of the host operating system 120. Furthermore, processes executing within privileged container 250 can change system time, various operating system preferences, and other similar aspects of the host operating system 120. While individual actions among these may be desirable to be performed by processes executing within a container virtual computing environment, existing technology forces Hobson to choose between either not performing any such privileged actions or allowing processes executing within a privileged container virtual computing environment to perform all such privileged actions.

[0032] Go to Figure 3 An exemplary partially privileged container virtual computing environment (MPC) is illustrated in the form of an exemplary partially privileged container virtual computing environment 350. A partially privileged container can have finer-grained privileges, allowing processes executing within such a container to perform certain privileged actions while continuing to protect and isolate the underlying host computing environment from other types of privileged actions. As will be described in detail below, such fine-grainedness may include allowing processes executing within the partially privileged container to modify files but preventing modifications to various aspects of the host operating system, or allowing modifications to specific parts of the host operating system but preventing modifications to other aspects of the host operating system, or allowing privileged access only to specific parts of the host file system, or other similar finer-grained distinctions. If an action attempted by a process within the partially privileged container is not permitted, such action can still be performed within the context of the virtual computing environment created by the partially privileged container, thereby allowing processes to operate freely within the virtual computing environment created by the partially privileged container while still protecting the underlying host computing environment and maintaining certain aspects of the host computing environment's isolation from the virtual computing environment created by the partially privileged container.

[0033] As an illustrative example, Figure 3 The exemplary system 300 illustrated shows a partially privileged container in the form of an exemplary partially privileged container 350, which is configured to allow read and write access to a portion of the host file system 131 311, while being configured to allow read access only to the remainder of the host file system 131 312. Furthermore, the host file system 131 may have additional files, directories, or other portions that are not exposed to the partially privileged container 350, even if they are read-only. File 344, such as... Figure 3As shown, this represents a portion of the host file system 131. This can be implemented as part of the host operating system 120 via container host connection 190 or some other component. The privileges associated with the container process 350 executing on the host computing environment 110, or the actions that the container process 350 can perform on the host computing system 110, are implemented by the host operating system 120 (including, for example, by the kernel of the host operating system 120) in conjunction with container definition files (or other similar data structures). Other data structures identify functions or actions that the container process 350 can or cannot perform in the host computing environment 110, such as exemplary functions 311 and 312. To allow processes to execute within the partially privileged container virtual computing environment 350, actions that the container 350 is not allowed to perform, and which cannot be performed on the host computing environment 110 by any process executing within the partially privileged container virtual computing environment 350, are instead performed within the isolated environment of the partially privileged container 350, thereby maintaining isolation from and protection of the host computing environment 110.

[0034] As illustrated in exemplary system 300, the execution of application 152 may result in the modification of files (such as, for example, files 141 and 143). For example, file 141 may be a document that can be created and edited by application 152, while file 143 may be a component that can be used by application 152 in conjunction with other applications. In such an example, it is desirable to prevent modification of file 143 on the host computing environment 110. For example, continued operation of application 151 may be based on file 143 remaining in an unmodified state. Therefore, in such an example, if application 152 were to modify file 143, application 151 might stop executing correctly or stop executing in the expected manner. However, application 152 might need to modify file 143 as a prerequisite for its own execution. To prevent modification of file 143 in host file system 131, host operating system 120 may specify certain portions of host file system 131, such as the portion where file 143 is stored, to require higher-level privileges to access and / or modify files within those portions of host file system 131. For example, operating systems often require elevated privilege levels, such as "administrator" or "superuser" privilege levels, to access specific files, folders, or directories that are necessary or important for the operation of the operating system and / or specific applications.

[0035] In combination, the host operating system 120 can proactively prevent the container process 350 from editing, deleting, or otherwise modifying portions of the host file system 131. As will be described in further detail below, such blocking is based on a list of actions enumerated as allowed or disallowed, which can be directly referenced or referenced based on metadata associated with such actions (such as the privilege level required to perform such actions) or an identifier of the specific source or target of such actions. In this way, more granular privileges or restrictions can be imposed on processes executing within the container.

[0036] More specifically, such as Figure 3 As illustrated in the exemplary system 300, when a process executing within a partially privileged container virtual computing environment 350 (e.g., exemplary application 152) attempts to perform an action, multiple privilege determinations are made. Initially, within the context of the partially privileged container virtual computing environment 350, the container operating system 160 checks whether the execution of application 152 is associated with a user having sufficient privileges, such as a user having sufficient privileges to edit files 141 and 143. As previously indicated, in this example, application 152 may need to edit files, such as file 143, which may require administrator, superuser, or other similar elevated privileges. Therefore, in such an example, a user seeking to effectively execute application 152, including within the partially privileged container computing environment 350, will need to execute application 152 with administrator or superuser privileges. However, if a user were to execute application 152 with such elevated privileges within the context of a conventional privileged container (such as privileged container 250 as previously detailed), application 152 would be able to access the entire host file system 131, because there is no mechanism to prevent such access other than a privilege check performed by the host operating system 120, which would determine that application 152 is executed with a sufficiently high privilege level to access the entire host file system 131.

[0037] In contrast, the exemplary partially privileged container 350 provides more fine-grained privilege control. Specifically, while a privilege check performed by the container operating system 160 can determine that application 152 is being executed with sufficient privilege level to perform both editing actions 355 and 356, a subsequent check performed by the host operating system 120 (described in further detail below) determines that action 356 is not permitted. As previously indicated, such a determination can be made with reference to implicit or explicit descriptions of permitted and / or prohibited actions.

[0038] For example, if the host operating system 120 determines that editing action 355 is permitted, then editing action 355 continues to edit file 141, replacing it with edit file 341. Such an action is performed directly on the host file system 131, for example, in a manner similar to the above reference. Figure 2The exemplary privileged container 250 is described in this manner. In contrast, if the host operating system 120 determines, for example, that an edit action 356 on file 143 is not permitted, a denial is provided by the container host connection 190, which may interface with the virtual file system drive 180, allowing the edit action 356 to be performed in the context of the partially privileged container computing environment 350 in the same manner as the conventional non-privileged container 150 described above. More specifically, the host file system 381 may include a first sub-part provided by the host file system drive 130, such as... Figure 2 The system 200 is provided as shown and described in detail above, and the host file system 381 may further include a second sub-part provided by the virtual file system drive 180, such as... Figure 1 The system 100 is provided as shown and described in detail above. A sub-part provided by the virtual file system driver 180 acts as the underlying layer (e.g., regarding file 143), and the edit action 356 creates a new file 343 in the container file system 371, which acts as an overwrite, whereas a sub-part provided by the host file system driver 130 acts as the host file system 131 (e.g., regarding file 341). Therefore, as previously described, from within the partially privileged container computing environment 350, application 152 sees both edited versions of file 341 and file 343, while from within the host computing environment 110, application 151 sees only the edited version of file 341 but only the original version of file 143. The file system 371, implemented by the same container file system driver 170 or a similar version thereof (similar to those described in detail above), can provide file system overwrites for those parts of the host file system 381 that the host operating system 120 does not allow processes executing within the partially privileged container 350 to perform actions on. As previously stated, information related to providing the container file system 371, such as information associated with editing file 343, is stored in a sandbox, such as the exemplary sandbox 149 described in detail above, and is still shown as Figure 3 Part of the host file system 131 in exemplary system 300.

[0039] In this way, the partially privileged container 350 provides a mechanism that allows processes running within it to perform certain functions that affect the host computing environment 110, while maintaining isolation between the container computing environment 350 and the host computing environment 110 for other types of functions.

[0040] According to one aspect, it may be beneficial for host computing environment 110 to use the latest version of a file, while ensuring the coexistence of one or more earlier versions with the latest version, for purposes such as compatibility. For example, some newer file versions may have better security and functionality, which would benefit host operating system 120 and / or application 151. In such an instance, both file 341 and file 141 are available to host computing environment 110. File 341 can be selected as the default; however, for example, if application 151 attempts to use file 341 but fails in some way, it can fall back and continue using file 141. Furthermore, multiple partially privileged containers (e.g., exemplary partially privileged container 350) can update file 341 more than once. If more than one version exists, host computing environment 110 can implement rollback mechanisms and / or side-by-side file storage to manage access to these multiple file versions and ensure optimal compatibility.

[0041] Although illustrated in the context of file system access, such partial privileges can include other capabilities, such as the ability to modify system time or other similar computing environment parameters, and to install, remove, and / or modify drives, mini-filters, firmware, registry entries, etc. For example, Figure 4The exemplary system 400 illustrated here is another exemplary partially privileged container in the form of an exemplary partially privileged container 450. Similar to the exemplary partially privileged container 350 detailed above, the exemplary partially privileged container 450 of the exemplary system 400 may have certain actions that the host operating system 120 would allow processes executing within such a partially privileged container 450 to perform, certain actions that the host operating system 120 would not allow, or a combination of the foregoing. For example, the host operating system 120 may allow the exemplary partially privileged container 450 to have read / write access 411 to the host file system 131 without modifying any host operating system extensions 420, such as read-only access 412. Operating system extensions 420 include drives (including purely software drives, such as drive extensions, virtual device drives, etc.), mini-filters, firmware updates, registry changes, operating system settings (such as the current time), operating system services, daemons, background processes, and other similar operating system extensions. Such a partially privileged container 450 can be used to support interaction with legacy hardware (such as exemplary legacy hardware 430) that may be part of the host computing environment 110, without potentially negatively impacting the host operating system 420, such as by installing operating system extensions, such as exemplary operating system extension 431, on the host operating system 420. For example, if allowed to continue execution as part of the host computing environment 110, exemplary operating system extension 431 might introduce vulnerabilities, instabilities, or other similar undesirable behaviors. However, exemplary extension 431 may be necessary to enable communication with, for example, legacy hardware 430.

[0042] More specifically, similar to the detailed description above, an application executing within the partially privileged container computing environment 450, such as application 152, first installs extension 431, as shown in installation action 451. As before, this installation action 451 requires application 152 to execute with high privileges, such as by a user with administrator or superuser privileges. Therefore, the container operating system 160 determines that application 152 executes with sufficient privileges to install extension 431. However, when application 152, executing from within the partially privileged container 450, attempts to access the host operating system extension 420 to continue the installation 451 of extension 431 on it, the host operating system 120 determines that such an action is not permitted. As before, this action is subsequently completed within the container's own computing environment and isolated from the host computing environment 110. In the current example, the installation of extension 431 instead points to container operating system extension 421, which overwrites the host file system 181 within container 150 with file system 141 (see above, e.g., ...). Figure 1In a similar manner (as shown), this becomes an overlay on the host operating system extension within the context of a partially privileged container computing environment 450. To avoid visual overcrowding, some components and aspects similar to those described in previous details are not listed here. Figure 4 The above is a straightforward representation. However, aspects and components of the container operating system 160 include mechanisms through which the container operating system extension 421 is overlaid on the host operating system extension 420, and these mechanisms are also visible and accessible to applications (e.g., exemplary application 152) executing within the partially privileged container computing environment 450. Therefore, from the perspective of processes executing within the partially privileged container computing environment 450 (e.g., exemplary application 152), the installation 451 of extension 431 has been successfully completed, and extension 431 is part of the operating system extensions available to these processes.

[0043] To continue the illustrative example, after successfully installing extension 431 (from the perspective of application 152), application 152 then uses extension 431 to access legacy hardware 430 and uses the legacy hardware 430 to create, edit, or otherwise modify file 441, as illustrated in action 452. For example, legacy hardware 430 could be an old digital camera, and extension 431 might be required to establish a communication connection with such a digital camera. File 441 could be a photo that application 152 copied from legacy hardware 430 and onto the host file system 131 using extension 431, as illustrated in editing action 452. In this way, partially privileged container 450 can support the use of legacy hardware or other similar actions without modifying the host operating system 120, for example, by installing legacy extensions that may cause instability or may be incompatible with various aspects of the host operating system 120.

[0044] The fine-grained privileged access provided by the partially privileged container described herein can be used to incrementally update various aspects of the host computing environment 110. For example, if the compatibility between extension 431 and the host operating system 120 is unknown or problematic, the exemplary system 400 described above can facilitate the installation of extension 431 onto the host operating system. The effective and proper installation and subsequent use of extension 431 within the context of the partially privileged container computing environment 450, such as through application 152, serves as verification that extension 431 is properly and completely installed without causing any incompatibilities or instabilities, and that it functions correctly within the context of the underlying host computing environment 110, with additional overlapping aspects such as the container operating system extension 421. Through such verification, it may be desirable to install extension 431 directly into the host operating system extension 420 so that the installation of extension 431 can persist after the termination of the partially privileged container process 450.

[0045] According to one aspect, changes made within the partially privileged container process 450, such as installing extension 431 into the container operating system extension overlay 421, are persisted to the host computing environment 110, for example, in the case of the aforementioned verification, or alternatively or additionally, when the partially privileged container process 450 terminates. More specifically, the sandbox 149 may include information describing the overlay, such as the exemplary container operating system extension overlay 421, which is unique to the partially privileged container computing environment 450 and otherwise isolated from the host computing environment 110. Such information may be in the form of enumerating transactions that, if applied to the host computing environment 110, will recreate the computing environment of the partially privileged container 450. For example, changes to NTFS files are logged or otherwise stored in the NTFS file system as discrete transactions. Such discrete transactions can be replayed or re-executed to recreate the computing environment of the partially privileged container 450 in the host computing environment 110.

[0046] Although described within the context of a single container virtual computing environment running on a host physical computing environment, the mechanisms described above also apply to container virtual computing environments running within other container virtual computing environments. For example, as Figure 5 The exemplary system 500 illustrated shows a partially privileged container 450 in the form of an exemplary container computing environment 510, except that it is now hosted by the container computing environment. More specifically, a container host connection 590, similar to the previously described container host connection 190, couples the partially privileged container 450 to the container computing environment 510 communicatively and functionally. Like the previously described host computing environment 110, the container computing environment 510 includes an operating system, such as a host container operating system 520, which includes file system drivers, such as a host container file system driver 530, similar to the previously described host file system driver 130. The host file system driver 530 supports the presentation of a host container file system 531, similar to the host file system 131, and the host container operating system 520 also includes a host container operating system extension 540, similar to the previously described host operating system extension 440.

[0047] Container computing environment 510 is similar to Figures 1 to 4 The other containers shown and described in detail above are executed on the host computing environment 110. According to one aspect, the container computing environment 510 virtualizes aspects of the computing hardware of the host computing environment 110, such as the exemplary storage medium 111, which is virtualized as container storage medium 511. In this way, the container computing environment 510 is more efficient than... Figures 1 to 4The container virtualization shown and described in detail above involves more computing environments, including, for example, virtualized operating system kernels. In simpler terms, the container computing environment 510 is closer to a complete virtual machine computing environment than a more lightweight container virtual computing environment.

[0048] Typically, container computing environments (such as the exemplary container computing environment 510), which virtualize a wider range of computing environments, are used to provide hardware independence and fault tolerance in server cluster computing environments. For example, multiple container computing environments, such as the exemplary container computing environment 510, can be instantiated in anticipation of increased demand from remote clients. Such remote clients utilize the container computing environment as any other computing environment, and the container process can be terminated when such a computing environment is no longer needed. Furthermore, if any hardware computing device fails, the container process can be instantiated on other hardware computing devices, and client utilization of the container process can continue without diminishing. In this way, a fixed set of hardware computing devices can accommodate varying numbers of remote clients while maintaining fault tolerance and location independence. In such an environment, the ability of a container computing environment (such as the exemplary container computing environment 510) to host partially privileged containers (such as the exemplary partially privileged container 450) provides the same benefits described in detail above, including, for example, allowing clients to incrementally update aspects of their computing environment, i.e., the computing environment provided by container computing environment 510.

[0049] Multiple nested container computing environments (such as Figure 5 Another use of the environment shown in the exemplary system 500 is to test or otherwise verify that processes from external sources do not violate or exceed privilege thresholds or restrictions established by operating system vendors, IT departments, or other similar standards-setting entities. For example, container computing environments, such as the exemplary container computing environment 510, can be set up to simulate standard computing environments that may require updates from containers, as referenced above. Figure 4 As described. If the operation of a partially privileged container 450 hosted by such an exemplary container computing environment 510 fails, the update exceeds the threshold privilege level provided by the container computing environment 510, for example, indicating that the update does not conform to the relevant specifications. Other similar tests or verifications can also be performed using nested container computing environments.

[0050] Go to Figure 6Referring to the exemplary system 600 shown therein, the above-described operations for imposing finer-grained restrictions on privileged containers are described in more detail. Specifically, within the host computing environment 110, when an application (such as exemplary application 151) performs an action (such as exemplary action 651), the kernel 620 of the host operating system 120, in conjunction with other operating system components, determines whether to allow or deny such action 651. Typically, such determination involves querying multiple sources from which restrictions can be enforced, including comparing the privilege level required for action 651 with the privilege level of the application 151 being executed (such as the privilege level identified by the user token of the user who triggered the execution of application 151), and comparing the identifier of the user executing application 151 with users allowed to access relevant data (such as users depicted in access control lists or other similar databases).

[0051] According to one aspect, kernel 620 can be modified to query or otherwise obtain information from other sources to determine whether to allow or deny an action from a process executing within a container that will modify aspects of the host computing environment. As utilized herein, the term "aspects of the host computing environment" does not include specific changes or updates to sandboxes, as such data is intended to be accessed only from within the container computing environment and is isolated from the host computing environment, except for sandboxes stored on the host computing environment. More specifically, when kernel 620 receives a request from a process executing within a container process (such as exemplary application 152) executing within exemplary partially privileged container process 650 to perform an action (such as exemplary action 652), in addition to one or more other checks detailed above, kernel 620 also obtains information about whether action 652 is allowed based on the settings of the partially privileged container 650. For example, as shown in communication 632, kernel 620 communicates with container-oriented services, such as exemplary container creation service 610, which, for example, creates and / or maintains the previously described container host connection 190. Conversely, as shown in communication 642, container creation service 610 references a container definition file, such as the exemplary container definition file 615, or an enumeration or identifier of other actions of a process that are allowed or disallowed to execute within partially privileged container 650. As previously described, such an enumeration or identifier of actions can be explicit or implicit and can be identified according to any identification mechanism, which includes, for example, an action identifier, the requested action privilege, the source of the action, a file, object, library, or other data being manipulated, and other similar identification mechanisms. Container creation service 610 then notifies kernel 620, and kernel makes a determination 622 to allow or deny action 652.

[0052] As part of the operation of components such as container creation service 610 and kernel 620, additional steps can be performed to verify the identity of partially privileged container 650, application 152, and related components. This includes checking certificates, hashes and / or digital signatures, performing software license checks, scanning for virus signatures, checking over the network and remote services, checking user identity, and so on. Information obtained from such checks can further determine whether to allow or deny an action, such as exemplary action 652. Such checks can occur at any point in the container's lifecycle, including when the container is built, packaged, distributed, downloaded, initialized, paused, resumed, terminated, etc. According to one aspect, the allow or deny made by kernel 620 based on information received from container creation service 610 or other similar container information sources is the same as or similar to the allow or deny made by kernel 620 based on conventional reference information (e.g., privilege level). As previously stated, according to one aspect, the denial of action 652 can cause the action to be performed, at least initially, within container computing environment 650 rather than within host computing environment 110.

[0053] Go to Figure 7 The exemplary system 700 illustrated here illustrates an exemplary use of partially privileged containers to perform maintenance, update, installation, or other similar service functions on a host computing environment 110, which is also commonly referred to as a "node" within a clustered computing environment. Node 110 may have multiple container packages stored at any given time for subsequent instantiation, such as creating a service 610 via a container. A queue 720 of container packages is illustrated as being stored on node 110. Each container package, such as exemplary container package 730, includes a container payload (such as example container payload 732) that includes computer-executable instructions to be executed in the container virtual computing environment, data to be used or installed from the container virtual computing environment, and other similar code and / or data. Container packages (such as exemplary container package 730) and container definition files (such as example container definition file 733), as previously described, may describe limitations on the functionality executable by processes executing within the partially privileged containers. Optionally, a container package (such as the exemplary container package 730) may be associated with a container identifier 731, which may be an identifier, serial number or other similar container identification information.

[0054] In some instances, a container management system can leverage partially privileged containers to perform incremental maintenance, updates, installations, or other similar service functions across multiple computing devices (including, for example, node 110). Such incremental services can be deterministic because subsequent services require that previous services have been correctly executed and completed as a prerequisite. For example, installing an update to an existing application might require a driver with the update already installed. Such prerequisites are specified, for example, through policies associated with containers, container definition files, or other similar metadata. A container package (e.g., exemplary container package 730) is provided to a container creation service 610 for instantiating a container, which verifies that necessary and / or specified prerequisites are met before providing the container package to the container creation service 610 for container instantiation.

[0055] In addition to specifying prerequisites (such as incremental updates or other similar maintenance performed by processes executing within a partially privileged container compute environment instantiated in multiple sequences), the container management system may also provide container policies that further describe which containers are instantiated, the instantiation order of the containers, relevant node compute conditions that may affect container instantiation, and other similar container policies. As shown in Exemplary System 700, a single node (such as Exemplary Node 110) can receive container packages from multiple container management systems (such as Example Container Management Systems 780 and 790). More specifically, the container deployment manager of Container Management System 780 (such as Exemplary Container Deployment Manager 782) and the Exemplary Container Deployment Manager 792 of Container Management System 790 independently provide container packages to Node 110, which, as previously described, are maintained in a container package queue (such as Exemplary Container Package Queue 720). Furthermore, the container management system includes policy managers (such as Exemplary Policy Managers 781 and 791) that provide updated policies that can affect a single container or multiple containers, and such policies are maintained in a policy store (such as Exemplary Policy Store 740) in Node 110.

[0056] The receipt of a policy can sometimes lead to the deprecation, deactivation, or other similar effects of previously received policies retained in policy store 740. For example, a subsequently received policy may indicate that a previously received policy is no longer valid. In such instances, in addition to retaining the newly received policy in policy store 740, the local container manager 710 or other similar processes may remove policies that are no longer valid or otherwise update the policies stored in policy store 710.

[0057] According to one aspect, a priority matrix (such as the exemplary priority matrix 750) is created (e.g., created by the local container manager 710) using information specified by received policies, container definition files, or other container metadata. Priority matrix 750 includes different priorities, through which containers included in different priority queues 720 will be instantiated based on different prerequisites or other similar inputs. For example, if the available system resources on node 110 exceed a threshold, priority matrix 750 may indicate that one container will be instantiated before another, but if the available system resources are below the threshold, the second container will be instantiated before the first.

[0058] The local container manager 710 provides containers to the container creation service for instantiation based on priority checks (such as exemplary priority check 761), idempotency checks (such as exemplary idempotency checks 762 and 763), or a combination thereof, as shown in action 770. Priority checks (such as exemplary priority check 761) confirm that necessary or enumerated prerequisites for container instantiation are met. Priority checks may refer to priority matrix 750 and independently confirm the existence of relevant prerequisites. Idempotency checks confirm that processes executing within a partially privileged container virtual computing environment are idempotent relative to the subsequent computing environment 110. In particular, some processes can perform actions that, if performed again, do not make additional changes to the host computing environment 110. For example, if the existence of an extension is checked before installation begins, the process installing the extension can be idempotent. If such a process is to be executed multiple times, no additional extensions or copies of the same extension will be installed. Conversely, processes that increment a counter are not idempotent because each subsequent execution of such a process will continue to increment the counter. According to one aspect, containers can be authenticated as idempotent (such as through password-secure third-party authentication or other similar authentication). Alternatively, idempotency can be implemented by the local container manager 710 (such as through idempotency checks 762 and 763), which may reference the container identifier 731, serial number, hash of the container payload 732, or other similar unique identifier of the container package 730, thereby preventing the instantiation of such a container package at a subsequent time. Container packages that satisfy such idempotency and priority checks are provided to the container creation service 610 for instantiation, and processes are executed therein, which, as previously described, can be maintained on node 110.

[0059] According to one aspect, containers use metadata such as sequence numbers, acknowledgment numbers, timestamps, or other ordering data to ensure they are received and processed sequentially. Containers can be sent individually, in batches, in groups with a specific order, or otherwise distributed to destinations such as host computing environment 110. During such distribution, ordering instructions are provided, such as encoded information, individually transmitted messages, processing instructions, location-based ordering, environment-based ordering, identity-based ordering, etc. Generation and processing associated with priority matrix 750 process this data and examine additional factors to determine the order and timing of these container instantiations and instruct them on the local container manager 710 or other relevant components on host computing environment 110.

[0060] In many transactional sequences, rollback is necessary when a failure occurs. The prioritization matrix 750 also has the capability to support rollback mechanisms for recovery from failures. Such rollbacks can be initiated from external sources (such as a container management system, another privileged container, or as part of a policy file) or locally determined, based on policies, configurations, metadata analysis, etc. As indicated, the prioritization matrix may depend on a transaction management system, which may run locally on host computing environment 110 or remotely on another node. The prioritization matrix 750 may depend on components such as a kernel transaction manager, a transaction-enabled file system, and a transaction-enabled database. These components enable the prioritization matrix 750 to implement certain transactional operations for ordered and / or real-time processing across multiple containers. These transactional operations can be atomic, consistent, isolated, or persistent. For example, when a batch of instructions for processing financial transactions with a given host computing environment 110 is sent using a partially privileged container, the prioritization matrix 750 can determine that these instructions must be executed sequentially to ensure that the financial transactions produce the results expected by the customer and the bank operator. As part of the execution and logging of these financial transactions, the prioritization matrix 750 monitors the transaction log and ensures its integrity. When a transaction is completed, the prioritization matrix 750 can signal to the host computing environment 110 or relevant components on related remote nodes (such as container management systems 780 or 790). The order of operations for determining execution, rollback, and other transaction processing activities can be achieved through the prioritization matrix 750, the local container manager 710, the container creation service 610, or any combination thereof.

[0061] Go to Figure 8The exemplary flowchart 800 illustrates a series of exemplary steps through which a partially privileged container executes processes that can selectively influence the underlying host computing environment. Initially, at step 810, a process executing within the partially privileged container initiates an action, such as modifying a file, installing a component, changing system attributes (such as setting a clock), or other similar actions. Subsequently, at step 815, an operating system component executing within the container's virtual computing environment compares the privilege level at which the process is currently executing (e.g., by referencing the user token of the user executing the process) with the privilege level required to execute the action initiated by the process at step 810. If, at step 820, the process does not execute the action with a sufficient privilege level, the process is prevented from executing such an action by the operating system component executing within the container's context, as shown in step 825, and the related processing terminates at step 875. Conversely, if, at step 820, the process is executed with a sufficient privilege level, the processing proceeds to step 830, where it is determined whether the action initiated in step 810 will affect the underlying host computing device, as defined above. If it is determined at step 830 that the action initiated in step 810 is executed only within the context of the container computing environment, the process proceeds to step 855. The action is executed within the context of the container computing environment, resulting in one or more modifications being recorded in the sandbox. As described above, these modifications are only accessible from within the container and do not affect the host computing environment. Conversely, if it is determined at step 830 that the action is being executed on the host computing device, the process proceeds to step 835, where the host operating system kernel is able to determine whether the action should be allowed. As previously described, such a determination involves querying a container-centric service (such as the container creation service) at step 835 to determine whether the action is allowed. This query is performed as part of an existing kernel mechanism by which the kernel allows or denies actions based on privileges, access control lists, etc., including existing kernel mechanisms. At step 840, in response to the operating system kernel query at step 835, the container creation service references a container definition file or other description of the allowed and / or denied actions.

[0062] Based on the information obtained from the container creation service, at step 845, the kernel decides whether to allow or deny the action on the host. If the kernel allows the action at step 845, the action is executed on the host at step 850, and the related processing ends at step 875. Conversely, if the kernel disallows the action at step 845, the action is executed within the context of the container computing environment using relevant overrides, and is stored in a sandbox at step 855.

[0063] At the subsequent point, the container is terminated, as shown in step 860. According to one aspect, at step 865, it is determined whether any changes made within the container's context should be persisted to the host. As previously stated, such a determination can be based on verification that the changes within the container did not introduce instability, or were executed correctly or otherwise valid. If, at step 865, the changes are not persisted to the host, the relevant processing ends at step 875. Conversely, if, at step 865, the changes are to be persisted to the host, the processing proceeds to step 870, and a transaction from the sandbox (such as an NTFS transaction and other similar transactions) is executed on the host to persist the changes to the host, and then the relevant processing ends at step 875.

[0064] Go to Figure 9 The exemplary flowchart 900 illustrates a series of exemplary steps that can be performed as part of the instantiation of a container (such as a container received from a remote container management service) that utilizes a partially privileged container to distribute changes to host nodes, such as updates, patches, installation of executable instructions, and other similar changes. Initially, at step 910, a container package and / or container policy is received from the remote container management service. Subsequently, at step 915, if a container policy was received at step 910, such a container policy is retained in the policy store. The received container policy may modify, replace, or otherwise affect a previously received container policy already in the policy store, and in such an instance, at step 920, such another container policy can be updated or removed based on the received container policy. At step 925, if a container package was received at step 910, such a container package can be retained in a container queue or in another similar set of received containers.

[0065] As previously mentioned, the priority matrix can represent the interaction between prerequisites and the policies associated with containers already in the queue and the containers themselves, such as describing the priority of container instantiation given multiple different prerequisite scenarios. At step 930, such a priority matrix is ​​updated based on the policy storage updated at step 920 and the container queue updated at step 925. The related processing can then terminate at step 970.

[0066] Alternatively, the process proceeds to step 935, or begins from step 935, because step 935 does not require the receipt of the container package and / or container policy at step 910 to be triggered. At step 935, the container package is selected for instantiation. As part of the selection or instantiation of the container, a priority check is performed, such as at step 940. More specifically, at step 940, any prerequisites enumerated for the instantiation of the container (such as prerequisites that may be specified by the corresponding container policy) or container metadata (such as container definition files) are evaluated, and if these prerequisites are not met, or if it is determined at step 945 that there are other containers with higher priority, then the currently selected container package is not instantiated, and the process returns to step 935. Conversely, if it is determined at step 945 that the prerequisites are met, or there are no other containers with higher priority, then the selected container is instantiated.

[0067] According to one aspect, in addition to performing priority checks or as an alternative, one or more idempotency checks may also be performed. Figure 9 In the exemplary flowchart 900 shown, at step 950, it is determined whether the container to be instantiated is idempotent. As previously described, such determination is based on proof or other similar verifiable indication that the container is idempotent and that processes executing within such a container will only affect the host computing environment in a manner that does not affect the host computing environment if the container is unintentionally instantiated and its processes are executed multiple times. If the container is not verified to be idempotent at step 950, an idempotency check is performed at step 955. Such an idempotency check includes one or more of the following: performing a hash of the container payload, checking the container identifier, or other similar operations by which the container can be uniquely identified for comparison with containers that have been previously instantiated and executed correctly. If at step 960, based on the idempotency check of step 955, it is determined that the selected container has been previously instantiated and that processes within such a container have been fully executed, then the process returns to step 935, and a different container package is selected. Conversely, if at step 960 it is determined that the container has not been previously instantiated, or that the previous instantiation of the container has not been completed, such as due to a container crash, exit, or otherwise improper termination, the process proceeds to step 965, where the container selected at step 935 is instantiated. The relevant processing then ends at step 970.

[0068] Go to Figure 10An exemplary computing device 1000 is illustrated, which can perform some or all of the mechanisms and actions described above. The exemplary computing device 1000 may include, but is not limited to, one or more central processing units (CPUs) 1020, system memory 1030, and a system bus 1021 that couples various system components, including system memory, to the processing unit 1020. The system bus 1021 can be any of several types of bus architectures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of various bus architectures. The computing device 1000 may optionally include graphics hardware, including but not limited to a graphics hardware interface 1060 and a display device 1061, which may include a display device capable of receiving touch-based user input, such as a touch-sensitive or multi-touch-enabled display device. Depending on the specific physical implementation, one or more of the CPU 1020, system memory 1030, and other components of the computing device 1000 may be physically located in the same location, for example, on a single chip. In such a case, some or all of the system bus 1021 may simply be silicon pathways within a single chip structure, while Figure 10 The illustrations in the text may simply be symbols used for ease of explanation.

[0069] The computing device 1000 also typically includes computer-readable media, which may include any available media accessible by the computing device 1000, and includes volatile and non-volatile media, as well as removable and non-removable media. By way of example, and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media includes media implemented in any method or technology for storing computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other media that can be used to store desired content and is accessible by the computing device 1000. However, computer storage media does not include communication media. Communication media typically embodies other data in computer-readable instructions, data structures, program modules, or modulated data signals (e.g., carrier waves or other transmission mechanisms), and includes any content delivery media. By way of example, and not limitation, communication media includes wired media (e.g., wired networks or direct wired connections) and wireless media (e.g., acoustic, RF, infrared, and other wireless media). Any combination of the above should also be included within the scope of computer-readable media.

[0070] System memory 1030 includes computer storage media in the form of volatile and / or non-volatile memory (e.g., read-only memory (ROM) 1031 and random access memory (RAM) 1032). Basic input / output system 1033 (BIOS), containing basic routines that facilitate the transfer of content between components within computing device 1000, such as those typically stored in ROM 1031 during startup. RAM 1032 typically contains data and / or program modules readily accessible and / or currently in operation by processing unit 1020. This is by way of example and not limitation. Figure 10 The diagram illustrates the operating system 1034, other program modules 1035, and program data 1036.

[0071] The computing device 1000 may also include other removable / non-removable, volatile / non-volatile computer storage media. This is merely an example. Figure 10 The illustration depicts a hard disk drive 1041 that can be read from or written to from a non-removable, non-volatile magnetic medium. Other removable / non-removable, volatile / non-volatile computer storage media that can be used with the exemplary computing device include, but are not limited to, magnetic tape cassettes, flash memory cards, digital multifunction disks, digital video tapes, solid-state RAM, solid-state ROM, and other computer storage media defined and described above. The hard disk drive 1041 is typically connected to the system bus 1021 via a non-volatile memory interface such as interface 1040.

[0072] The above discussion and Figure 10 The driver and its associated computer storage medium illustrated in the diagram provide storage for computer-readable instructions, data structures, program modules, and other data for the computing device 1000. For example, in... Figure 10 In the illustration, hard disk drive 1041 is shown storing operating system 1044, other program modules 1045, and program data 1046. Note that these components may be the same as or different from operating system 1034, other program modules 1035, and program data 1036. The different numbering of operating system 1044, other software modules 1045, and program data 1046 indicates that they are at least different copies.

[0073] Computing device 1000 can operate in a networked environment using a logical connection to one or more remote computers. Computing device 1000 is illustrated as being connected to a general network connection 1051 (to network 1070) via a network interface or adapter 1050, which in turn connects to a system bus 1021. In a networked environment, program modules or portions thereof, or their peripherals, depicted relative to computing device 1000, can be stored in the memory of one or more other computing devices communicatively coupled to computing device 1000 via general network connection 1061. It should be understood that the network connections shown are exemplary, and other means of establishing communication links between computing devices can be used.

[0074] Although described as a single physical device, the exemplary computing device 1000 can be a virtual computing device, in which case the functionality of the aforementioned physical components (e.g., CPU 1020, system memory 1030, network interface 1040, and other similar components) can be provided by computer-executable instructions. Such computer-executable instructions can execute on a single physical computing device or can be distributed across multiple physical computing devices, including dynamically across multiple physical computing devices, such that the specific physical computing device hosting such computer-executable instructions can dynamically change over time depending on needs and availability. In the case where the exemplary computing device 1000 is a virtualized device, the underlying physical computing device hosting such a virtualized computing device may itself include physical components similar to those described above and operating in a similar manner. Furthermore, virtual computing devices can be utilized in multiple layers, with one virtual computing device executing within the construction of another virtual computing device. Therefore, as used herein, the term "computing device" refers to a physical computing device or a virtualized computing environment, including virtual computing devices, where computer-executable instructions can be executed in a manner consistent with those executed on a physical computing device. Similarly, as used herein, the term referring to the physical components of a computing device refers to those physical components or their virtualizations that perform the same or equivalent functions.

[0075] As a first example, the above description includes a computing device comprising: one or more processing units; and one or more computer storage media, the one or more computer storage media including computer-executable instructions, which, when executed by the processing units, cause the computing device to: instantiate a container virtual computing environment separate from the host computing environment, the container virtual computing environment being instantiated on the host computing environment; execute a process within the container virtual computing environment at a first privilege level, and as part of the execution, the process performs a first action that modifies aspects of the first computing environment, the first action being executable by the process executing at the first privilege level; and prevent the first action from modifying a first aspect of the host computing environment by the operating system of the host computing environment. Regarding the computing environment; and performing a first action in a container virtual computing environment to modify a first computing environment aspect of the container virtual computing environment, such that a process executing within the container virtual computing environment perceives that the first action has been completed, while a process executing within the host computing environment perceives that the first action has not yet been completed; wherein the blocking is based on metadata associated with the container virtual computing environment, which indicates that a second action is allowed to be executed to modify a second computing environment aspect of the host computing environment, the second action being performed by a process executing within the container virtual computing environment and modifying the second computing environment aspect; and wherein performing the first action in the container virtual computing environment is based on blocking the first action from modifying the first computing environment aspect of the host computing environment.

[0076] The second example is the computing device of the first example, wherein the first computing environment aspect that prevents the first action from modifying the host computing environment is executed by the operating system of the host computer environment in a manner similar to that in the case where the operating system of the host environment has determined that the first action cannot be executed by a process executing at the first privilege level.

[0077] The third example is the computing device of the first example, wherein performing the first action in the container virtual computing environment includes: modifying an aspect of the first computing environment in the overlay, and storing the modified aspect of the first computing environment in a sandbox on the host computing environment.

[0078] The fourth example is the computing device of the first example, wherein storing the modified first computing environment aspect in a sandbox includes: recording one or more transactions in the sandbox.

[0079] The fifth example is a computing device of the first example, wherein one or more computer storage media include additional computer-executable instructions, which, when executed by a processing unit, cause the computing device to: perform a first action in a host computing environment in the event that the container virtual computing environment is terminated, thereby modifying a first computing environment aspect of the host computer environment.

[0080] The sixth example is the computing device of the first example, wherein the execution of a process having a container virtual computing environment includes at least one step of a multi-step transaction, the multi-step transaction including other steps, the other steps being executed by one or more processes executing within one or more other container virtual computing environments; and wherein further instantiation of the container virtual computing environment is further triggered by a transaction manager based on the success of a previous other container virtual computing environment among one or more other container virtual computing environments.

[0081] The seventh example is the computing device of the first example, wherein the metadata associated with the container virtual computing environment specifies that modifications to files within the first part of the file system are permitted to be performed on the host computing environment by a process executing within the container virtual computing environment.

[0082] The eighth example is the computing device of the first example, wherein the instantiation of the container virtual computing device is performed only after it is determined that the enumerated prerequisites associated with the container virtual computing environment have been met by the host computing environment.

[0083] The ninth example is the computing device of the eighth example, wherein the container package received by the computing device from the remote container management system includes: the enumerated prerequisites and metadata associated with the container virtual computing environment.

[0084] The tenth example is the computing device of the first example, wherein a container virtual computing environment is selected for instantiation based on policy information received by the computing device from a remote container management system.

[0085] The eleventh example is the computing device of the first example, wherein the instantiation of the container virtual computing device is performed only after an idempotency check associated with the container virtual computing environment is executed.

[0086] Example 12 is the computing device of Example 11, wherein the idempotency check includes: verifying proof of idempotency associated with the container virtual computing environment.

[0087] The thirteenth example is the computing device of the eleventh example, wherein the idempotency check includes determining that the container virtual computing environment has not been previously instantiated to completion and that the process has not previously been executed to completion within the container virtual computing environment.

[0088] The fourteenth example is a method for providing additional restrictions on a privileged container virtual computing environment, the method comprising: instantiating a privileged container virtual computing environment separate from a host computing environment, the privileged container virtual computing environment being instantiated on the host computing environment; executing a process within the privileged container virtual computing environment at a first privilege level, the process performing, as part of the execution, a first action modifying an aspect of the first computing environment, the first action being executable by the process executing at the first privilege level; the first action being prevented by the operating system of the host computing environment from modifying the first computing environment aspect of the host computing environment; and executing the first action in the container virtual computing environment, thereby modifying the first computing environment aspect of the container virtual computing environment such that the process executing in the container virtual computing environment perceives that the first action has been completed, while the process executing in the host computing environment perceives that the first action has not yet been completed; wherein the prevention is based on metadata associated with the container virtual computing environment indicating that a second action is permitted to be executed to modify a second computing environment aspect of the host computing environment, the second action being executed by the process executing in the container virtual computing environment and modifying the second computing environment aspect; and wherein the execution of the first action in the container virtual computing environment is based on preventing the first action from modifying the first computing environment aspect of the host computing environment.

[0089] The fifteenth example is a system comprising: a first computing device that executes computer-executable instructions implementing a first container management system; and a second computing device that executes computer-executable instructions implementing a local container manager, the local container manager performing the steps of: receiving a first container package from the first computing device, the first container package including a first container definition file; and receiving a first policy from the first computing device, the first policy influencing when the second computing device instantiates a container virtual computing environment based on the first container package; wherein the second computing device refers to the first container definition file to determine whether a process executing within the container virtual computing environment is permitted to perform a first action that modifies a first computing environment aspect of a host computing environment, on which the container virtual computing environment is instantiated.

[0090] The sixteenth example is a system of the fifteenth example, wherein a first policy defines prerequisites for a second computing device to instantiate a container virtual computing environment based on a first container package; and wherein the location container manager further performs additional steps, the additional steps including: providing the first container package to a container creation service executed on the second computing device to instantiate the container virtual computing environment when it is determined that the prerequisites have been met.

[0091] Example 17 is the system of Example 15, in which the location container manager performs additional steps, including performing an idempotency check associated with the container virtual computing environment.

[0092] Example 18 is a system of Example 17, wherein the idempotency check includes a proof of idempotency verification, and the first container package includes a proof of idempotency.

[0093] Example 19 is the system of Example 17, where the idempotency check includes determining that the container virtual computing environment has not been previously instantiated to completion.

[0094] The twentieth example is a system of the fifteenth example, wherein the second computing device executes further computer-executable instructions, the execution of which includes the steps of: instantiating a container virtual computing environment; executing a process within the container virtual computing environment at a first privilege level, wherein, as part of the execution, the process performs a first action, wherein the first action can be performed by the process executing at the first privilege level; preventing the first action from modifying a first computing environment aspect of the host computing environment by the operating system of the host computing environment; and executing the first action in the container virtual computing environment, thereby modifying the first computing environment aspect of the container virtual computing environment such that the process executing within the container virtual computing environment perceives that the first action has been completed, while the process executing within the host computing environment perceives that the first action has not yet been completed; wherein the execution of the first action in the container virtual computing environment is based on preventing the first action from modifying the first computing environment aspect of the host computing environment.

[0095] As can be seen from the above description, mechanisms for providing fine-grained, selectable, partially privileged container virtual computing environments have been proposed. Given the many possible variations of the subject matter described herein, we claim all embodiments that may fall within the scope of the following claims and their equivalents as part of the invention.

Claims

1. A computing device for a virtualized environment, comprising: processor; as well as Memory, coupled to the processor, includes computer-executable instructions that, when executed, perform operations to: A process is executed within a container virtual computing environment, which is implemented in a host computing environment, wherein the process is executed according to a first privilege level and performs a first action aimed at modifying aspects of a first computing environment, which are implemented in both the container virtual computing environment and the host computing environment. The operating system of the host computing environment prevents the first action from modifying the first computing environment aspect of the host computer environment, wherein the blocking is based on metadata associated with the container virtual computing environment, the metadata indicating that the second action may be allowed to be executed to modify the second computing environment aspect of the host computing environment; as well as The first action is performed in the container virtual computing environment, thereby modifying the first computing environment aspect of the container computing environment such that a process executing in the container virtual computing environment perceives that the first action has been completed, while a process executing in the host computing environment perceives that the first action has not been completed, wherein the execution of the first action in the container virtual computing environment is based on preventing the first action from modifying the first computing environment aspect of the host computing environment.

2. The computing device of claim 1, wherein preventing the first action from modifying the first computing environment aspect of the host computing environment is performed by the operating system of the host computer environment in such a manner as if the operating system of the host computing environment had determined that the first action could not be performed by a process executing at the first privilege level.

3. The computing device of claim 1, wherein performing the first action in the container virtual computing environment comprises: Modify aspects of the first computing environment in the overlay layer, and store the modified aspects of the first computing environment in a sandbox on the host computing environment.

4. The computing device of claim 3, wherein storing the modified first computing environment aspect in a sandbox on the host computing environment comprises: One or more transactions are recorded in the sandbox.

5. The computing device of claim 1, wherein the computer-executable instructions further perform operations to: In the event that the container virtual computing environment terminates, the first action is performed in the host computing environment, thereby modifying the first computing environment aspect of the host computing environment.

6. The computing device of claim 1, wherein the process performs at least one step of a multi-step transaction, the multi-step transaction including other steps, said other steps being performed by one or more processes executing within one or more other container virtual computing environments; and The instantiation of the container virtual computing environment is triggered by the transaction manager based on the success of a previous container virtual computing environment among the one or more other container virtual computing environments.

7. The computing device of claim 1, wherein the metadata associated with the container virtual computing environment specifies that modifications to files within a first portion of the file system are permitted to be performed on the host computing environment by a process executing within the container virtual computing environment.

8. The computing device of claim 1, wherein the container virtual computing environment is instantiated after it is determined that the enumerated prerequisites associated with the container virtual computing environment have been satisfied by the host computing environment.

9. The computing device of claim 8, wherein the container package received by the computing device from a remote container management system comprises: The enumerated prerequisites and the metadata associated with the container virtual computing environment.

10. The computing device of claim 1, wherein the container virtual computing environment is selected for instantiation based on policy information received by the computing device from a remote container management system.

11. The computing device of claim 1, wherein the container virtual computing environment is instantiated after performing an idempotency check associated with the container virtual computing environment.

12. The computing device of claim 11, wherein the idempotency check comprises: Verify the proof of idempotency associated with the container virtual computing environment.

13. The computing device of claim 11, wherein the idempotency check comprises: It is determined that the container virtual computing environment has not been previously instantiated to completion, and the process has not previously been executed to completion within the container virtual computing environment.

14. A method for a virtualized environment, the method comprising: A process is executed within a privileged container virtual computing environment, which is implemented in a host computing environment, wherein the process is executed according to a first privilege level and performs actions aimed at modifying aspects of the computing environment, wherein a first instance of the computing environment aspect is implemented in the privileged container virtual computing environment and a second instance of the computing environment aspect is implemented in the host computing environment; The second instance is determined by the operating system kernel of the host computing device to be such that the privilege level does not allow the action to modify aspects of the computing environment, wherein the determination includes evaluating a container definition file implemented in the host computing environment, the container definition file identifying the functions or actions that the process is allowed to perform in the host computing environment; and In response to the determination, the first instance of the computing environment in the execution of the action is modified based on the privilege level.

15. A system for a virtualized environment, comprising: A first computing device, the first computing device executing computer-executable instructions for implementing a first container management system; as well as A second computing device executes computer-executable instructions that implement a local container manager, the local container manager executing the following steps: Receive a first container package from the first computing device, the first container package including a first container definition file; as well as The first policy is received from the first computing device, and the first policy affects when the second computing device instantiates a container virtual computing environment based on the first container package. The second computing device refers to the first container definition file to determine whether a process executing within the container virtual computing environment is allowed to perform a first action that modifies a first computing environment aspect of the host computing environment, wherein the container virtual computing environment is instantiated on the host computing environment, and the first computing environment aspect is implemented in both the container virtual computing environment and the host computing environment.

16. The system of claim 15, wherein the first strategy defines the prerequisites for the instantiation of the container virtual computing environment by the second computing device based on the first container package; and The steps performed by the local container manager include: If the prerequisites have been met, the first container package is provided to the container creation service executed on the second computing device to instantiate the container virtual computing environment.

17. The system of claim 15, wherein the local container manager further performs the step of: Perform an idempotency check associated with the container virtual computing environment.

18. The system of claim 17, wherein the idempotency check includes a proof of idempotency verification, and the first container package includes the proof of idempotency.

19. The system of claim 17, wherein the idempotency check comprises: It was determined that the container virtual computing environment had not been previously instantiated to completion.

20. The system of claim 15, wherein the second computing device executes additional computer-executable instructions, the execution of which includes the following steps: Instantiate the container virtual computing environment; The process is executed within the container virtual computing environment at a first privilege level, and as part of the execution, the process performs the first action, wherein the first action can be performed by the process executing at the first privilege level; The operating system of the host computing environment prevents the first action from modifying the first computing environment aspect of the host computer environment; as well as The first action is performed in the container virtual computing environment, thereby modifying the first computing environment aspect of the container computing environment such that the process executing in the container virtual computing environment perceives that the first action has been completed, while the process executing in the host computing environment perceives that the first action has not yet been completed. The execution of the first action in the container virtual computing environment is based on preventing the first action from modifying the first computing environment aspect of the host computing environment.

Images