Abstract: Access to data and resources in a multi-tenant computing system is managed by tagging the data and resources with attributes, as well as by tagging users with attributes. Tenant-specific access policies are configured. When an access request is received from a workload, a policy decision engine processes the attributes that are tagged to the requesting workload (e.g., user, application, etc.) as well as those tagged to the requested data or resource, given a relevant tenant-specific policy. An access decision is provided in response to the access request, and the access decision can be enforced by a tenant-specific enforcement system.

Abstract: Access to data and resources in a multi-tenant computing system is managed by tagging the data and resources with attributes, as well as by tagging users with attributes. Tenant-specific access policies are configured. When an access request is received from a workload, a policy decision engine processes the attributes that are tagged to the requesting workload (e.g., user, application, etc.) as well as those tagged to the requested data or resource, given a relevant tenant-specific policy. An access decision is provided in response to the access request, and the access decision can be enforced by a tenant-specific enforcement system.

Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Abstract: The techniques described herein enable client APIs to be deployed within isolated computing environments while externally exposing and/or maintaining a log of computing events that the client APIs perform and/or attempt to perform within the isolated computing environments. Generally described, configurations disclosed herein enable audit parameters associated with client application programming interfaces (APIs) to be deployed within an isolated computing environment to generate a log of computing events performed by the client APIs. Ultimately, access to the log of computing events is provided externally to the isolated computing environment without exposing sensitive computing resources (e.g., a host operating system (OS)) to the various client APIs.

Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.