Patent Description:
Operating systems in computing systems may use hardware resource partitioning. A popular resource partitioning technique is virtual machine-based virtualization, which enables a higher density of server deployments, ultimately enabling scenarios such as cloud computing. Recently, container-based (sometimes referred to as namespace based) virtualization has offered new promises including higher compatibility and increased density. Higher compatibility means lower costs of software development. Higher density means more revenue for the same cost of facilities, labor and hardware.

However, typical container-based solutions share aspects of their operating system with the host computing system. This may include files, configuration, policy, user accounts, user data stores which store user data, and so forth. In some implementations, the user data stores (and the information contained therein) are shared between the host computing system. When a container is created for a user in the host computing system the container will include a container operating system and a user data store. This will extend the users environment in the container to install and run applications, process data, et cetera. The user will get the benefit of increased application compatibility, and/or increased isolation which protects user data and the host computing system from attack software.

Various challenges may be encountered in such a system. For example, some systems may wish to not allow all of the user data on the host operating system into the container operating system. In some environments, legacy applications make assumptions about data compatibility, to ensure these applications can run as expected, user data must meet these assumptions. In some environments, applications want to access as much information as possible about the user as this is a valuable commodity for purposes of marketing and advertising. However, the user wishes to constrain this information to improve privacy when running specific applications. In some environments, the user wishes to shield themselves from accidental download and execution of malware and attack software.

The subject matter claimed herein is not limited to aspects that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate a few exemplary technology areas where some aspects described herein may be practiced. <CIT> discloses a secure challenge-response virtualization system including a computer having a memory divided into at least a first and a second logical partition, where the first partition is operative to receive a challenge from an entity, and a challenge/response manager configured with the second partition, where the first partition is configured to provide the challenge to the challenge/response manager configured with the second partition, and where the challenge/response manager is configured to generate a response to the challenge and provide the response to the first partition.

Aspects of the present invention are provided in the accompanying claims.

One aspect illustrated herein includes a method that may be practiced in an environment comprising a host system with a first operating system and a second operating system. The first operating system and the second operating system are separated by a security boundary. The system includes an at least partially anonymized, containerized operating system configured to anonymize an authorized user at the first operating system by hiding information for the authorized user from the second operating system. The method includes acts for the second operating system accessing resources from a service. The method includes sending an anonymized request, for an anonymized user corresponding to the authorized user, for resources , through a broker. A request for proof indicating that the anonymized user is authorized to obtain the resources is received from the broker. As a result, a request is sent to the first operating system for the proof that the anonymized user is authorized to obtain the resources. Proof is received from the first operating system, based on the anonymized user being associated with the authorized user, that the anonymized user is authorized to obtain the resources. The proof is provided to the broker. As a result, the resources are obtained from the service.

In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific aspects which are illustrated in the appended drawings. Understanding that these drawings depict only typical aspects and are not therefore to be considered to be limiting in scope, aspects will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

Aspects described herein implement a containerized based configuration approach that anonymizes user information, but still allows an anonymized containerized operating system to access resources that require an authorized user to request them. In particular, a container operating system may be created using configuration, files and other elements from another operating system, such as a host operating system where the container operating system re-uses certain user elements from the host operating system that have been anonymized when exposed in the container operating system. However ordinarily, this creates situations where a user using the container operating system may be unable to access certain resources as the user is not properly identified in the container operating system such that the user may not be able to provide the appropriate credentials to be able to access certain resources. Aspects herein can implement functionality to nonetheless allow such implementations to access those certain resources.

Illustrating now additional details, in a containerized based configuration approach, various hierarchical configuration layers are used to configure entities such as containerized operating systems. Additionally, filters can be applied to configuration layers to accomplish a desired configuration for an entity. In particular, an entity, such as an operating system kernel, can have different portions of different configuration layers exposed to it such that configuration from different configuration layers can be used to configure the entity, but where the entity operates as if it is running in its own pristine environment, even though it is using physical elements from the host operating system. Thus, a given configuration layer could be used as part of a configuration for multiple different entities thus economizing storage, network, and compute resources by multi-purposing them for different container operating systems.

A containerized entity is an isolated runtime that uses operating system resource partitioning. This may be an operating system using hardware-assisted virtualization such as a virtual machine. It may be an operating system using operating-system-level virtualization with complete namespace isolation such as a container. It may be an isolated application running on an operating system using partial namespace isolation (e.g., filesystem and configuration isolation).

As noted above, generally virtual machine-based virtualization provides the same isolation as physical machines, while offering flexibility and density. Container-based virtualization provides an even lighter weight virtualization environment, improved compatibility and lower operational costs by sharing immutable physical portions of an operating system. Today, many server scenarios are adopting containers both in the enterprise and in the cloud. While enterprise and cloud computing reap the benefits, containers also hold promise in client. Beyond providing a functional software development environment, containers will provide the next generation of features around security and isolation. However, as noted above, in the client scenarios, individual credential information may be needed to access certain resources.

Containers achieve their lightweight attributes through sharing aspects of the operating system. This may include sharing files and folders, sharing configuration, sharing devices, and sharing operating system services. In some environments, such as friendly multi-tenant hosting, aspects can de-duplicate overlapping processes, enabling even more efficient resource utilization. Files, processes and objects are all contributors to process overlap.

There are methods to share processes and information between containers and the host. However, aspects need to ensure a user in one environment can clearly extend their usage into another environment. For example, a user on the host should be able to seamlessly access files and seamlessly run applications in a container or vice versa. This also may apply across containers and not directly impact the host. Previously, a generic user would be created in a container and the user at the host accesses the container as that generic user. This may include various aspects of overhead such as signing with different credentials, managing user settings and preferences and so forth. A user as illustrated herein is an entity that is external to the host system or an equivalent of an external entity. A user is not an operating system service, although an operating system service can be implemented to act as a proxy for a user. Note that in some aspects, external machines or external processes external to a host system which hosts a user may be users.

Aspects illustrated herein may address one or more challenges to extending the user object. <FIG> illustrates a system <NUM>. The system <NUM> includes a host operating system <NUM> and a container operating system <NUM>-<NUM>. Note that typically several container operating systems will be implemented on the system <NUM>. Indeed, efficiency is obtained by several container operating systems sharing elements of the host operating system <NUM>.

As illustrated in <FIG>, there is a security boundary <NUM> between the host operating system <NUM> and the container operating system <NUM>-<NUM>. Although not shown, there are security boundaries between different container operating systems (referred to herein generically as <NUM>) as well. When user information is stored in a secure, isolated location (i.e., the user data store <NUM>-<NUM>) in the host operating system <NUM> and shared with multiple isolated container operating systems <NUM>, aspects may include functionality, as illustrated in more detail below, to ensure that the user information is not spoofed or tampered with.

Alternatively or additionally, aspect may include functionality to Ensure stateful transactions are not repudiated.

Alternatively or additionally, aspect may include functionality to ensure that information is not disclosed or leaked across the various security boundaries.

Alternatively or additionally, aspect may include functionality to mitigate attempts to escalate service across the security boundary <NUM> or denial of service across the security boundary <NUM>.

To enable a more flexible approach to cross-container user access, some aspects determine a root operating system (shown below as a 'first operating system') (e.g., host operating system <NUM>), where a given user's information is stored and tracked. From this root, the user object is extended to other operating systems (shown below as a 'second operating system'), e.g., container operating systems, such as the container operating system <NUM>-<NUM>. Note, in some aspects, a root operating system may be a container operating system, and the other operating system may be a different container operating system. To maintain the security boundary <NUM> between operating systems, the user object is abstracted; and where applicable, the user object is anonymized.

The following now illustrates details with respect to an architecture that may be used to implement some aspects of the invention.

There are many operating system processes, services and objects that may need to share information between the container operating system <NUM>-<NUM> and the host operating system <NUM>. Benefits to better sharing include: more efficient operation, higher density, or using a trusted broker to achieve better security and isolation. Information about users such as a user object may also be shared. This extends the user model across operating system instances, offering convenience in access, all while maintaining isolation. In some aspects, such as running a secure browser application, this may be an important method to providing persistence of user data such as favorites, home pages and other personalized settings. In other aspects similar user data may be persisted, for example if the user was running a word processing application, the documents he or she was writing could be locally saved. In some aspects the user will want to remain anonymous. Here, the root operating system may create a map between the local user and the user data in the remote operating system (such as a container). This map may include certain specific data such as an access level to ensure seamless access to files and applications in the remote operating system.

Aspects may include functionality to achieve the benefits of user access while maintaining isolation. In some scenarios, container operating systems <NUM> are used to isolate one or more applications from a pristine, secure host operating system <NUM>. (Note that while the examples herein are for the most part generally directed to isolating container operating systems from host operating systems, it should be appreciated that aspects of the invention may alternatively or additionally isolate different container operating systems from each other. ) These applications, for example, could be used to access resources, such as Internet resources (such as websites and files) from locations in which they may, accidently or intentionally, download malware or attack software as well. In this environment, the container operating system <NUM>-<NUM> is assumed to be insecure, and the host operating system <NUM> is behaving as the trusted broker and managing the user data. To achieve this, some aspects map the user objects between the host operating system <NUM> and the container operating system <NUM>-<NUM> (or container operating system to container operating system in the container operating systems <NUM>) in a way that is secure and unexploitable across the security boundary <NUM> (or container operating system to container operating system security boundaries). Aspects may alternatively or additionally filter user data across the security boundary <NUM>.

The architecture shown in <FIG> illustrates one example aspect and how it impacts the relationship between the host operating system <NUM> and the container operating system <NUM>-<NUM>. However, aspects of the invention may also apply between any two entities that share user access, whether they be a host operating system, a container operating system, a network node (such as a web proxy or firewall), etc..

<FIG> is an architecture diagram with components as explained below. Note that the operating system instances are typically connected to share data. This may be a network connection, a named pipe, an RPC channel or something similar. Note that the filter components (generally referred to as <NUM>), monitor component (generally referred to as <NUM>), and enforcement component (generally referred to as <NUM>) are optional on a remote operating system (such as the container operating system <NUM>-<NUM>). Additionally, some aspects may not have these components.

The host operating system <NUM> is an operating system that has the capabilities to host additional operating system instances such as container operating systems <NUM>. The boundary between the host operating system <NUM> and one or more container operating systems <NUM> is a security boundary <NUM>.

The container operating system <NUM>-<NUM> (note that a single container operating system <NUM>-<NUM> is illustrated, but many aspects will implement multiple container operating systems, referred to generally as <NUM>) is an entity which is an operating system that runs one or more applications <NUM> that require isolation from the host operating system <NUM>. The container operating system <NUM>-<NUM> may also or alternatively be configured to meet additional unique requirements to achieve compatibility including running a different operating system version, having a different configuration and so forth.

OS services <NUM>-<NUM> and <NUM>-<NUM> (generally referred to as <NUM>) are components that run the operating system services to support applications. Some operating systems refer to system services as "daemons".

The user data stores <NUM>-<NUM> and <NUM>-<NUM> (generally referred to as <NUM>) are components that store user data such as username and the metadata that is associated with a user. This metadata contains access levels, settings, files and other content. Filter configuration is also stored here. The monitoring and enforcement components (generally referred to as <NUM> and <NUM>) may store logging here to tightly associate with the user. This could include transaction information, timestamps, and how user information is mapped into a remote OS instance. Some operating systems may store credentials here; other operating systems may have a credential vault that they access (not illustrated). Note that the user data store may store user data that is not specifically intended to be used on the root OS; as the container operating system <NUM>-<NUM> may be a different operating system with a different schema than the host operating system <NUM>.

The security subsystems <NUM>-<NUM> and <NUM>-<NUM> (generally referred to as <NUM>) are components that track the identity of the remote endpoints (e.g. container operating system <NUM>-<NUM>, host operating system <NUM>, etc.). The security subsystem <NUM> decides what user data to share; and controls the configuration of the filter component <NUM>, monitoring component <NUM>, and enforcement component <NUM>. The security subsystem <NUM> also does other general tasks such as managing the local security policy and tracking user accounts.

The filter components <NUM>-<NUM> and <NUM>-<NUM> (generally referred to as <NUM>) are components that are used to map a user in a root operating system (such as the host operating system <NUM>) into another operating system, such as container operating system <NUM>-<NUM>. Note that in other aspects, a root operating system may be a container operating system and the other operating system may be another container operating system. Based on configuration, a filter component will determine how much data to share.

The monitor components <NUM>-<NUM> and <NUM>-<NUM> (generally referred to as <NUM>) are components that performs monitoring on what information is sent across the security boundary <NUM>. The monitor component <NUM> is configured by the corresponding security subsystems <NUM> and may be informed by the user data stores <NUM>. For additional visibility, the monitor component <NUM> may also have a plug-in model in which the plug-ins provide their data schemas and state machines. The monitor component <NUM> may send alerts to the operating system <NUM> or <NUM> as appropriate if unexpected information or unexpected communication attempts are observed. The monitor component <NUM> may also record what it monitors via telemetry or write it to a log file for future analysis.

The enforcement components <NUM>-<NUM> and <NUM>-<NUM> are components that perform enforcement across the security boundary <NUM> (or other security boundary). In some aspects, the enforcement component (referred to generally as <NUM>) has a set number of resource controls or quality of service metrics for each user that is being monitored. In some aspects, the enforcement component <NUM> may receive alerts from the monitor component <NUM> that unexpected information is being transferred. The enforcement component <NUM> may then determine that the communication across the security boundary <NUM> (or other security boundary) is in violation and stop the communication.

The following now illustrates an operational model, with reference to <FIG>. Here, a concrete example of how a user on the host operating system <NUM> accesses an application and files on the container operating system104-<NUM> is illustrated. In some aspects, the user and the application (e.g., one of the applications in the applications <NUM>-<NUM>) have a need to access a resource <NUM> such as a website (e.g., www. In this example, DNS is demonstrated as a distributed service.

In this scenario, the security subsystem <NUM>-<NUM> in the host operating system has access to the security subsystem <NUM>-<NUM> in the container operating system <NUM>-<NUM>. A John Doe User Object <NUM> is passed through the filter, monitor and enforcement components <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> by the security subsystem <NUM>-<NUM> in the host operating system <NUM> and sent to the container operating system <NUM>-<NUM> to populate the user object stub <NUM> that is in the user data store <NUM>-<NUM> of the container operating system <NUM>-<NUM>. In some aspects, John Doe's username and identity are preserved in the container operating system <NUM>-<NUM>. However, in other aspects, John Doe's user name and identity are anonymized. For anonymization, the filter component <NUM>-<NUM> on the host operating system <NUM> may delete and/or overwrite some of the information when passing it to the user object stub <NUM>. Thus, for example, some information may be completely removed, such that some of the user elements are blank in the user data store <NUM>-<NUM>. In other aspects, a pseudonym or other obfuscation may be used in place of user information in the host operating system <NUM>. For example, instead of a username "John_Doe" being propagated to the user data store <NUM>-<NUM> at the container operating system <NUM>-<NUM>, a username "Brian_Roe" may be propagated to the user data store <NUM>-<NUM>. Note that the user data store <NUM>-<NUM> at the host operating system <NUM> can track pseudonyms correlated with actual user data. Some aspects may implement this tracking functionality to the filter and security subsystem.

When the user object stub <NUM> is populated, John Doe is able to use applications <NUM>-<NUM> and access files (not shown) on the container operating system as he expects. For example, if John Doe was using a web browser application in the container operating system <NUM>-<NUM>, John Doe may be able to access the same favorites that he gets on the host operating system <NUM>.

In a related scenario, John Doe wants to access a resource <NUM>, such as www. The web browser application in the container operating system <NUM>-<NUM> asks the broker service for the broker <NUM> for this website. The broker <NUM> is a web proxy. Then it does a DNS a name lookup for the broker <NUM>, obtaining its IP addresses and it opens a socket connection to the broker <NUM>. Now the web browser in the container operating system <NUM>-<NUM> sends an HTTP get request to the IP address of the broker <NUM> asking to retrieve the request from www. This is received by a broker <NUM>. Note that, the broker <NUM> may be an enterprise web proxy tasked with ensuring that enterprise machines do not access unauthorized external resources or that unauthorized users do not access (either by whitelist or blacklist) certain external resources
The broker <NUM> sends a challenge request back to the web browser in the container operating system <NUM>-<NUM> because, in this example, entities on the network authenticate to the broker <NUM> to have access to the Internet. Upon receiving this broker challenge, the web browser in the container operating system <NUM>-<NUM> queries the security subsystem <NUM>-<NUM> in the container operating system <NUM>-<NUM>. The security subsystem <NUM>-<NUM> in the container operating system <NUM>-<NUM> queries the user data store <NUM>-<NUM> to access the user object stub <NUM>. In some aspects, this information resides in the user object stub <NUM> and the challenge is just answered and access to the resource (i.e., the resource <NUM>) is granted by the broker <NUM>
In other aspects, the information is only in the user data store <NUM>-<NUM> on the host operating system. In this case, the security subsystem <NUM>-<NUM> in the container operating system <NUM>-<NUM> queries the security subsystem <NUM>-<NUM> in the host operating system <NUM> for this information. The information may be provided to the user data store <NUM>-<NUM> in the container operating system (e.g. via being mapped in via the filter <NUM>-<NUM>). Alternatively, the security subsystem <NUM>-<NUM> on the host operating system <NUM> generates a challenge response. This information is then passed to the container operating system <NUM> and associated with the user object stub <NUM>. The web browser in the container operating system <NUM>-<NUM> then gets this information from the security subsystem <NUM>-<NUM> in the container operating system <NUM>-<NUM> and sends it to the broker <NUM> as a response to its challenge. The broker <NUM> then sends the web browser in the container operating system <NUM>-<NUM> a response that authentication is completed. The web browser in the container operating system <NUM>-<NUM> then sends the HTTP get requests to the resource <NUM> and is able to download the web information.

In some implementations, the security subsystem <NUM>-<NUM> negotiates version and data schema for user objects. This may be done by manually looking at the container operating system version or a manifest file to identify a potential list of possible data schemas, or it may be interactive, in which security subsystem <NUM>-<NUM> directly contacts security subsystem <NUM>-<NUM> to share a list of possible data schemas. The best compatibility may be selected using a priority list that is shared as part of the negotiation, or take an approach of a pre-determined highest common denominator of the compatible version negotiation. There may be other approaches such as doing a dynamic analysis of the available data schemas.

In some implementations, the privilege level may differ between the host operating system <NUM> and the container operating system <NUM>-<NUM>, even though the user is mapped. For example, John Doe may be a standard user on the host operating system, but a member of the Administrators group when in the container operating system <NUM>-<NUM>.

It is important to note that in some aspects the broker and the resource may be on the local host. For example, in some aspects, an application running in the container operating system <NUM>-<NUM> may request a resource on host operating system <NUM>. This resource may be a document, a configuration file, or temporary access to a device. In these aspects, authentication occurs locally and access will be granted in a similar mechanism as outlined in <FIG> and described above, but where the broker <NUM> is physically running in the host operating system <NUM> and where the resource <NUM> is at the host operating system. In this way, the application can run in the anonymized context of the container operating system <NUM>-<NUM>, but can access resources in the host operating system <NUM>, including creating, reading, and/or modifying such resources. When the container operating system <NUM>-<NUM> is later deleted, effects of the application running in the container operating system are nonetheless persisted in the resource.

The following now illustrates various methods and method acts that may be performed in some aspects. Reference is made to <FIG>, which illustrates a method <NUM>.

The method <NUM> may be practiced in an environment comprising a host system with a first operating system and a second operating system. The first operating system and the second operating system are separated from each other by a security boundary. The second operating system comprises an at least partially anonymized, containerized operating system configured to anonymize an authorized user at the first operating system by hiding information of the authorized user (e.g., identity and/or other information) from the second operating system. A method includes acts for the second operating system accessing resources from an external service. For example, as illustrated in <FIG>, a method may include entities at the containerized operating system <NUM>-<NUM> accessing resources (such as web pages, files, etc., at the resource <NUM>).

The method includes sending an anonymized request, for an anonymized user corresponding to the authorized user, for resources through a broker (act <NUM>). A request is sent to the broker <NUM> from an application, such as one of the applications <NUM>-<NUM> for resources for resources at the resource <NUM>. Note that the request, in some aspects, may be sent from the application through an intermediate service (not shown) at the container operating system <NUM>-<NUM>. The intermediate service could be any intermediate system that is requesting authorization for an application or service running in the container operating system <NUM>-<NUM>. If that user information resides on the host operating system <NUM>, the host operating system <NUM> has the ability to proxy for the container operating system, enabling the application or service (on behalf of the user in the host operating system <NUM>) to access the resource <NUM>. Alternatively or additionally, the intermediate service could be an authentication proxy to the proxy authority in the host operating system <NUM>. Such requests are sent directly from an application to the broker <NUM>.

The method <NUM> further includes receiving from the broker a request for proof indicating that the anonymized user is authorized to obtain the resources (act <NUM>). The broker <NUM> may ask components at the container operating system <NUM>-<NUM> to provide proof that they are authorized to access the resources at the resource <NUM>. As noted, the components at the container operating system <NUM>-<NUM> may not have this proof readily available due to the authorized user being anonymized to in the container operating system <NUM>-<NUM>.

Thus, as a result, the second operating system sends a request to the first operating system for the proof that the anonymized user is authorized to obtain the resources (act <NUM>). This may be accomplished in a number of different ways, and aspects may include other steps to facilitate this action. For example, an application in the container operating-system <NUM>-<NUM> may contact the OS Services <NUM>-<NUM> and/or the security subsystem <NUM>-<NUM> in the container operating system <NUM>-<NUM> to initiate the request to the host operating-system <NUM> for the proof that the anonymous user is authorized to obtain the resources. In some aspects, the security subsystem <NUM>-<NUM> in the container operating-system <NUM>-<NUM> will query the use of data store <NUM>-<NUM> in the container operating-system <NUM>-<NUM> to attempt to obtain the proof. The container operating-system requesting proof from the host operating-system may include the user data store <NUM>-<NUM> in the container operating-system <NUM>-<NUM> sending a query to one or more of the filter component <NUM>-<NUM>, the monitor component <NUM>-<NUM>, or the enforcement component <NUM>-<NUM>. In an alternative aspect, the security subsystem <NUM>-<NUM> in the container operating-system <NUM>-<NUM> sends a request for the proof to one or more of the filter component <NUM>-<NUM>, the monitor component <NUM>-<NUM>, or the enforcement component <NUM>-<NUM>.

The method further includes receiving the proof from the first operating system, based on the anonymized user being associated with the authorized user, that the anonymized user is authorized to obtain the resources (act <NUM>). This may include, or be enabled, by various actions taken by the first operating-system <NUM>. For example, one or more of the filter component <NUM>-<NUM>, the monitor component <NUM>-<NUM>, or the enforcement component <NUM>-<NUM> may request information from the security subsystem <NUM>-<NUM> in the host operating-system <NUM> to attempt to obtain the proof to be returned to the container operating-system <NUM>-<NUM>. Alternatively or additionally, the security subsystem <NUM>-<NUM> and the host operating-system <NUM> may attempt to obtain information from the user data store <NUM>-<NUM> to attempt to identify if the anonymized user and/or authorized user are authorized to obtain resources from the resource <NUM>. In some aspects, the security subsystem <NUM>-<NUM> will return the appropriate information to the filter component <NUM>-<NUM>, the monitor component <NUM>-<NUM>, or the enforcement component <NUM>-<NUM>, which returns information to the security subsystem <NUM>-<NUM> and the container operating-system <NUM>-<NUM>, where it can be used as appropriate. The container operating system <NUM>-<NUM> is not necessarily in charge of validating the proof, and in some aspects may not be able to interpret the proof.

The method further includes providing the proof to the broker (act <NUM>). The application provides the received proof to the broker <NUM> directly. A secondary service at the container operating-system <NUM>-<NUM> provides the proof to the broker <NUM>. The security subsystem <NUM>-<NUM> provides the proof to the broker <NUM>.

The method further includes, as a result, obtaining the resources from the service (<NUM>). The broker <NUM> forwards the requests for resources to the resource <NUM> to allow the resources to be obtained from the resource <NUM>.

Note that the method may be practiced where the proof that is returned is not necessarily a password are username that enables the broker <NUM> to forward the request to the resource <NUM>, but and rather is simply the proof that the anonymized user at the container operating-system <NUM>-<NUM> matches an authorized user at the first operating-system <NUM> that is authorized to access the resource <NUM>. Thus, the proof may be some type of token or other indicator that is provided from the container operating-system <NUM>-<NUM> to the broker <NUM>.

In some aspects, obtaining the resources from the service is performed as a result of the first operating system providing an indication of the proof to the broker through a channel external to the second operating system. For example, in some aspects the host operating-system <NUM> directly provides the proof to the broker <NUM> allowing the resources to be obtained by the container operating-system <NUM>-<NUM>, and in particular a requesting application at the container operating-system <NUM>-<NUM>.

The method may be practiced where obtaining the resources from the service is performed as a result of the first operating system providing an indication to the broker through a channel external to the second operating system that a retry of the request for the resources by the container operating system should be granted, and wherein the proof provided from the second operating system to the broker comprises a retry of the request for resources.

Aspects include functionality for creating the second operating system from the first operating system by anonymizing some elements of the first operating system in the second operating system, but maintaining some personalized elements of the first operating system (such as location, input language, country, time zone, default browser, etc.) in the second operating system. <FIG> illustrates an example where a filter and/or broker is used to anonymize certain elements from user objects on the first operating system on the second operating system.

Another aspect may include acts to apply a user object in a root operating system (e.g., the host operating system <NUM>) to one or more other operating system instances (e.g., the container operating system <NUM>-<NUM>). Such aspects for a given user object, may track other operating system instances to which a user has access. For each other operating system, aspects track user identities and authorization levels (including applications, services and files).

For a given user object, aspects perform actions to ensure an appropriate level (as defined by some user settings, global administrator defined settings, default settings, or otherwise) of abstraction is applied to transition a security boundary between the root operating system and another operating system instance. In some aspects, this may be implemented in a service scenario, enabling an administrator to access many container instances to change configuration, policy and so forth.

For metadata associated with each user, aspects perform a mapping to ensure this information transitions the security boundary.

Some aspects may include actions to anonymize the user. For example, such aspects may, for a given user object, associate the user object with a stub in another operating system instance. These aspects may create a unique, anonymized identifier to represent the user object to extend it beyond the root operating system. These aspects may further apply a metadata filter to only provide an appropriate set of user metadata that is associated with the user stub. Such aspects may further inject files associated with the user in another operating system instance. For example, in some implementations, one or more applications <NUM>-<NUM> require user location information, however the filter <NUM>-<NUM> blocks user location information (such as time zone, GPS coordinates, etc.). In this example, the metadata filter injects the appropriate user location information, satisfying the requirements of applications <NUM>-<NUM>.

Aspects may additionally or alternatively negotiate version information between the root operating system and another operating system instances. Thus, for example, the root operating system and the another operating system may be different versions of the same operating system. This call allow different functionality to be implemented between the different operating systems.

Aspects may additionally or alternatively share data schemas between the root operating system and other operating system instances.

Aspects may additionally or alternatively monitor communications between the root operating system and other operating system instances.

Aspects may additionally or alternatively enforce communications between the root operating system and other operating system instances.

Further, the methods illustrated herein are practiced by a computer system including one or more processors and computer-readable media such as computer memory. In particular, the computer memory stores computer-executable instructions that when executed by one or more processors cause various functions to be performed, such as the acts recited in the aspects.

Aspects of the present invention may comprise or utilize a special purpose or general-purpose computer including computer hardware, as discussed in greater detail below. Aspects within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Thus, by way of example, and not limitation, aspects of the invention can comprise at least two distinctly different kinds of computer-readable media: physical computer-readable storage media and transmission computer-readable media.

Physical computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage (such as CDs, DVDs, etc), magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry or desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

Alternatively or in addition, the functionality described herein may also be implemented all or in part through use of a distributed system, such as a "cloud". The cloud abstracts underlying functionality of hardware (e.g., servers, network hardware, storage hardware, et cetera) and software resources, which may include applications, data and/or services (e.g. an authentication service, a directory service, a naming service, et cetera) that can be utilized while computer processing is executed on servers that are discrete from host operating system. Host operating system may connect to this cloud via a local area network (LAN), a metropolitan area network (MAN) and/or a wide area network (WAN). In some aspects a host operating system may be part of a cloud, and customers may use container operating system. In other aspects, both a host operating system and container operating system may be part of a "cloud platform" that provides capabilities and services to customers that rent resources such as virtual machine and/or containers. It should be noted that the cloud and the cloud platform can be arranged in a myriad of configurations. For example, the cloud can be implemented as a single cloud, as multiple instances of a cloud all behaving as a single cloud, or with one or more instances of a cloud platform implemented behind the cloud and behaving as if the one or more instances of the cloud platform were implemented in the cloud.

Claim 1:
A method of operating a computer system (<NUM>) with a first operating system (<NUM>) and a second operating system (<NUM>) wherein the first operating system is a host operating system and the second operating system is a containerized operating system hosted by the first system, where the first operating system (<NUM>) and the second operating system (<NUM>) are separated by a security boundary (<NUM>), the method (<NUM>) comprising:
anonymizing by the first operating system, identity information related to an authorized user at the first operating system to generate an anonymized user at the second operating system;
wherein the anonymized user at the second operating system corresponds to the authorized user at the first operating system;
sending (<NUM>) an anonymized request from the second operating system for the anonymized user for resources (<NUM>) from an external service, that the authorized user is authorized to access through a broker;
sending (<NUM>, <NUM>), by the second operating system, a request to the first operating system for proof that the anonymized user is authorized to obtain the resources as a result of the broker's request;
receiving (<NUM>), by the second operating system, the proof from the first operating system, based on the anonymized user being associated with the authorized user, that the anonymized user at the second operating system is authorized to access the resources;
obtaining (<NUM>), by the second operating system, the resources as a result of providing the proof.