Isolated runtime environment for protecting secrets used to access remote resources from a compute instance

Abstract

The instance secret management isolation runtime environment is launched in a virtualized server and utilizes a subset of the memory allocated to a compute instance. The subset of memory is inaccessible to entities external to the runtime environment. The secret manager of the runtime environment provides security artifacts to applications running in a compute instance that requested access to the resource. The artifacts are generated by the secret manager using security secrets associated with the compute instance, and the secrets are not accessible to programs external to the runtime environment. In response to a determination that the artifacts are valid, the application obtains access to the resource.

Description

Technical Field

[0001] The emergence of virtualization technology for commodity hardware provides advantages in managing large-scale computing resources for many customers with diverse needs, enabling various computing resources to be efficiently and securely shared by multiple customers. For example, virtualization technology can enable a single physical computing machine to be shared among multiple users by providing each user with one or more virtual machines hosted by the single physical computing machine. Each such virtual machine can be regarded as a software simulation that functions as a separate logical computing system, providing the user with the illusion of being the sole operator and administrator of a given hardware computing resource while providing application isolation and security among the various virtual machines. In a cloud-based computing environment, a program running within a given virtual machine or computing instance of a virtualized computing service may need to access remote resources in other services, and the requests to access the remote resources may need to be protected.

Brief Description of the Drawings

[0002]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

[0003] Embodiments are described herein as examples of several embodiments and illustrative drawings. Those skilled in the art will recognize that the embodiments are not limited to the described embodiments or drawings. The drawings and their detailed description are not intended to limit the embodiments to the specific forms disclosed, but rather, the intention is to cover all modifications, equivalents, and alternatives within the spirit and scope defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to limit the scope of the description or claims. As used throughout this application, the word "may" is used in a permissive sense (i.e., having the possibility of doing) rather than a mandatory sense (i.e., must do). Similarly, the words "include", "including", and "includes" mean including but not limited to. When used in the claims, the term "or" is used as an inclusive or rather than an exclusive or. For example, the phrase "at least one of x, y, or z" means any one of x, y, and z, as well as any combination thereof. Unless explicitly stated otherwise, articles such as "a" or "an" should generally be construed as including one or more of the described items throughout this application. Thus, phrases such as "a device configured to" are intended to include one or more of the described devices. Such one or more of the described devices can also be configured collectively to perform the described recitation. For example, "a processor configured to perform recitations A, B, and C" can include a first processor configured to perform recitation A that operates in conjunction with a second processor configured to perform recitations B and C. Unless explicitly stated otherwise, the term "set" should generally be construed as including one or more of the described items throughout this application. Thus, phrases such as "a set of devices configured to" are intended to include one or more of the described devices.One or more such described devices can also be collectively configured to perform the recited description. For example, a "set of servers configured to perform Recitations A, B, and C" can include a first server configured to perform Recitation A that operates in conjunction with a second server configured to perform Recitations B and C.

Best Mode for Carrying Out the Invention

[0004] This disclosure relates to a method and apparatus for reducing the probability of misuse of security secrets associated with computing instances of virtualized computing services using an isolated runtime environment. Typically, credentials / security secrets are accessible to all software and users of an instance that uses the credentials to obtain access to other resources, which may increase the likelihood of misuse of the credentials. Specifically, this disclosure relates to a "credential-less" authentication protocol for computing instances, which refers to an authentication protocol in which security secrets used by an instance for authentication are not directly exposed to the instance itself. Security secrets such as a unique cryptographic key assigned to a computing instance can be utilized to prepare requests for accessing remote resources (e.g., remote resources managed in services other than virtualized computing services) within a cloud provider network from the computing instance. Programmatic requests (such as Hypertext Transfer Protocol (HTTP) GET requests) for remote resources to securely access data items stored in a storage service of the provider network from a program running in a computing instance are formatted and digitally signed according to a protocol enforced by the provider network. An authorization role is assigned to a computing instance, for example, by a request of a virtualized computing service (VCS) client in which the computing instance is established, and enables a program running within the computing instance to access or utilize a remote resource or service indicated within the role. One or more security secrets generated for a computing instance based on an authorization role and referred to herein as "instance secrets" are used in the process of preparing programmatic requests for transmission to a service where the remote resource is managed.

[0005] To support various types of secure computing that involve signing requests for remote resources using instance secrets, an isolated runtime environment with a verified software configuration can be established within a compute instance. Such an isolated runtime environment (IRE) may be referred to as a "software enclave". A compute instance associated with an IRE and capable of utilizing the IRE for secure computing is referred to as the IRE's "parent" compute instance. The IRE can utilize a separate subset of the memory assigned to its parent compute instance, and other programs running within the compute instance (i.e., programs not running within the IRE itself) cannot access the separate subset of memory. Programs within the IRE can communicate with external entities only via a special local communication channel and a communication broker running within the compute instance, and are prohibited from accessing persistent storage or establishing a network connection. Security secrets for various applications can be obtained or provided to trusted programs running within the IRE using the local communication channel without exposing the secrets to untrusted programs in the compute instance that are not running within the IRE. Such secrets can later be used, for example, at the request of an untrusted program, to perform computations by trusted programs within the IRE.

[0006] Generally, IRE can be established for various purposes, for example, at the request of a client for which a parent computing instance is running on behalf, or at the request of the control plane or management components of VCS. An IRE configured as an Instance Secret Management IRE or ISM-IRE can be automatically established for a parent computing instance for the purpose of managing instance secrets, for example, after a VCS client for which a parent computing instance is established opts in (or does not opt out) of the use of ISM-IRE to prepare requests for remote resources. For example, a control plane server of VCS can start an ISM-IRE including a secret manager (for example, one or more processes or threads) for a parent computing instance by issuing a command to a virtualization management component (VMC) running on a virtualization host on which the computing instance is running. In some cases, for example, depending on the machine image used for the computing instance, ISM-IRE can be started as part of the overall startup procedure of the parent computing instance. The establishment of ISM-IRE can be said to be automatic in that no explicit request for starting ISM-IRE itself is required from the VCS client. Further, a set of one or more instance secrets (such as private cryptographic keys) of a parent computing instance can be automatically obtained or determined by the secret manager from, for example, a security service of a provider network without the need for the VCS client to request the acquisition of the instance secrets.

[0007] Next, the applications running within the parent compute instance can send representations of their access requests for remote resources to the secret manager. The secret manager can use the instance secret to generate a signature (or other similar security artifact) for each of the remote resource access requests and provide the signature or artifact to the application accessing the remote resource. The application can send the security artifact to the service for which the requested resource is managed according to the remote access protocol of the provider network without the application accessing the instance secret. If the resource manager or request handler of the remote service determines that the security artifact is valid, for example, if the authorization role assigned to the compute instance and associated with the instance secret permits or grants access to the resource by the compute instance, it can provide access to the resource. In the virtualization server where the parent compute instance runs, the instance secret cannot be stored or saved in a location external to the ISM-IRE, and the instance secret cannot be transmitted to other entities over the network. Therefore, the use of ISM-IRE can substantially reduce the likelihood of inadvertent or intentional breach or "leakage" of the instance secret.

[0008] As will be appreciated by those skilled in the art in light of the present disclosure, certain embodiments may be capable of achieving various advantages including some or all of the following: (a) eliminating or at least substantially reducing the possibility of inadvertent or intentional misuse of security secrets used to access remote resources from a computing instance implemented in a provider network, even if a malicious entity attempts to gain access to the computing instance in some way or attempt to run a program on the computing instance, and / or (b) reducing the amount of computing and other resources that must be dedicated to detecting and debugging unauthorized access to resources in a provider network.

[0009] According to some embodiments, the system may include one or more control plane servers (CPSs) of virtualized computing services (VCSs) of a cloud provider network, one or more virtualized servers or hosts of the VCSs, and one or more resource managers of a set of resources in another service (such as a storage service or a database service) of the provider network. The CPS may automatically start an instance secret management isolation runtime environment (ISM-IRE) including a secret manager (SM) within a computing instance running on a virtualized server. Access may be granted to a subset of the memory allocated to the computing instance in the ISM-IRE. The ISM-IRE may be started without receiving a specific start request for the ISM-IRE from a client of the VCS that may have received a request to start the computing instance in the VCS control plane. The subset of memory may be inaccessible to programs running outside the ISM-IRE in various embodiments. Network communication with endpoints external to the virtualized server may be prohibited from the ISM-IRE. For example, the ISM-IRE may be configured without external networking (networking external to the local host being started), or may be configured with only a secure local channel for communicating with the parent instance, which may be a local socket such as a VM socket (vsock) in some implementations. The ISM-IRE may also be configured without persistent storage, remote storage, or interactive access. Neither the root user nor the admin user of the parent instance may access or SSH into the ISM-IRE. In some embodiments, the ISM-IRE may be started as part of the initialization or boot procedure of the computing instance, for example, using a specific machine image provided to the virtualization management component (VMC) of the virtualized server from the control plane server. In other embodiments, the ISM-IRE may be started at some point after the computing instance has been started.

[0010] In some embodiments, the SM (Secret Manager) may be configured to automatically determine or obtain a set of one or more instance secrets (such as cryptographic keys) associated with an authorized role assigned to a compute instance from, for example, a security service of a provider network, without receiving a request to determine / obtain an instance secret from a client. In at least one embodiment, the instance secret may not be accessible by a program that (a) is running within the compute instance and (b) is not running within the ISM-IRE itself.

[0011] In various embodiments, the SM may obtain an indication of a request to access a set of resources of other services (managed by a resource manager) generated by an application running within a compute instance. The SM may provide the application with a set of one or more security artifacts, such as a digital signature of at least a portion of the resource access request. The set of security artifacts may be generated by the SM using at least the instance secret. The application may send a request to the resource manager of the accessed resources along with the security artifacts provided by the SM. The resource manager may provide application access to the resources in response to determining that the security artifacts are valid and that the role assigned to the compute instance (which may be indicated by the security artifacts or obtained by the resource manager using a different mechanism) permits access to the resources.

[0012] In at least one embodiment, before the ISM-IRE is used for requests generated by a compute instance, the VCS client for which the parent compute instance of the ISM-IRE is launched by a request of the VCS client may submit a programmatic request indicating an authorization role assigned to the parent compute instance to the VCS control plane. Such role assignment requests may be submitted using any of the various programmatic interfaces of the VCS in various embodiments, such as a web-based console, a command-line tool, a graphical user interface, an application programming interface (API), etc. In one embodiment, the instance launch request that results in the establishment of the parent compute instance may include a role as a parameter. A set of instance secrets may be associated with (or generated using) the role in various embodiments.

[0013] In some embodiments, multiple roles may be assigned to a given compute instance by a request of the VCS client, and a respective set of instance secrets may be generated for each such role. The multiple roles may be used, for example, to enable respective subsets of applications running on the parent compute instance to access respective sets of remote resources. Information about the role used for a given resource access request may, in some embodiments, be provided by the application to a secret manager (SM), and the SM may use it to select the instance secret used to sign or generate a security artifact for the given resource access request.

[0014] According to one embodiment, the VCS may support multiple options for processing instance secrets. One of the options may be involved in establishing the ISM-IRE and secret manager of the type introduced above, and another option may be involved in obtaining instance secrets from, for example, a metadata service running on a virtualized server. In some embodiments, a VCS client desiring to use the metadata service may notify the VCS control plane server accordingly via a program interface. If the VCS client determines to use the metadata service for a particular computing instance or the computing instances of all clients, the ISM-IRE may not be set for those computing instances. In at least some embodiments, the VCS control plane may obtain an indication that the client has opted in (or not opted out) of the ISM-IRE option and may set the respective ISM-IRE for the client's computing instances only after the client has approved the use of the ISM-IRE.

[0015] In some embodiments, to further enhance the security of instance secrets, the validity of a given instance secret may automatically expire after a certain period of time, and thus, the SM may sometimes need to obtain a newer version of the secret. In one embodiment, the VCS client may provide an indication of the expiration criteria for one or more instance secrets managed by the SM via a programmatic interface. The expiration criteria may be specified, for example, as a time interval (e.g., equivalent to "expiring T minutes after the instance secret is generated"), may be specified based on usage (e.g., equivalent to "expiring after the instance secret has been used for N resource access requests"), may be specified based on a combination of time and usage (equivalent to "the instance secret remains valid for at most N resource access requests and expires by T minutes after the secret is generated"), or may be specified using other factors. After (or just prior to) the expiration of a given secret, the SM may, in various embodiments, obtain a replacement for that secret and then use the alternate version thereafter.

[0016] In some embodiments, the validity of the software (and / or hardware) state of at least a portion of the virtualization server on which the ISM-IRE is launched may be verified before an instance secret is generated for a compute instance running on the virtualization server. For example, a proof document indicating the state of the software (including, e.g., virtualization management component software, ISM-IRE software including the SM, etc.) may be provided to the security service of the provider network responsible for generating the instance secret, and the security service may ensure that the state information provided to it is acceptable or valid before issuing the instance secret or before providing the instance secret to the SM.

[0017] In some embodiments, at least some instance secrets may be obtained by the SM during the boot or startup procedure of the ISM-IRE, e.g., prior to any resource access requests from an application running on the parent computing instance of the ISM-IRE. In other embodiments, the instance secrets may be obtained at the first time they are needed, e.g., in response to metrics obtained by the SM for resource access requests from an application running on the parent computing instance.

[0018] Access to any of various resources in a cloud provider network, or to resources external to the cloud provider network, may in some embodiments be protected using instance secrets. Such resources may include, for example, data items stored in a storage service (object storage service, file system service, etc.), data items stored in a database service, machine learning models stored in a machine learning service, and the like. In one embodiment, an instance secret may be required to access a resource at a client premise from a computing instance running in a data center of the provider network. For example, a resource manager of such a client premise resource may call an authorization service (e.g., an authorization service within the provider network) to determine whether a security artifact submitted with a request from the computing instance is valid, and may provide access to the resource after determining that the security artifact is acceptable.

[0019] In at least one embodiment, a plurality of IREs (including at least one ISM-IRE) can be established for a given parent computing instance. For example, the VCS control plane automatically causes the establishment of the ISM-IRE, but a client with a proxy-configured parent computing instance can request the establishment of other IREs that can be used to perform security operations independent of the use of instance secrets. Each IRE, including the client-requested IRE, can include its own secret manager in such embodiments, and the client-requested IRE can be restricted to using the same type of local communication channel as the channel used by the ISM-IRE. In some implementations, such local channels may utilize one or more shared memory buffers and / or interrupt-driven communication protocols. The security secrets used by the secret manager of the client-requested IRE are obtained from a source indicated by the VCS client and used by the secret manager to perform calculations and / or generate security artifacts based on the client's application requirements. The ISM-IRE can be referred to as an IRE generated by the system in such embodiments, as opposed to the client-requested IRE.

[0020] As described above, in various embodiments, the VCS may be implemented as part of a service suite of a cloud provider network or a cloud computing environment. A cloud provider network (sometimes simply referred to as "the cloud") refers to a pool of network-accessible computing resources (such as computing resources, storage resources, networking resources, applications, and services), which may be virtualized or bare metal. The cloud can provide convenient on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adapt to variable loads. Thus, cloud computing can be regarded as both applications delivered as services via a publicly accessible network (such as the Internet or a cellular communication network), and the hardware and software within a cloud provider data center that provides those services.

[0021] A cloud provider network can be formed as several regions, where a region is a separate geographic area in which a cloud provider clusters data centers. Such a region may also be referred to as a provider network defined region since its boundaries may not necessarily coincide with boundaries such as countries or states. Each region can include a private high-speed network, for example, two or more availability zones connected to each other via a fiber communication connection. An availability zone (also known as an availability domain or simply a "zone") refers to an isolated failure domain that includes one or more data center facilities with separate power, separate networking, and separate cooling from those within another availability zone. A data center refers to a physical building or enclosure that houses and provides power and cooling to the servers of a cloud provider network. Preferably, the availability zones within a region are positioned far enough apart from other zones so that the same natural disaster does not take two or more availability zones offline simultaneously. Customers can connect to the availability zones of a cloud provider network via a relay center (TC) through a publicly accessible network (e.g., the Internet, a cellular communication network). The TC can be considered a primary backbone location that links customers to the cloud provider network, collocated with other network provider facilities (e.g., an Internet service provider, a telecommunications provider), and securely connected to the availability zones (e.g., via a virtual private network (VPN) or a direct connection). Each region can operate two or more TCs for redundancy. A region is connected to a global network that connects each region to at least one other region. A cloud provider network may deliver content from a presence point outside of these regions via an edge location and a regional edge cache server (presence point, or PoP), or may be networked with these regions.This partitioning and geographic distribution of computing hardware enables cloud provider networks to provide customers with low-latency resource access at global scale with high fault tolerance and stability.

[0022] In some embodiments, the virtualized servers may be located within the VCS region, at the edge location of the VCS, or at a VCS extended location. The edge location (or “edge zone”) as referred to herein can be structured in several ways. In some implementations, the edge location is an extension of the cloud provider network substrate that includes a limited amount of capacity provided outside of an availability zone (e.g., within a small data center or other facility of the cloud provider located near the customer's workload and far from any availability zone). Some edge locations can be referred to as local zones (because they are more local to or closer to a group of users than traditional availability zones). A local zone may be connected to a publicly accessible network such as the Internet in various ways, e.g., directly, via another network, or via a private connection to a region. Typically, a local zone will have more limited capacity than a region, but in some cases, a local zone can have substantial capacity, e.g., over thousands of racks. Some local zones can use an infrastructure similar to that of a typical cloud provider's data center. A VCS extended location can include a portion of a customer-owned facility where one or more data plane servers where VCS compute instances can be launched are located. Special highly secure channels using various types of tunneling techniques may be established in various embodiments to send commands (e.g., commands to launch compute instances and / or containers) from the VCS control plane servers (which remain in the provider network data center) to the extended location data plane servers.

[0023] A cloud provider network may implement various computing resources or services, which, in addition to VCS, may include data processing services (e.g., map reduce, data flow, and / or other large-scale data processing techniques), data storage services (e.g., object storage services, block-based storage services, or data warehouse storage services), other types of packet processing services, and / or other types of network-based services (which may include various other types of storage, processing, analysis, communication, event processing, visualization, and security services). Resources (e.g., computing resources and storage resources) necessary to support the operation of such services may be provisioned in an account associated with the cloud provider, whereas resources requested by a user of the cloud provider network may be provisioned in a user account.

[0024] Various network-accessible services may be implemented in one or more data centers, edge locations, and / or extended locations of a provider network in different embodiments. Network-accessible computing services can include an elastic computing cloud service or a VCS (referred to in various implementations as an elastic computing service, virtual machine service, computing cloud service, computing engine, or cloud computing service). Such services may present computing instances (guest virtual machines, or simply "instances") having various computing resources and / or memory resources that are managed by a compute virtualization service (referred to in various implementations as an elastic computing service, virtual machine service, computing cloud service, computing engine, or cloud computing service). In one embodiment, each of the virtual computing instances may correspond to one of several instance types or families. Instance types are characterized by their hardware type, computing resources (e.g., the number, type, and configuration of virtualized central processing units (VCPUs or VCPU cores)), memory resources (e.g., the capacity, type, and configuration of local memory), storage resources (e.g., the capacity, type, and configuration of locally accessible storage), network resources (e.g., the characteristics of its network interface and / or network capabilities), hardware accelerator resources, and / or other suitable descriptive characteristics (e.g., "burstable" instance types having a baseline performance guarantee and the ability to burst beyond that baseline periodically, or non-burstable or dedicated instance types where a fixed amount of resources is allocated and guaranteed). In some embodiments, one or more of the instance types may support the automatic establishment of ISM-IRE of the kind introduced above. Each instance type can have a specific ratio of processing, local storage, memory, and networking resources, and if the instance families are different, the types of these resources they have may also be different.Multiple sizes of these resource configurations may be available within a given instance type. Using an instance type selection function, the instance type can be selected for a customer, for example, (at least in part) based on input from the customer. For example, a customer may select an instance type from a predefined set of instance types. As another example, a customer may specify the desired resources of the instance type and / or the requirements of the workload on which the instance is to be executed, and the instance type selection function may select an instance type based on such specifications. A host suitable for the requested instance type can be selected based at least in part on factors such as the collected network performance metrics, resource utilization levels on different available hosts, etc. In some embodiments, instances of several different instance types can be launched in the expansion facility in response to programmatic requests from the client. Other types of network-accessible services, such as packet processing services, database services, wide area networking (WAN) services, etc., may also be implemented in a cloud provider network in some embodiments.

[0025] The traffic and operations of a cloud provider network (or individual services of a cloud provider network including VCS) can be broadly classified in various embodiments into two categories, namely, control plane operations that occur via a logical control plane and data plane operations that occur via a logical data plane. The data plane represents the movement of user data through a distributed computing system, while the control plane represents the movement of control signals through a distributed computing system. The control plane is generally distributed across one or more control servers and includes one or more control plane components implemented by one or more control servers. Control plane traffic generally includes administrative operations such as system configuration and management (e.g., resource allocation, hardware capacity management, diagnostic monitoring, or system state information). The data plane includes customer resources implemented on a cloud provider network (e.g., computing instances, containers, block storage volumes, databases, or file storage). Data plane traffic generally includes non-administrative operations such as transferring customer data between customer resources. Certain control plane components (e.g., Tier 1 control plane components such as the control plane of a virtualized computing service) are typically implemented on a separate set of servers from the data plane servers, while other control plane components (e.g., Tier 2 control plane components such as analytics services) may share virtualized servers with the data plane, and control plane traffic and data plane traffic can be sent over separate / distinct networks.

[0026] FIG. 1 illustrates an exemplary system environment in which an automatically launched isolated runtime environment can be utilized to enhance the security of secrets utilized to access remote resources from a computing instance in a virtualized computing service of a cloud provider network, according to at least some embodiments. As shown, system 100 includes resources and artifacts of several network-accessible services of cloud provider network 102, including virtualized computing service (VCS) 110, security secrets service 160, identity and role management service (IRMS), and storage service 164. VCS control plane 112 can include a plurality of control plane servers, including, for example, instance state change manager 114, provisioning manager 116, instance secrets processing coordinator 118, client request handler 119, and the like. VCS can include virtualized server fleet 130, which can include virtualized servers (VS) 132A and 132B from which various types of computing instances or virtual machines can be launched in response to programmatic requests from VCS clients. A given virtualized server 132 can include a virtualization manager component (VMC) 137 (such as a hypervisor) and zero or more computing instances at a given point in time. For example, VS132A includes VMC137A and computing instances (CI) 134A and 134B, and VS132B includes VMC137B and CIs 134K and 134L.

[0027] Some of the computing instances may include application programs that need to access resources in other services of the provider network, such as data item 166 of storage service 164. To help ensure that only authorized entities can access data item 166, in the illustrated embodiment, a protocol for submitting resource access requests from computing instance 134 may be adopted and enforced in provider network 102. An example of such a protocol is described below in the context of FIG. 2. As part of such a protocol, a security artifact (such as a digital signature of at least a portion of a formatted string representing a resource access request) may be generated using an instance secret assigned to the computing instance from which the computing instance is originating. SSS 160 may be responsible for generating the instance secret in at least some embodiments. The security artifact may be sent to resource manager 167, which is responsible for the data item being accessed, along with the resource access request, and access to the data item may be provided by the resource manager only after the security artifact is verified to be valid in the illustrated embodiment. One or more authorization roles (also referred to as access management roles) may be assigned to a given computing instance 134 at the request of the VCS client in which the computing instance is launched on behalf. A given role may, in various embodiments, include rules indicating the types (or a specific list) of remote resources that can be accessed from the computing instance, and the instance secret may be generated at least in part based on the role. In the illustrated embodiment, information about the role may be stored in IRMS 162.

[0028] In the embodiment illustrated in FIG. 1, one or more control plane servers (such as instance secret processing coordinator 118 and / or instance state change manager 114) can automatically start each instance secret management isolation runtime environment (ISM-IRE) within at least some of the compute instances (e.g., using a separated portion of their memory). For example, CI134A includes ISM-IRE136A, CI134B includes ISM-IRE136B, and CI134K includes ISM-IRE136K. In the illustrated embodiment, some CIs, such as CI134L, may not include an ISM-IRE. The CI itself may be started in response to the programmatic requirements of the VCS client, but in at least some embodiments, the ISM-IRE may be started without receiving a specific client request to do so. Communications to / from the ISM-IREs may be severely restricted in various embodiments, for example, network communications may be prohibited, input / output to persistent storage may be prohibited, etc. A local communication channel may be set up, for example, using a shared memory buffer, for messages originating from or directed to the ISM-IRE. Each ISM-IRE may include its own secret manager, which is implemented using, for example, one or more processes or threads. In some embodiments, the VCS control plane may start only the ISM-IRE in the client's CI in response to an indication that the client has opted in to the use of the ISM-IRE. In other embodiments, the use of the ISM-IRE may be a default option provided to the VCS client, and the ISM-IRE may be automatically created for each CI unless the client opts out of the default.

[0029] The secret manager of the ISM-IRE can obtain, determine, or acquire a set of instance secrets associated with the role assigned to its parent computing instance (the computing instance on which the ISM-IRE is configured). For example, to acquire an instance secret, a highly secure communication path may be established between the ISM-IRE and the SSS160 (using the local communication channel). In response to receiving an indication of a resource access request (e.g., an access request directed to data item 166 of storage service 164) issued by an application running within the parent CI, the SM may generate a security artifact for the request (e.g., a digital signature corresponding to at least a portion of the request) using an appropriate instance secret and provide the security artifact to the application. Next, the application may send the security artifact along with the request to the resource manager 167. After the security artifact is validated / verified (e.g., by the resource manager itself or by an authentication / authorization service called by the resource manager) and the resource manager confirms that the computing instance is permitted to access the target resource (e.g., based on the role assigned to the computing instance), in the illustrated embodiment, access to the resource may be granted. If the security artifact is found to be unacceptable or invalid, or if the associated role does not permit access to the target resource, in various embodiments, access to the target resource may be denied.

[0030] In some embodiments, a given CI may have multiple authorization roles (each enabling an application to access a different set of resources), and each set of instance secrets may be generated corresponding to each role, and each set of instance secrets may be used in the above-described manner to enable resource access according to the corresponding role. In some embodiments, in addition to the automatic ISM-IRE or system-initiated ISM-IRE, other IREs may be initiated in the parent CI at the explicit request of the VCS client and used for other security calculations or operations that do not necessarily require instance secrets. In one embodiment, the VCS client may provide the VCS control plane with input regarding the expiration criteria of one or more instance secrets of those CIs, and force the SM to refresh or replace the instance secrets based on the expiration criteria. According to some embodiments, at least some states of the installed software of the virtualized server may be verified using, for example, the proof documents prepared by the VMC before the instance secrets are provided to the SM running in the ISM-IRE of the virtualized server. In one embodiment, at least some instance secrets may be obtained by the SM when (or immediately after) the parent CI and the ISM-IRE start up, and in other embodiments, some or all of the instance secrets may be obtained only in response to detecting that a request to access a remote resource has been generated by an application running in the parent CI.

[0031] VCS 110 may implement one or more programmatic interfaces 177, including, for example, one or more web-based consoles, a set of application programming interfaces (APIs), command line tools, graphical user interfaces, etc. Such interfaces may be utilized by VCS clients to request various types of configuration operations on various VCS client devices 150 (e.g., desktops, laptops, mobile computing devices, etc.) and receive corresponding responses, etc. For example, a client may submit a programmatic request to launch or instantiate a compute instance (CI) 134, opt in or out of the use of ISM-IRE, submit preferences regarding expiration criteria for instance secrets, etc. Individual ones of the compute instances 134 may, in various embodiments, include respective virtual machines and / or other types of program execution platforms (such as bare metal instances having more direct control granted to them than is granted to guest virtual machines, to more hardware devices).

[0032] In some embodiments, at least some of the client requests may be directed to the VCS control plane 112. In the illustrated embodiment, control plane servers such as the instance state change manager 114, the provisioning manager 116, the instance secret processing coordinator 118, and the client request handler 119 may each be implemented using some combination of hardware and software on one or more computing devices. Client requests for a computing instance may first be processed, for example, by the request handler 119. The request handler may perform some initial checks (e.g., to verify that the client has permission for the requested type of operation) and then pass an internal version of the request to one or more other components of the control plane for implementation. The instance state change manager may be responsible, for example, in the illustrated embodiment, for the startup, termination, and migration of computing instances implemented on the virtualization servers of the VCS virtualization server fleet 130. The provisioning manager 116 may be responsible, for example, in the illustrated embodiment, for identifying the particular virtualization server on which one or more requested computing instances are to be launched.

[0033] The virtualization manager component (VMC) 137 (which may include a hypervisor) in the virtualization server may function as an intermediary between the computing instance 134 and at least some of the hardware elements of the VS, including, for example, physical processors (e.g., central processing units (CPUs), graphical processing units (GPUs), etc.), memory, persistent storage devices, networking cards, peripheral devices, and the like. In some embodiments, at least a portion of the virtualization management responsibility may be offloaded from the primary processor or CPU to a hardware card (e.g., a card linked to the VS's CPU via a peripheral connection interface or PCI-Express interconnect and referred to as an offload card) in order to free up more of the primary processor's computing power for the computing instance.

[0034] In the illustrated embodiment, after a request to launch a compute instance is sent by a client to the VCS control plane, the corresponding internal command to launch the instance can be sent to a virtualization manager component (e.g., a hypervisor or an offloaded virtualization management component) running on the selected virtualization server. A set of resources including a section of the virtualization server's memory can be allocated by the virtualization manager component to the compute instance. In some embodiments, the control plane server may send a request to the VMC to launch the ISM-IRE, for example, as part of the internal command that causes the launch of the CI itself. In other embodiments, a separate request and / or command may be sent to the virtualization server to launch the ISM-IRE, for example, after the compute instance 134 has already been provisioned. In some embodiments, at least a portion of the memory allocated to the compute instance may be separated or reserved by the VMC137 for the ISM-IRE136. As shown in FIG. 1, the resources of a given virtualization server 132 (such as 132A and 132B) may be used by multiple compute instances in at least some embodiments, some of which may be provisioned on behalf of different VCS clients. Other virtualization servers may comprise one or more compute instances provisioned on behalf of a single client. Each subset of the resources allocated to a given compute instance may be separated or sliced for multiple IREs in some scenarios (e.g., including the ISM-IRE and one or more client-requested IREs). In at least some embodiments, the lifetimes of the client-requested IREs and their parent compute instances (or other client-requested IREs on the same compute instance) may be different. For example, one client-requested IRE may terminate before its parent CI, or one client-requested IRE may terminate before another client-requested IRE having the same parent CI. In some embodiments, the ISM-IRE may only terminate when its parent CI terminates.In at least some embodiments, the resources of the parent computing instance that are set aside or reserved for IRE may not be accessible to the programs or processes running on the parent computing instance. For example, if 4 gigabytes of the total 32 gigabytes of memory initially allocated to the CI are reserved for ISM-IRE, the programs / processes within the CI can access and use only the remaining 28 gigabytes.

[0035] As described above, when constructing or instantiating an IRE, in various embodiments, some constraints may be imposed to limit the manner in which programs or processes within the IRE can communicate or interact with other entities (e.g., processes / programs running inside or outside the parent computing instance). In at least one embodiment, for example, the IRE process / program may be prohibited from over-the-wire networking communication with any entity external to the IRE (e.g., by not configuring a virtual or physical network interface accessible to the IRE). Similarly, in various embodiments, the IRE may be configured such that access to persistent storage devices and / or file systems is prohibited, i.e., the processes / programs within the IRE may not be able to perform read or write operations to persistent storage. In some embodiments, one or more communication intermediary processes (CIPs) or daemons may be instantiated in the parent computing instance of the IRE, which are permitted to use local communication channels to communicate with the IRE on behalf of other processes / programs inside or outside the parent computing instance. For example, in some embodiments, one or more buffers of shared memory mapped to both the CIP and the IRE may be used for such communication. In at least some such embodiments, interrupt-based or notification-based communication techniques may be used for two-way communication between the CIP and the IRE. For example, a notification may be generated by the CIP when a message is ready for the IRE, and similar notifications may be used to indicate when the IRE has finished reading a buffer, when the IRE is ready to send an outbound message within the buffer, when the CIP has finished sending that outbound message, etc. In some embodiments, such a communication mechanism may be referred to as a "doorbell" mechanism.

[0036] In at least some embodiments, the VMC of VS132, such as a hypervisor, may include a security manager responsible for verifying or measuring the software configuration of IRE136 and / or other software components of the VS, including at least some portions of the VMC itself. The security manager may perform measurements and / or attestations of the software stack of IRE and other software components, and the results of such configuration verification or analysis operations may, in various embodiments, be provided to one or more destinations (e.g., SSS160). In at least one embodiment, one or more hash functions may be applied to the software installed by the security manager, and the results of the hash functions may be compared to the hash results of an acceptable configuration by the client. Evidence that the security manager itself is trustworthy (such as a digital certificate identifying the security manager), as well as unique identifiers of the IRE and / or its parent computing instance, may also be provided in at least some embodiments.

[0037] In embodiments where SSS160 generates an instance secret, a mechanism may be employed that does not allow the unencrypted version of the instance secret to be tampered with or accessed by any party other than SSS and ISM-IRE itself. In some embodiments, for example, a logical equivalent of a TLS (Transport Layer Security) session may be established between SSS and IRE, and the instance secret may be encrypted using a shared secret key determined / generated by both ISM-IRE and SSS during the session. The encrypted version of the secret may pass through a communication mediation process (CIP) on the way from the client to ISM-IRE, but note that CIP may not have the shared secret key required to decrypt the secret in various embodiments. In at least some embodiments, the decrypted version of the secret may be generated within the IRE using the shared secret key.

[0038] Figure 2 illustrates an exemplary remote request submission protocol that may be employed in a cloud provider network according to at least some embodiments. In the illustrated scenario, application program 236 running on compute instance (CI) 234, which is composed of requests from client 1, a client of a VCS similar to VCS 110 in FIG. 1, needs to access data item 266 in storage service 264. The storage service may implement a web service interface that can be used to request access, for example, via HTTP or a similar protocol.

[0039] The remote request submission protocol of the cloud provider network in which the VCS and the storage service are implemented may include several steps in the illustrated embodiment. In the first step, labeled step A in FIG. 2, a canonical or standardized request for a data item, such as a properly structured version of an HTTP GET or PUT request, may be created. For example, the elements of the request, including the HTTP request method, the target service name or service host name represented as a URI (Uniform Resource Identifier), the query string, various HTTP headers, etc., may have to be arranged in a specific order using a specified delimiter (such as a newline token) that separates each element of the request. In step B, a string for signing may be created from the canonical request. The string may include, for example, an identifier of the hash algorithm used to generate the digest of the canonical request, a representation of the data and time at which the request was generated, a representation of the credential information scope associated with the request (e.g., the region of the provider network, the name of the target service, etc.), and a hashed representation of the canonical request itself.

[0040] In step C, a digital signature of the request can be generated or calculated. As part of the process of generating the signature, a signing key may be created using the instance secret of the CI. In some embodiments, a series of hash-based message authentication codes (HMACs) may be generated to ultimately obtain the signing key. The signing key and the string for signing (generated in step B) may be provided as inputs to a keyed hash function, and the output of the keyed hash function may represent the signature. In some embodiments, the instance secret itself may be generated at least in part based on the authorization role assigned to the CI by client 1 (e.g., in a provider network's security secret service). In one embodiment, other security data such as a session token and / or key identifier assigned to the client's account in the provider network may also be used in the process of generating the signature. The key identifier may indicate or identify the authorization role (assigned to the CI) in which the instance secret is created in some implementations.

[0041] In step D, the signature and the request can be sent to the target storage service 264 where the data item resides. If the signature is valid and acceptable, access to the data item can be provided to the requesting application in step E, and if the signature is not valid, access can be denied in at least some embodiments.

[0042] In some embodiments, Protocol 277 does not necessarily impose strict requirements on how the signature is calculated, or by which entity / program, or how / where the secret key is stored. For example, steps A, B, and C may be performed within a software development kit (SDK) provided by the provider network operator and used by the application to access external data, within a command line tool or other tool provided by the provider network operator, or within program code developed by the client. If the client does not wish to utilize the ISM-IRE based techniques described above, the secret key may be stored in plain text on the CI, hard coded into the application 236, read from a file by the application, or processed in any other way selected by the client. However, the security of the secret key can be significantly enhanced in various embodiments by utilizing ISM-IRE, thereby ensuring that the secret key cannot be accessed by any program running outside of ISM-IRE, including the application program 236 itself.

[0043] Figure 3 illustrates the components of a virtualized server in which an instance secret management isolation runtime environment can be launched, according to at least some embodiments. In the illustrated embodiment, a compute instance 344 can be launched in a VCS virtualized server 332 in response to a request submitted, for example, by a VCS client. The ISM-IRE 346 can be automatically configured in various embodiments using a portion of the resources previously allocated to the compute instance 344, using the compute instance 344 as a parent compute instance. The virtualization management component 334 of the virtualized server 332 can include, in at least some embodiments, an IRE resource separation manager (IRERSM) 338 responsible for identifying resources configured for exclusive use by the ISM-IRE (by threads or processes launched within the ISM-IRE). For example, from a memory section 377 of the virtualized server initially allocated to the parent compute instance 344, the IRERSM 338 may select or identify a memory subset 378 for exclusive use by the ISM-IRE, and when additional client-requested IREs or system-requested IREs are set within the same parent CI, the IRERSM 338 may exclusively secure respective additional subsets for such IREs. The separated memory may, in such embodiments, be configured for ISM-IRE use and then may not be accessible to processes / programs running within the parent CI. In some embodiments, subsets of other resources, such as virtual CPUs, that may be designated for use by the parent compute instance 344 may also be designated for exclusive use by the ISM-IRE.

[0044] In various embodiments, within the compute instance 344, the Communication Intermediation Process (CIP) 348 can be instantiated. In some embodiments, an operating system daemon may be used as the CIP. In one embodiment, such a CIP daemon may be established as part of the procedure to establish the ISM-IRE 346. In other embodiments, the CIP daemon may be started up as part of the initialization or boot sequence of the parent compute instance 344, or in response to an API call after the compute instance has been booted. The CIP 348 may be configured to transfer data from any other entity that desires to communicate with the ISM-IRE (e.g., including an external source 355 of instance secrets such as a security secret service similar to the SSS 160 in FIG. 1) to the ISM-IRE 346, and in various embodiments, may be configured to transfer outbound data from the ISM-IRE 346 to one or more destinations. In at least some embodiments, as part of the configuration steps to ensure isolation of the ISM-IRE from any external entity (e.g., other than the VMC 334), the process / program of the ISM-IRE 346 may not be permitted to transfer data to any entity or endpoint via a network connection that uses the network interface card of the virtualization server. In such embodiments, all communications to / from the ISM-IRE may have to pass through the CIP. Similarly, in some embodiments, the configuration settings of the ISM-IRE 346 may also prohibit the interaction between the IRE and persistent storage, and in such embodiments, the interaction between the ISM-IRE 346 and the file system. That is, reads from and writes to persistent storage may not be permitted from the process / program of the ISM-IRE. The local communication channel 349 may be set up in at least some embodiments for data transfer between the CIP and the ISM-IRE. For example, in one embodiment, a portion of the shared memory that is accessible to both the CIP and the ISM-IRE may be designated or mapped to store data transferred in / out of the ISM-IRE.In some embodiments, a two-way notification or interrupt-based mechanism may be used to indicate when data is ready to be read by the ISM-IRE (in the case of inbound data to the ISM-IRE) or when it is read by the CIP (in the case of outbound data from the ISM-IRE). The compute instance 344 may include various other processes / programs such as application components 356 of the compute instance and / or operating system components that may be less reliable than the ISM-IRE with respect to performing computations using security secrets (from the perspective of the VCS control plane and / or VCS client) in the illustrated embodiment.

[0045] In at least some embodiments, a configuration verification operation may be performed on the ISM-IRE at one or more points during the lifetime of the ISM-IRE. A configuration verification query may be sent from a verification requester (e.g., a control plane server such as the instance secret processing coordinator 118 of FIG. 1) to the CIP348, and the CIP348 may pass the query to the ISM-IRE. The IRE Security Manager (IRESM) 336 may determine that the query is directed to the ISM-IRE 346, for example, based on an indicator provided by the CIP348 or the ISM-IRE 346. The IRESM 336 may then perform a configuration verification / analysis operation on the software stack of the ISM-IRE 346, as indicated by arrow 392. In some embodiments, for example, one or more hash functions may be applied to various layers of the software of the ISM-IRE 346, and the output hash value may represent a signature of the software stack. In at least some embodiments, the IRESM 336 may perform a proof of the IRE software stack. In the illustrated embodiment, the results of the configuration measurement / verification tests employed by the IRESM 336 may be provided to the verification requester. The results may be passed from the IRESM to the ISM-IRE, from the ISM-IRE to the CIP, and ultimately to the verification requester in such a scenario. In other embodiments, a different path than that used for the query may be used for the verification results. In at least some embodiments, in addition to the authentication / verification results and nonces, the verification requester may also be provided with (a) an indicator of the identification of the IRESM similar to a TLS certificate rooted in a trusted certificate authority, and (b) an indicator of the identification of the ISM-IRE and / or its parent computing instance (e.g., including one or more public keys of each asymmetric key pair). The verification requester may then verify that the proof results and identity information are acceptable, and if acceptable, the ISM-IRE may be designated as trusted and verified for computations involving the use of the instance secret. In some embodiments, a hash value-based verification of the ISM-IRE software state may be performed by the VMC 334.In an embodiment where the client-requested IRES is established in a compute instance, it should be noted that similar state verification procedures can be initiated by the client at various stages of the lifetime of the client-requested IRE.

[0046] In the illustrated embodiment, one or more instance secrets 387 may be transferred from an external source 355 (such as a security secrets service) to the ISM-IRE as part of operation 391, e.g., upon request of a secrets manager 388 within the ISM-IRE. To do so, in various embodiments, a secure communication session or channel similar to a TLS session may be established between the external source 355 and the ISM-IRE. Within the compute instance 344, the CIP and the local communication channel 349 may be used for such a secure session. Using one or more messages of the session, an encrypted version of the instance secret 387 that cannot be decrypted by the CIP even if the CIP passes the messages of the session to / from the ISM-IRE can be securely transferred to the ISM-IRE 346. The secrets manager 388 of the IRE 346 may then begin performing computations using the instance secret, such as generating a signature for a request to access a remote resource from a less trusted application component 356. In some embodiments, a secrets provisioning agent 357, such as a privileged operating system thread of the compute instance, may prompt the secrets manager to obtain the instance secret 387.

[0047] Figure 4 illustrates exemplary interactions associated with the acquisition of instance secrets by a secret manager running within an isolated runtime environment, according to at least some embodiments. In the illustrated embodiment, the parent compute instance of the ISM-IRE may include a secret provisioning agent 401, implemented as, for example, a privileged operating system process or thread over which the VCS client has no direct control. The secret provisioning agent 401 may send an AcquireSecret request 450 to the ISM-IRE secret manager 404 in the illustrated embodiment. The timing of the AcquireSecret message relative to the time when the ISM-IRE is launched may vary in different embodiments. For example, in some embodiments, the AcquireSecret message may be sent during or immediately after the boot or startup of the ISM-IRE, while in other embodiments, the AcquireSecret message may be sent later, in response to a determination by the secret provisioning agent that, for example, a request for remote access has been generated by the application program 413 or is about to be generated by the application program 413 during startup. In some embodiments, the secret provisioning agent need not necessarily be implemented as part of the operating system, and instead, for example, some user-mode programs or the application program 413 itself may request to acquire a secret from the ISM-IRE secret manager. In at least one embodiment, the AcquireSecret request may indicate an authorization role for which the secret is being acquired. In various embodiments, the owner of the parent compute instance (the VCS client by whose request the parent compute instance is launched) may create and assign roles using a programmatic interface and notify the SSS that the parent compute instance has been assigned a role, prior to the steps shown in FIG. 4.

[0048] In response to receiving the AcquireSecret request, the ISM-IRE Secret Manager 404 may send a GetNonce request 451 to the Security Secret Service (SSS) 407 of the provider network, using, for example, a secure communication path involving the use of CIP and the local communication channel. To tie together the various messages of the secret acquisition procedure shown in FIG. 4, nonces (e.g., pseudorandom numbers) may be used, and the sender of the request for the operation may include a nonce in the request, and for example, trust the response only if the response includes the same nonce. Such nonces may be used in the encryption system to prevent a copy of the request (submitted, for example, by a malicious program or entity that somehow accessed the content of the request) from succeeding. In some embodiments, the identifier of the parent computing instance, and the role assigned to the parent computing instance, may be provided as part of the GetNonce request and used in the calculations used to generate the nonce at the STS. In one embodiment, the VCS may maintain an instance profile for each computing instance, indicating various characteristics of the computing instance including the role assigned to the computing instance, the profile may be included in the GetNonce request, and may be utilized to generate the nonce. The nonce may be provided by the STS to the ISM-IRE as indicated by arrow 452.

[0049] According to at least some embodiments, as shown above, the software state of the virtualized server can be verified before the SSS generates the instance secrets of the secret manager. In the embodiment illustrated in FIG. 4, the secret manager 404 can request a proof document or proof object indicating the software state from a virtualization management component (VMC) (e.g., a hypervisor) 410 of the virtualized server by sending a GetAttestation request 453 to the VMC. In some embodiments, the parameters of the GetAttestation request 453 may include a nonce (which may help the VMC confirm that the request is from a legitimate ISM-IRE). In an embodiment where the virtualized server includes a physical trusted platform module (TPM) or a virtualized TPM, the contents of the TPM indicating the measured values of the software state of the virtualized server may be included in the GetAttestation request. In other embodiments, the data obtained from the TPM may not be used for attestation. In some embodiments, the software of the ISM-IRE may be attested without attesting the rest of the software stack of the virtualized server. In other embodiments, the software of the ISM-IRE, the parent computing instance, and / or the VMC itself may be attested. The VMC can generate a proof document 454 and, in the illustrated embodiment, provide the digitally signed version of the proof document / object to the secret manager. The proof document or object may actually indicate that the VMC has verified that the ISM-IRE is legitimate (i.e., the state of the software used by the ISM-IRE has been verified).

[0050] In the illustrated embodiment, the Secret Manager may include a signed proof document or object in the GetSecret request 455 sent to the SSS 407. The parameters of the GetSecret request may, in some implementations, indicate or include the role for which the secret is generated. For example, in one implementation, the GetSecret request may indicate the identifier of the compute instance, and the SSS may have been previously notified by the VCS client about the role assigned to the compute instance. In the illustrated embodiment, the SSS may examine the proof document and generate an instance secret 456 if the proof information is satisfactory or has been successfully verified. The instance secret may then be sent back to the Secret Manager 404, along with other security data generated by the SSS, such as a session token and key identifier that are also used, for example, in the process of signing requests for the remote application and. In some implementations, the Secret Manager may then provide a response to the AcquireSecret request 450 of the Secret Provisioning Agent. A token, referred to as the instance secret identifier or InstanceSecretID 457, may be sent to the Secret Provisioning Agent, effectively indicating that the instance secret has been acquired or provisioned by the Secret Manager. In such an embodiment, the InstanceSecretID may be provided by the Secret Provisioning Agent to the application program 413 that makes requests to access remote resources.The InstanceSecret itself may not be exposed by the secret manager to the secret provisioning agent, and instead, the InstanceSecretID (along with, in some implementations, other security data such as a session token and / or a key identifier) that can be provided as a pointer or reference to the InstanceSecret may be exposed to the secret provisioning agent (and from the agent to the application program 413). Note that this is the case.

[0051] Figure 5 illustrates an exemplary interaction associated with the transmission of an access request, where a signature is generated by a secret manager running within an isolated runtime environment, according to at least some embodiments. After an instance secret has been obtained in the secret manager using the operations shown in Figure 4, in some embodiments, the application program 413 may send a request to the secret manager 404 for additional security data to be used in the pre-signature portion of preparing a remote request. Such a request may include a GetAdditionalSecurityData request 551, whose parameters may include the InstanceSecretID previously provided to the application program by the secret manager via the secret provisioning agent. The response, the AdditionalSecurityData 552 message, may include, for example, an account key identifier for a client on whose behalf a parent compute instance was established, a session token that can be used to control the expiration of the request and / or the instance secret, and the like. In at least some embodiments, the additional security data may not need to be protected to the same extent as the instance secret, but nevertheless, the secret manager 404 may be used to provide the additional security data to the application program.

[0052] A request to access a remote resource can be generated in application program 413, and the corresponding string for signing can be generated in the application or by the application (e.g., by an SDK component or a command-line tool) as described above in the context of FIG. 2. The string for signing can be shown, for example, in SignAccessRequest 553 sent from application program 413 to the secret manager using a communication mediation process (CIP) and a local communication channel of the type shown in FIG. 3. InstanceSecretId can be included among the parameters of the SignAccessRequest message in some embodiments. The signature 554 of at least a portion of the request is generated by the secret manager using the instance secret and can be sent to application program 413 in the illustrated embodiment. The application program can then send AccessRequest 555 to the resource manager of remote service 514 that manages the target resource for which access is desired, along with the signature generated for the request. The resource manager can then, in some embodiments, send a request to the authentication service 517 (also referred to as an authorization service) to verify the validity of the signature (in CheckSignature message 556). If the signature is verified to be valid, in the illustrated embodiment, SignatureOK message 557 can be sent from the authentication service to the resource manager of remote service 514, and if the signature is not valid, in at least some embodiments, instead, a message indicating that the signature is not valid can be sent. After the resource manager determines that the signature is valid, access to the resource can be granted, for example, to the application program, and the requested data (in the case of a read request) can be provided in RequestedData message 558. If the access involves writing to a data object, in one embodiment, the write can be performed on the data object, and an indication that the write was successful can be provided.In some embodiments, the authentication service 517 may not be required, and the resource manager of the remote service 514 may verify the validity of the signature itself. In one embodiment, in addition to the signature, a session token or other metadata that identifies the computing instance from which the access request is sent and / or the ISM-IRE of that computing instance may also be sent from the application program to the remote service and used (e.g., in the authentication service) to perform additional validity check before the signature is approved.

[0053] FIG. 6 illustrates an exemplary scenario in which, according to at least some embodiments, a plurality of authorized roles, each having its associated instance secret, can be assigned to a single computing instance. A computing instance 634 of a VCS similar to the VCS 110 of FIG. 1 includes an application program 636 and an application program 637 in the exemplary scenario illustrated in FIG. 6. An ISM-IRE 680 including a secret manager 682 is launched using a subset of the memory of the computing instance 634.

[0054] The application program 636 needs to access a remote external resource 652, while the application program 637 needs to access a remote external resource 653. The external resource 652 may, in some cases, be part of or managed by a network-accessible service of a different provider network than the external resource 653, or in other cases, both sets of external resources may be part of the same service. In some cases, one or both sets of external resources may not be located in a data center of the provider network. For example, one set of external resources may be located at a client facility of the provider network.

[0055] For example, in order to prevent application program 636 from accessing external resource 653 and / or prevent application program 637 from accessing external resource 652, a client on which compute instance 634 is launched may, in the illustrated embodiment, create and assign two different authorization roles for the compute instance using, for example, a programmatic interface implemented by VCS. Role 644A may enable access to external resource 652 (and may not enable access to external resource 653), and role 644B may enable access to external resource 653 (and may not enable access to external resource 652). Separate instance secrets 662A and 662B corresponding to role 644A and role 644B, respectively, may be obtained and managed by secret manager 682. In the illustrated exemplary scenario, a request to access external resource 652 from application program 636 may be signed by the secret manager using instance secret 662A, while a request to access external resource 653 from application program 637 may be signed by the secret manager using instance secret 662B. In various embodiments, any number of roles may be assigned to a compute instance associated with an ISM-IRE, and the secrets corresponding to each of the roles may be managed by a single ISM-IRE.

[0056] As described above, in some embodiments, the VCS client may want to start its own IRE and use the IRE to manage secrets other than the instance secrets assigned to the compute instance. FIG. 7 illustrates an exemplary scenario in which multiple isolated runtime environments may be established within a compute instance, according to at least some embodiments. In the illustrated scenario, a compute instance (CI) 734 is launched in a VCS virtualization server in response to an instance launch request from VCS client C1. ISM-IRE 740 is automatically launched by the VCS within compute instance 734, and a separated memory subset 778 of the total memory 777 initially assigned to the parent compute instance 734 is reserved for use by ISM-IRE 740. The secret manager running within ISM-IRE 740 utilizes the instance secrets assigned to CI 734 according to the cloud provider protocol for remote resource access, enabling application program 736 to access remote resources according to the authorized role assigned to CI 734.

[0057] In the illustrated embodiment, client C1 may also desire to perform other security-related computations using an isolated runtime environment. Since ISM-IRE is set up by the VCS, particularly to manage instance secrets, client C1 may not be provided access to ISM-IRE in the illustrated embodiment. Instead, client C1 may submit a programmatic request to the VCS control plane to establish a second IRE, labeled as client-requested IRE 744 in FIG. 7. In the illustrated embodiment, a second separate memory subset 779 may be utilized for client-requested IRE 744, and a second secret manager may be executed within client-requested IRE 744. This secret manager may be provided with security secrets from a source indicated by client C1 (e.g., used on behalf of application program 737) using a local communication channel similar to channel 349 shown in FIG. 3. In some implementations, the same communication mediation process (similar to CIP 348 in FIG. 3) may be shared by ISM-IRE and client-requested IRE, while in other implementations, a separate CIP may be used. Client-requested IRE may share many of the traits and characteristics (e.g., network and persistent storage I / O limitations) discussed earlier for ISM-IRE. Differences between client-requested IRE and ISM-IRE may include: (a) the VCS control plane can start ISM-IRE without receiving a request from a client, while client-requested IRE can only be started when requested by the client; (b) the source of the security secrets used may be different; and (c) client-requested IRE can be terminated by a client request, while ISM-IRE cannot be terminated. Optionally, in some embodiments, multiple client-requested IREs may be established.In one embodiment, the plurality of ISM-IREs may be launched in a single computing instance to which a plurality of roles are assigned, and each ISM-IRE is used to manage and use respective instance secrets corresponding to one of the plurality of roles.

[0058] FIG. 8 illustrates exemplary programmatic interactions related to instance secret management between a client and a virtualized computing service, according to at least some embodiments. VCS 812, which is similar in characteristics and functionality to VCS 110 of FIG. 1, may implement a set of programmatic interfaces 877, such as a web-based console, command line tools, application programming interfaces (APIs), graphical user interfaces, etc., in the illustrated embodiment. The VCS client 810 may submit an OptInForISM-IRE message 814 via the programmatic interface indicating that the client desires to automatically configure an ISM-IRE for the client's computing instance as needed. A record indicating that the client has opted in to the use of instance secret protection techniques using an ISM-IRE may be stored in the VCS control plane, for example, along with client account metadata, and in the illustrated embodiment, an OptInInfoSaved message 815 may be sent to the client. In some embodiments, instead of requiring the client to explicitly opt in, the VCS may notify the client that the ISM-IRE feature is on by default for at least some categories of computing instances and that the client may programmatically opt out of the use of the ISM-IRE as needed. In some embodiments, the VCS may provide information regarding the amount of computing instance memory that may be reserved for an ISM-IRE, for example, via a website, such that the client is aware that the ISM-IRE consumes a portion of the computing instance memory.

[0059] In the illustrated embodiment, a client may submit a LaunchCI request 817 for a compute instance. In one embodiment, the client may specify, as a parameter of the LaunchCI request, an authorization role intended to be used by a program running within the CI. If the ISM-IRE feature is enabled for the type of instance requested by the client (e.g., either by default or after the client opts in), in some embodiments, the VCS control plane may launch the ISM-IRE using a subset of the compute instance memory as part of the initialization or setup of the requested compute instance. In other embodiments, the launch of the ISM-IRE may be deferred until later in the lifetime of the compute instance, e.g., until an indication is received that a program running within the compute instance will access remote resources. In at least some embodiments, a CILaunched message 819 may be sent to the client after the compute instance has been launched.

[0060] In various embodiments, a VCS client may submit an AddNewRoleToCI request 829 indicating a new authorization role to be assigned to a specified compute instance via a programmatic interface 877. The VCS control plane may store information regarding the new role assignment and may send back a RoleAdded message 831 to the client. In some embodiments, for each added role, a corresponding instance secret (or secrets) may be obtained by a secret manager running within the ISM-IRE of the compute instance.

[0061] The client may wish to modify (or remove) the authorized role assigned to a compute instance. In some embodiments, a ModifyRole request 833 specifying the changes (e.g., permission to access additional remote resources, removal of permission to access some resources, etc.) may be submitted via the programmatic interface 877. The change indicators may be stored in the VCS control plane, and in the illustrated embodiment, a RoleChanged message 835 may be sent to the client. In some embodiments, the role information may be stored in an access management service similar to the IRMS 162 of FIG. 1, or an identity and role management service, instead of or in addition to being stored in the VCS itself. In such an embodiment, if the client wishes to modify a role, a corresponding request may be sent to the access management service or IRMS, and that service may notify the VCS of any changes that may require action by the VCS. In response to a role change, in some embodiments, the VCS control plane may cause the instance secret manager of the ISM-IRE of the compute instance to which the role is assigned to refresh or reacquire the instance secret corresponding to the changed role.

[0062] In various embodiments, the VCS client 810 may provide preferences or requirements related to the expiration of instance secrets. For example, the client may want to set the maximum amount of time that an instance secret remains valid, or the maximum number of remote resource access requests that can be made using a given instance secret, after which a new version of the instance secret needs to be obtained by the secret manager of the ISM-IRE. By expiring the secret in this way, the likelihood that the secret can be misused can be further reduced. The client may, in the illustrated embodiment, submit an InstanceSecretsExpirationPreferences message 843 that indicates one or more criteria to be used for one or more instance secrets of one or more of the client's compute instances. The preferences may be stored by the VCS control plane, and an ExpirationPreferencesApplied message 845 may be sent to the client for which the preferences are enforced.

[0063] The VCS control plane (and / or the control plane of other services that manage remote resources accessed from the compute instance) may, in some embodiments, capture various metrics related to remote accesses in which an instance secret is used, such as the number of remote accesses per unit time, a log record of such accesses indicating which particular remote resources were accessed. In one embodiment, the client may submit a GetInstanceSecretsUsageMetrics request 847 to view at least a portion of the metrics associated with a given set of compute instances or a given set of roles. The requested metrics may be provided to the client in one or more MetricSet messages 849. Note that in some embodiments, types of programmatic interactions other than those shown in FIG. 8 that are associated with the use of the ISM-IRE may be supported by the VCS.

[0064] Figure 9 is a flowchart illustrating an aspect of an operation that can be implemented to manage instance secrets using an isolated runtime environment, according to at least some embodiments. As shown in element 901, a control plane server (CPS) of a VCS that is similar in characteristics and functionality to the VCS 110 of FIG. 1 may receive an indication that enhanced secret management techniques are implemented using an IRE for secrets used to protect requests for remote resources from one or more of the compute instances (CIs) of the VCS client. The client may submit, for example, a message indicating that the client has opted in for the use of such an IRE.

[0065] Compute instance CI1 may be launched in virtualization server VS in response to an instance launch request from the client (element 904). The ISM-IRE may be automatically launched within CI1 in various embodiments without receiving a request to launch the ISM-IRE (element 907). A portion of the memory assigned to CI1 may be reserved for use by the ISM-IRE in various embodiments. This separated portion of memory may be inaccessible to any program that is not executed within the ISM-IRE itself, including other programs executing in CI1. Network communication may be prohibited from the ISM-IRE, and access to persistent storage may also be prohibited from the ISM-IRE in at least some embodiments. A type of secure local communication channel with an associated communication mediation process (CIP) shown in FIG. 3 may provide a means of communication between the ISM-IRE and external entities in some embodiments.

[0066] In the illustrated embodiment, the Secret Manager (SM) running within the ISM-IRE may obtain or determine one or more instance secrets (such as cryptographic keys) associated with the authorization role assigned to CI1 (element 910). The role may be defined, in at least some embodiments, by a client on behalf of which CI1 is established and / or assigned to CI1. In various embodiments, the instance secrets may not be accessible from a program running within CI1 that is not running within the ISM-IRE.

[0067] The SM may obtain an indicator of a request to access one or more remote resources external to CI1, generated by an application running within CI1 (element 913). The remote resources may include data stored in another service of the provider network where the VCS is implemented, such as, for example, a storage service, a machine learning service, or a database service.

[0068] In various embodiments, the SM may use the instance secret to generate security artifacts (such as the digital signature of at least a portion of the request) associated with the remote access request (element 916). The security artifacts may be transferred, sent, or provided from the SM to the application without revealing the instance secret itself to the application (element 919). The application may then send the security artifacts to the resource manager of the remote resource for which access is desired, along with the request itself (element 922). If the resource manager determines that the security artifacts are valid and thus that CI1 is permitted to access the requested resource, the application may obtain access to the resource in the illustrated embodiment (element 928). In some embodiments, the resource manager may utilize another service, such as the authorization / authentication service of the provider network, to determine whether the artifacts are valid, and in other embodiments, the resource manager may make the validity / invalidity determination itself.

[0069] Note that in various embodiments, some of the operations shown in the flowchart of FIG. 9 may be implemented in an order different from that shown in the figure, or may be implemented in parallel rather than sequentially. Further, some of the operations shown in FIG. 9 may not be required in one or more implementations.

[0070] In at least some embodiments, a server implementing techniques of the type described herein (e.g., including functions of VCS, security secret services, storage services, database services, authorization / authentication services, identity and role management services, and / or other services of a cloud provider network) may include a general-purpose computer system including or configured to access one or more computer-accessible media. FIG. 10 illustrates such a general-purpose computing device 9000. In the illustrated embodiment, computing device 9000 includes one or more processors 9010 coupled to system memory 9020 (which may include both non-volatile and volatile memory modules) via an input / output (I / O) interface 9030. Computing device 9000 further includes a network interface 9040 coupled to the I / O interface 9030.

[0071] In various embodiments, computing device 9000 may be a uniprocessor system including one processor 9010, or a multiprocessor system including several processors 9010 (e.g., two, four, eight, or another suitable number). Processor 9010 may be any suitable processor capable of executing instructions. For example, in various embodiments, processor 9010 may be a general-purpose or embedded processor implementing any of various instruction set architectures (ISAs) such as x86, PowerPC, SPARC, ARM, or MIPS ISA, or any other suitable ISA. In a multiprocessor system, each of the processors 9010 may, although not necessarily, implement the same ISA. In some implementations, a graphics processing unit (GPU) and / or a field-programmable gate array (FPGA) may be used instead of, or in addition to, conventional processors.

[0072] System memory 9020 can be configured to store instructions and data accessible by processor 9010. In at least some embodiments, system memory 9020 can include both volatile and non-volatile portions, and in other embodiments, only volatile memory may be used. In various embodiments, the volatile portion of system memory 9020 can be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM, or any other type of memory. In the case of the non-volatile portion of the system memory (which may include one or more NVDIMMs), in some embodiments, a flash-based memory device including a NAND flash device may be used. In at least some embodiments, the non-volatile portion of the system memory can include a power source, such as a supercapacitor or other power storage device (e.g., a battery). In various embodiments, any one of memory-storage based resistive random access memory (ReRAM), 3D NAND technology, ferroelectric RAM, magnetoresistive RAM (MRAM), or various types of phase change memory (PCM) can be used for at least the non-volatile portion of the system memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as the methods, techniques, and data described above, are shown stored within system memory 9020 as code 9025 and data 9026.

[0073] In one embodiment, the I / O interface 9030 may be configured to regulate I / O traffic between any peripheral devices within the device, including the processor 9010, the system memory 9020, and the network interface 9040 or other peripheral interfaces such as various types of persistent storage devices and / or volatile storage devices. In some embodiments, the I / O interface 9030 may perform any necessary protocol, timing, or other data conversions to transform a data signal from one component (e.g., the system memory 9020) into a format suitable for use by another component (e.g., the processor 9010). In some embodiments, the I / O interface 9030 may include support for devices attached via various types of peripheral buses (including various types of hardware accelerators), such as variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some embodiments, the functionality of the I / O interface 9030 may be split among two or more separate components, such as a north bridge and a south bridge. Also, in some embodiments, some or all of the functionality of the I / O interface 9030, such as the interface to the system memory 9020, may be incorporated directly into the processor 9010.

[0074] The network interface 9040 may be configured to enable the exchange of data between the computing device 9000 and other devices 9060 attached to the network 9050, such as other computer systems or devices as illustrated, for example, in FIGS. 1-9. In various embodiments, the network interface 9040 may support communication via any suitable wired or wireless general data network, such as, for example, an Ethernet network type. Further, the network interface 9040 may support communication via a telecommunications / telephony network, such as an analog voice network or a digital fiber communication network, communication via a storage area network, such as a fiber channel SAN, or communication via any other suitable type of network and / or protocol.

[0075] In some embodiments, system memory 9020 may represent one embodiment of a computer-accessible medium configured to store at least a subset of program instructions and data for implementing the methods and apparatuses discussed in the context of FIGS. 1-9. However, in other embodiments, the program instructions and / or data may be received, sent, or stored on different types of computer-accessible media. Generally speaking, computer-accessible media may include non-transitory storage media or memory media such as magnetic media or optical media like disks or DVDs / CDs coupled to computing device 9000 via I / O interface 9030. Non-transitory computer-accessible storage media may also include any volatile or non-volatile media such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, and any volatile or non-volatile media may be included in some embodiments of computing device 9000 as system memory 9020 or another type of memory. In some embodiments, a plurality of non-transitory computer-readable storage media may collectively store program instructions that, when executed on one or more processors or across multiple processors, perform at least a subset of the methods and techniques described above. Computer-accessible media may further include transmission media or signals such as electrical, electromagnetic, or digital signals transmitted via a communication media such as a network and / or wireless link that may be implemented via network interface 9040. Some or all of a plurality of computing devices, as illustrated in FIG. 10, may be used to implement the functionality described in various embodiments, e.g., software components running on various different devices and servers may cooperate to provide functionality. In some embodiments, in addition to or instead of being implemented using a general-purpose computer system, a portion of the functionality described may be implemented using a storage device, a network device, or a dedicated computer system.As used herein, the term "computing device" refers to at least all of these types of devices and is not limited to these types of devices.

[0076] Embodiments of the present disclosure can be described in consideration of the following clauses. Clause 1. A system comprising: A control plane server for virtualized computing services of a cloud provider network; A virtualization server for virtualized computing services; A resource manager for a set of resources of another service of the cloud provider network. The control plane server is configured to: Start an instance secret management isolation runtime environment in the virtualization server, where the instance secret management isolation runtime environment uses a subset of the memory allocated to the computing instance of the virtualization server, the instance secret management isolation runtime environment is started without receiving a startup request for the instance secret management isolation runtime environment from a client of the virtualized computing service in which the computing instance was started on behalf of, the subset of memory is inaccessible to programs running outside the instance secret management isolation runtime environment, network communication with endpoints outside the virtualization server is prohibited from the instance secret management isolation runtime environment, and the instance secret management isolation runtime environment is configured to start including a secret manager. The secret manager is configured to: Determining, without receiving a request from a client to determine a cryptographic key associated with an authorization role assigned to a compute instance, from a security service of a cloud provider network, a cryptographic key that is not accessible by a program that (a) is running on a virtualized server and (b) is not running within an instance secret management isolation runtime environment, Obtaining an indicator of a request to access resources of a set of resources generated by an application running within a compute instance, Configured to provide, to the application, a signature associated with at least a portion of the request, the signature being generated by a secret manager using at least the cryptographic key, The resource manager, A system configured to provide the application access to the resources in response to a determination that the signature is acceptable and that the authorization role permits access to the resources. Clause 2. The control plane server is further configured to verify that the client has not opted out of using the instance secret management isolation runtime environment before starting the instance secret management isolation runtime environment, of the system according to Clause 1. Clause 3. The control plane server is further configured to obtain, via a programmatic interface, from the client an indicator of expiration criteria for one or more security secrets managed by a secret manager, including the cryptographic key, Clause 3. The control plane server is further configured to obtain, via a programmatic interface, from the client an indicator of expiration criteria for one or more security secrets managed by a secret manager, including the cryptographic key, The secret manager is further configured to obtain a replacement cryptographic key according to the expiration criteria, of the system according to Clause 1 or 2. The secret manager, The system according to Clause 1 or 2, further configured to obtain a replacement cryptographic key according to the expiration criteria. System according to any one of clauses 1 to 3, wherein the secret key is obtained in the secret manager after verification of the validity of at least a part of the installed software of the virtual server. Clause 5. The control plane server System according to any one of clauses 1 to 4, further configured such that the control plane server obtains from the client, via a program interface, an indicator indicating that an authorization role is assigned to a compute instance. Clause 6. A computer-implemented method, using a first subset of the memory allocated to a compute instance of a virtual server of a virtualized computing service to start an instance secret management isolation runtime environment without receiving a request for the instance secret management isolation runtime environment from a client on behalf of which the compute instance is started, the first subset of the memory being inaccessible to programs running outside the instance secret management isolation runtime environment, and the instance secret management isolation runtime environment including a first secret manager; providing, by the first secret manager, to an application within the compute instance, a first security artifact associated with a request to access a first resource from the application, the first security artifact being generated by the first secret manager using a first security secret associated with the compute instance, the first security secret being executable within the compute instance and not accessible to programs not running within the instance secret management isolation runtime environment; obtaining access to the first resource in response to a determination by the application that the first security artifact is valid. A computer-implemented method. Clause 7. Obtaining, via a programmatic interface, a request from a client to assign a first authorization role to a compute instance, wherein a first security secret is generated at least in part based on the first authorization role, and the first authorization role grants the compute instance permission to access a first resource, the obtaining further comprising the obtaining of the computer-implemented method according to clause 6. Clause 8. Obtaining, via a programmatic interface, a request from a client to assign a second authorization role to a compute instance, the second authorization role granting the compute instance permission to access a second resource, the obtaining and Providing, by a first secret manager, to another application within the compute instance, another security artifact associated with a request from the other application to access a second resource, the other security artifact being generated by the first secret manager using a second security secret associated with the second authorization role, the second security secret being executable within the compute instance and not accessible to programs not executed within an instance secret management isolation runtime environment, the providing further comprising the computer-implemented method according to clause 7. Clause 9. Obtaining, via a programmatic interface, an indication that a client has opted in to use an instance secret management isolation runtime environment, the instance secret management isolation runtime environment being launched at least in part based on the indication, the obtaining further comprising the computer-implemented method according to clause 6 or 7. Clause 10. Obtaining, from a client via a programmatic interface, an indication of an expiration criterion for one or more security secrets managed by a first secret manager, including a first security secret The computer-implemented method according to clause 6 or 7 or 9, further comprising obtaining, by a first secret manager, a replacement security secret for a first secret according to an expiration criterion. Clause 11. The computer-implemented method according to clause 6 or 7 or 9 or 10, further comprising validating at least a portion of the installed software of the virtualization server before providing a first security secret to a first secret manager. Clause 12. The computer-implemented method according to any one of clauses 6 or 7 or 9 to 11, further comprising obtaining, by a first secret manager, a first security secret during a boot procedure of an instance secret management isolation runtime environment before generating a request to access a first resource. Clause 13. The computer-implemented method according to any one of clauses 6 or 7 or 9 to 11, further comprising obtaining, by a first secret manager, a first secret in response to an indicator of a request to access a first resource. Clause 14. The computer-implemented method according to any one of clauses 6 or 7 or 9 to 11 or 13, further comprising utilizing, by a first secret manager, one or more shared memory buffers to communicate with an entity external to an instance secret management isolation runtime environment. Clause 15. Starting an isolation runtime environment requested by a client using a second subset of the memory allocated to a compute instance, To generate a second security artifact that is utilized by another application running within a computing instance, a second secret manager running within an isolated runtime environment requested by a client utilizes a second security secret, where the second security secret is obtained from a source indicated by the client and the second security secret is not accessible by a first secret manager, further comprising utilizing, a computer-implemented method according to any one of clauses 6 or 7 or 9 to 11 or 13 or 14. Clause 16. A non-transitory computer-accessible storage medium storing program instructions that, when executed on a processor, launch an instance secret management isolated runtime environment in a virtualized server of a virtualized computing service, where the instance secret management isolated runtime environment utilizes a subset of memory allocated to a computing instance of the virtualized server and the subset of memory is inaccessible to programs running external to the instance secret management isolated runtime environment, and the instance secret management isolated runtime environment includes a secret manager; provide, by the secret manager, to an application within the computing instance, a security artifact associated with a request to access a resource from the application, where the security artifact is generated by the secret manager using a security secret associated with the computing instance and the security secret is not accessible to programs running within the computing instance and not running within the instance secret management isolated runtime environment; obtain access to the resource in response to a determination by the application that the security artifact is valid. A non-transitory computer-accessible storage medium. Clause 17. A security secret is generated based at least in part on an authorization role assigned to a compute instance by a client on whose behalf the compute instance is launched, where the authorization role grants the compute instance permission to access resources, the non-transitory computer-accessible storage medium according to Clause 16. Clause 18. An instance secret management isolation runtime environment is launched after it is determined that a client on whose behalf a compute instance is launched has opted in to use at least one instance secret management isolation runtime environment, the non-transitory computer-accessible storage medium according to Clause 16 or 17. Clause 19. Stores further program instructions that, when executed, cause a secret manager to obtain a replacement for a security secret according to an expiration criterion for the security secret, where the expiration criterion is indicated by a client on whose behalf a compute instance is launched, the non-transitory computer-accessible storage medium according to any one of Clauses 16 - 18. Clause 20. The resource includes one or more of (a) a data item stored in an object storage service, or (b) a data item stored in a database service, the non-transitory computer-accessible storage medium according to any one of Clauses 16 - 19.

[0077] Conclusion Various embodiments may further include receiving, sending, or storing instructions and / or data implemented according to the foregoing description on a computer-accessible medium. Generally speaking, computer-accessible media may include magnetic or optical media, such as storage media or memory media like disks or DVD / CD-ROMs, volatile or non-volatile media such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), ROM, and transmission media or signals such as electrical, electromagnetic, or digital signals transmitted via a communication medium such as a network and / or a wireless link.

[0078] Illustrated in the figures, the various methods described herein represent exemplary embodiments of the methods. The methods may be implemented in software, hardware, or combinations thereof. The order of the methods may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc.

[0079] As will be apparent to those having the benefit of this disclosure, various modifications and changes can be made. It is intended to embrace all such modifications and changes, and accordingly, the above description should be regarded in an illustrative rather than a limiting sense.

Claims

1. A system comprising: one or more computing devices, wherein the one or more computing devices include instructions that, when executed on or across the one or more computing devices, cause a virtualized computing service's virtualized server to launch an instance secret management isolation runtime environment that utilizes a subset of memory allocated to a compute instance of the virtualized server, the subset of memory being inaccessible to programs executing outside the instance secret management isolation runtime environment, the instance secret management isolation runtime environment including a secret manager; the secret manager provides a security artifact associated with a request by an application within the compute instance to access a resource, the security artifact being generated by the secret manager using a security secret associated with the compute instance, the security secret being executable within the compute instance and not accessible to programs not executed within the instance secret management isolation runtime environment; and the application obtains access to the resource in response to a determination that the security artifact is valid.

2. The one or more computing devices further include instructions that, when executed on or across the one or more computing devices, cause the one or more computing devices to obtain an indicator of an expiration criterion of the security secret via a programmatic interface; and further obtain a replacement security secret according to the expiration criterion. The system according to claim 1.

3. The system according to claim 1 or 2, wherein the security secret is obtained in the secret manager after verifying the validity of at least a part of the installed software of the virtualized server.

4. A computer-implemented method, comprising: starting an instance secret management isolation runtime environment in a virtualized server of a virtualized computing service, wherein the instance secret management isolation runtime environment utilizes a subset of the memory allocated to the computing instance of the virtualized server, the subset of the memory being inaccessible to programs running outside the instance secret management isolation runtime environment, and the instance secret management isolation runtime environment includes a first secret manager; providing, by the first secret manager, a security artifact associated with a request for the application in the computing instance to access a first resource, the security artifact being generated by the first secret manager using a first security secret associated with the computing instance, the first security secret being executable within the computing instance and not accessible to programs not executed within the instance secret management isolation runtime environment; obtaining access to the first resource in response to a determination by the application that the security artifact is valid. A computer-implemented method comprising:

5. The computer-implemented method according to claim 4, further comprising obtaining, via a program interface, a request for assigning a first authorization role to the computing instance, wherein the first security secret is generated at least in part based on the first authorization role, and the first authorization role grants the computing instance permission to access the first resource.

6. Obtaining a request for assigning a second authorization role to the computing instance via the programmatic interface, wherein the second authorization role grants the computing instance permission to access a second resource; The first secret manager provides another security artifact associated with a request from another application to access the second resource to another application within the computing instance, wherein the other security artifact uses a second security secret associated with the second authorization role and is generated by the first secret manager, the second security secret is executable within the computing instance and not accessible to a program not executed within the instance secret management isolation runtime environment. The computer-implemented method according to claim 5, further comprising: **Claim 7** Obtaining an indicator that a client by which the computing instance is launched on behalf has opted in to use the instance secret management isolation runtime environment, wherein the instance secret management isolation runtime environment is launched at least partially based on the indicator. The computer-implemented method according to claim 4 or 5, further comprising: **Claim 8** Obtaining an expiration criterion indicator for one or more security secrets managed by the first secret manager, including the first security secret; The first secret manager obtaining a replacement security secret for the first secret according to the expiration criterion. The computer-implemented method according to claim 4 or 5 or 7, further comprising: **Claim 9** Obtaining, by the first secret manager, the first security secret during a boot procedure of the instance secret management isolation runtime environment prior to generating the request to access the first resource. The computer-implemented method according to claim 4 or 5 or 7 or 8, further comprising: **Claim 10** The computer-implemented method according to claim 4 or 5 or 7 or 8, further comprising obtaining the first secret by the first secret manager in response to the metric of the request to access the first resource.

11. The computer-implemented method according to claim 4 or 5 or 7 or 8 or 10, further comprising utilizing, by the first secret manager, one or more shared memory buffers for communicating with entities external to the instance secret management isolated runtime environment.

12. Starting an isolation runtime environment requested by a client using a second subset of the memory allocated to the computing instance; Utilizing a second security secret by a second secret manager running within the client-requested isolation runtime environment to generate a second security artifact utilized by another application running within the computing instance, wherein the second security secret is obtained from a source indicated by a client by which the client-requested isolation runtime environment is launched on behalf, and wherein the second security secret is not accessible by the first secret manager. The computer-implemented method according to claim 4 or 5 or 7 or 8 or 10 or 11, further comprising the step of utilizing.

13. A non-transitory computer-accessible storage medium storing program instructions, wherein when the program instructions are executed on a processor, Starting an instance secret management isolated runtime environment in a virtualized server of a virtualized computing service, wherein the instance secret management isolated runtime environment utilizes a subset of the memory allocated to a computing instance of the virtualized server, and wherein the subset of the memory is inaccessible from programs running external to the instance secret management isolated runtime environment, and wherein the instance secret management isolated runtime environment includes a secret manager. Starting, The secret manager provides a security artifact associated with a request for an application within the compute instance to access a resource from the application, the security artifact being generated by the secret manager using a security secret associated with the compute instance, the security secret being accessible by a program that is running within the compute instance and not running within the instance secret management isolation runtime environment. A non-transitory computer-accessible storage medium that performs, in response to a determination by the application that the security artifact is valid, obtaining access to the resource. **Claim 14** The non-transitory computer-accessible storage medium according to claim 13, wherein the instance secret management isolation runtime environment is launched after a determination is made that a client on whose behalf the compute instance is launched has opted in to use at least one instance secret management isolation runtime environment. **Claim 15** The non-transitory computer-accessible storage medium according to claim 13 or 14, wherein the resource includes one or more of (a) a data item stored in an object storage service, or (b) a data item stored in a database service.

Images