Isolation runtime environment for protecting secrets used to access remote resources from compute instances

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 between 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 requests to access remote resources may need to be protected.

Brief Description of the Drawings

[0002] [Figure 1] An exemplary system environment is illustrated 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. [Figure 2] An exemplary remote request submission protocol that can be employed in a cloud provider network is illustrated, according to at least some embodiments. [Figure 3]This document illustrates the components of a virtualization server in which an instance secret management isolation runtime environment can be invoked, in at least several embodiments. [Figure 4] This illustrates exemplary interactions associated with obtaining instance secrets by a secret manager running within an isolated runtime environment, in at least several embodiments. [Figure 5] This illustrates exemplary interactions associated with sending an access request, in which a signature is generated by a secret manager running within an isolated runtime environment, in at least several embodiments. [Figure 6] This illustrates an exemplary scenario in which, in at least some embodiments, multiple authorization roles, each having its own associated instance secret, may be assigned to a single compute instance. [Figure 7] This illustrates exemplary scenarios in which multiple isolated runtime environments can be established within a compute instance, in at least some embodiments. [Figure 8] This illustrates exemplary programmatic interactions related to instance secret management between a client and a virtualized computing service, in at least some embodiments. [Figure 9] This flowchart illustrates, in at least some embodiments, the actions that may be taken to manage instance secrets using an isolated runtime environment. [Figure 10] This is a block diagram illustrating an exemplary computing device that may be used in at least some embodiments.

[0003] Embodiments are described herein by example of several embodiments and illustrative drawings, but those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood that the drawings and their detailed descriptions are not intended to limit embodiments to any particular form disclosed, but rather to encompass all modifications, equivalents, and substitutes that fall within the spirit and scope defined by the appended claims. Headings used herein are for structural purposes only and are not intended to limit the scope of the description or claims. As used throughout this application, the word “may” is used in an allowable sense (i.e., it has the possibility of) rather than an essential sense (i.e., it must). Similarly, the words “include,” “including,” and “includes” mean “includes, but not limited to.” Where used in the claims, the term “or” is used in an inclusive sense (or) rather than an exclusive sense (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 otherwise explicitly stated, articles such as "a" or "an" should generally be interpreted throughout this application as including one or more described items. Thus, phrases such as "devices configured to perform" are intended to include one or more described devices. Such one or more described devices may also be collectively configured to perform the described descriptions. For example, "processors configured to perform descriptions A, B, and C" may include a first processor configured to perform description A, which operates in conjunction with a second processor configured to perform descriptions B and C. Unless otherwise explicitly stated, the term "set" should generally be interpreted throughout this application as including one or more described items. Thus, phrases such as "set of devices configured to perform" are intended to include one or more described devices.One or more such described devices may also be configured collectively to perform the mentioned descriptions. For example, “a set of servers configured to perform descriptions A, B, and C” may include a first server configured to perform description A, which works in conjunction with a second server configured to perform descriptions B and C. [Modes 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 compute 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 use the credentials to gain access to other resources, which can increase the likelihood of credential misuse. Specifically, this disclosure relates to a “credential-free” authentication protocol for compute instances, which refers to an authentication protocol in which the security secrets used by the instance for authentication are not directly exposed to the instance itself. Security secrets, such as a unique cryptographic key assigned to a compute instance, can be used to prepare requests for access from the compute instance to remote resources within the cloud provider network (e.g., remote resources managed by services other than virtualized computing services). To securely access remote resources, such as data items stored in the provider network's storage services, from a program running on the compute instance, programmatic requests to the remote resources (such as Hypertext Transfer Protocol (HTTP) GET requests) are formatted and digitally signed according to a protocol enforced by the provider network. An authorization role is assigned to a compute instance, for example, at the request of a virtualized compute service (VCS) client on which the compute instance is established, and enables a program running within the compute instance to access or utilize the remote resources or services indicated in the role. One or more security secrets generated for the compute instance based on the authorization role, and referred to herein as “instance secrets,” are used in the process of preparing programmatic requests for sending remote resources to the managed service.

[0005] To support various types of secure computation, including signing requests to 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.” The compute instance to which the IRE is associated and which can utilize the IRE for secure computation is referred to as the IRE’s “parent” compute instance. The IRE can utilize a detached subset of memory allocated to its parent compute instance, and other programs running within the compute instance (i.e., programs not running within the IRE itself) cannot access this detached subset of memory. Programs within the IRE can communicate with external entities only through special local communication channels and communication intermediaries running within the compute instance; accessing persistent storage or establishing network connections is prohibited. Security secrets for various applications can be obtained or provided to trusted programs running within the IRE using local communication channels without exposing the secrets to untrustworthy programs on compute instances not running within the IRE. Such secrets can later be used, for example, at the request of an untrustworthy program, to perform computations by trusted programs within the IRE.

[0006] In general, an IRE can be established for various purposes, for example, at the request of a client running a parent compute instance on its behalf, or at the request of a VCS control plane or management component. An IRE configured as an instance secret management IRE or ISM-IRE can be established automatically for a parent compute instance for the purpose of managing instance secrets, for example, after a VCS client running a parent compute instance on its behalf opts in (or does not opt ​​out) of using ISM-IRE to prepare requests for remote resources. For example, a VCS control plane server can start an ISM-IRE containing a secret manager (e.g., one or more processes or threads) for a parent compute instance by issuing a command to a virtualization management component (VMC) running on the virtualization host where the compute instance is running. In some cases, for example, depending on the machine image used for the compute instance, the ISM-IRE can be started as part of the overall startup procedure for the parent compute instance. The establishment of an ISM-IRE can be described as automatic in that no explicit request to start the ISM-IRE itself is required from the VCS client. Furthermore, a set of one or more instance secrets (such as private encryption keys) of the parent compute instance can be automatically obtained or determined by the secret manager, for example, from the provider network's security service, without requiring the VCS client to request the acquisition of the instance secrets.

[0007] Next, applications running within the parent compute instance can send representations of their access requests to 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 remote resource access request and provide that signature or artifact to the application accessing the remote resource. Along with the request, the application can send the security artifact to a service where the requested resource is managed according to the provider network's remote access protocol, without the application having access to the instance secret. The resource manager or request handler of the remote service can provide access to the resource if it determines that the security artifact is valid, for example, if the authorization role assigned to the compute instance and associated with the instance secret allows or grants the compute instance access to the resource. On the virtualization server where the parent compute instance runs, the instance secret cannot be stored or kept outside of ISM-IRE, nor can it be transmitted to other entities over the network. Therefore, the use of ISM-IRE can substantially reduce the possibility of accidental or intentional breach or "exposure" of the instance secret.

[0008] As a person skilled in the art will understand in light of this disclosure, certain embodiments may be able to achieve a variety of benefits, including some or all of the following: (a) eliminating, or at least substantially reducing, the possibility of accidental or intentional misuse of security secrets used to access remote resources from compute instances implemented in the provider network, even if a malicious entity attempts to gain access to the compute instance in any way or attempt to run a program on the compute 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 the provider network.

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

[0010] In some embodiments, the Secret Manager (SM) may be configured to automatically determine or retrieve, for example, a set of one or more instance secrets (such as cryptographic keys) associated with the authorization role assigned to a compute instance, from a provider network security service, without receiving a request from a client to determine / retrieve instance secrets. In at least one embodiment, the instance secrets 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 indicator of a request for access to a set of resources (managed by the resource manager) of other services, 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 an instance secret. The application may submit a request to the resource manager of the resource to be accessed, along with the security artifacts provided by the SM. The resource manager may grant application access to the resource in response to a decision 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 resource.

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

[0013] In some embodiments, multiple roles may be assigned to a given compute instance at the request of a VCS client, and each set of instance secrets may be generated for each such role. Multiple roles may be used, for example, to enable each subset of an application running on a parent compute instance to access each set of remote resources. In some embodiments, information about the roles used for a given resource access request may be provided by the application to a secret manager (SM), which may use to select the instance secrets to be used to generate the signature or security artifact of the given resource access request.

[0014] According to one embodiment, the VCS may support several options for handling instance secrets. One option may involve establishing the type of ISM-IRE and secret manager introduced above, while another option may involve obtaining instance secrets from a metadata service running on the virtualization server, for example. A VCS client wishing to use the metadata service may, in some embodiments, notify the VCS control plane server accordingly via a programmatic interface. If a VCS client decides to use the metadata service for a particular compute instance or for all compute instances of a client, the ISM-IRE may not be set for those compute instances. In at least some embodiments, the VCS control plane may obtain an indicator that a client has opted in (or not opted out) of the ISM-IRE option and may set the ISM-IRE for each of that client's compute instances only after the client has approved the use of 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 therefore the SM may need to acquire a newer version of the secret from time to time. In one embodiment, a VCS client may provide an indicator of the expiration criterion for one or more instance secrets managed by the SM via a programmatic interface. The expiration criterion may be specified, for example, as a time interval (e.g., "the instance secret expires T minutes after it is created"), based on usage (e.g., "the instance secret expires after it has been used for N resource access requests"), based on a combination of time and usage (e.g., "the instance secret remains valid for at most N resource access requests and expires T minutes after it is created"), or using other factors. After (or immediately before) a given secret expires, the SM may, in various embodiments, acquire a replacement for that secret and then use the replacement version.

[0016] The validity of the software (and / or hardware) state of at least a portion of the virtualization server on which ISM-IRE is launched may, in some embodiments, be verified before an instance secret is generated for the compute instances running on the virtualization server. For example, proof documents indicating the state of the software (including virtualization management component software, ISM-IRE software including SMs, etc.) may be provided to a 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 ISM-IRE boot or startup procedure, for example, prior to any resource access requests from an application running on the parent compute instance of the ISM-IRE. In other embodiments, the instance secrets may be obtained, for example, in response to an index obtained by the SM of a resource access request from an application running on the parent compute instance, at the first time it is needed.

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

[0019] In at least one embodiment, multiple IREs (including at least one ISM-IRE) may be established for a given parent compute instance. For example, the VCS control plane automatically triggers the establishment of an ISM-IRE, but a client whose parent compute instance is set up on its behalf may request the establishment of other IREs that can be used to perform security operations independent of the use of instance secrets. Each IRE, including such a client-requested IRE, may, in such embodiments, include its own secret manager, and the client-requested IRE may 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. In such embodiments, the ISM-IRE may be referred to as a system-generated IRE, in contrast to the client-requested IRE.

[0020] As shown above, VCS may, in various embodiments, be implemented as part of a service suite in a cloud provider network or 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 compute resources, storage resources, and 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 considered as both applications delivered as a service over a publicly accessible network (e.g., the internet or a cellular communication network), and the hardware and software within the cloud provider data center that provides those services.

[0021] A cloud provider network can be formed as several regions, which are isolated geographical areas where the cloud provider clusters its data centers. Such regions may also be called provider network-defined regions, as their boundaries may not necessarily coincide with national, state, or other boundaries. Each region may contain two or more availability zones connected to each other via a private high-speed network, such as fiber optic communication connections. An availability zone (also known as an availability domain, or simply a “zone”) refers to an isolated fault domain containing one or more data center facilities with isolated power, isolated networking, and isolated cooling from those in other availability zones. A data center refers to a physical building or enclosure that houses and provides power and cooling to the servers of the cloud provider network. Preferably, availability zones within a region are located far enough apart from other zones so that the same natural disaster does not bring two or more availability zones offline simultaneously. Customers can connect to the availability zones of the cloud provider network via transit centers (TCs) and publicly accessible networks (e.g., the internet, cellular communication networks). A TC can be considered a primary backbone location linking the customer to the cloud provider network, and may be co-located with other network provider facilities (e.g., Internet service providers, telecommunications providers) and securely connected to availability zones (e.g., via a virtual private network (VPN) or direct connection). Each region may operate two or more TCs for redundancy. Regions are connected to a global network that connects each region to at least one other region. The cloud provider network may deliver content from presence points outside these regions via edge locations and region edge cache servers (presence points, or PoPs), or may be networked with these regions.This partitioning and geographic distribution of computing hardware enables a cloud provider network to provide customers with low-latency resource access at a 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 the VCS extended location. The edge location (or "edge zone") 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 that is 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 the region. Typically, a local zone will have a more limited capacity than a region, but in some cases, a local zone can have a substantial capacity of, for example, thousands of racks or more. Some local zones may use an infrastructure similar to that of a typical cloud provider's data center. The VCS extended location may 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 reduction, 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 to an account associated with the cloud provider, in contrast to resources requested by a user of the cloud provider network, which may be provisioned to a user account.

[0024] Various network-accessible services may be implemented in different embodiments at one or more data centers, edge locations, and / or extension locations of a provider network. Network-accessible computing services may include elastic computing cloud services or VCSs (referred to in various implementations as elastic computing services, virtual machine services, computing cloud services, computing engines, or cloud computing services). Such services may present computing instances (guest virtual machines, or simply "instances") with various computing and / or memory resources, managed by a computing virtualization service (referred to in various implementations as elastic computing services, virtual machine services, computing cloud services, computing engines, or cloud computing services). In one embodiment, each virtual computing instance may correspond to one of several instance types or families. An instance type may be characterized by its 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 preferred descriptive characteristics (such as a “burstable” instance type having baseline performance guarantees and the ability to periodically burst above that baseline, or a non-burstable or dedicated instance type with a fixed amount of resources allocated and guaranteed). In some embodiments, one or more instance types may support the automatic establishment of ISM-IRE of the types introduced above. Each instance type may have a specific ratio of processing, local storage, memory, and networking resources, and different instance families may have different types of these resources.Multiple sizes of these resource configurations may be available within a given instance type. Using the instance type selection feature, an instance type may be selected for a customer, for example, based (at least partially) on customer input. 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 for an instance type and / or the requirements of the workload on which the instance will run, and the instance type selection feature may select an instance type based on such specifications. A suitable host for the requested instance type can be selected, at least partially, based on factors such as collected network performance metrics and resource utilization levels on different available hosts. In some embodiments, instances of several different instance types may be launched in an extended facility in response to programmatic requests from clients. Other types of network-accessible services, such as packet processing services, database services, and wide area networking (WAN) services, may also be implemented in the cloud provider network in some embodiments.

[0025] Traffic and operations of a cloud provider network (or individual services of a cloud provider network, including VCS) can, in various embodiments, be broadly categorized into two types: control plane operations, which are performed via a logical control plane, and data plane operations, which are performed 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 generally includes one or more control plane components, distributed across one or more control servers and implemented by one or more control servers. Control plane traffic generally includes management operations such as system configuration and management (e.g., resource allocation, hardware capacity management, diagnostic monitoring, or system status information). The data plane includes customer resources implemented on the cloud provider network (e.g., computing instances, containers, block storage volumes, databases, or file storage). Data plane traffic generally includes non-management operations such as transferring customer data to and from customer resources. Certain control plane components (e.g., Tier 1 control plane components such as the control plane for virtualized computing services) are typically implemented on a set of servers separate 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 may be delivered on separate / independent networks.

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

[0027] Some compute instances may include application programs that need to access resources in other services on 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 compute instance 134 may be adopted and enforced in the provider network 102. An example of such a protocol is described below in the context of Figure 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 the resource access request) may be generated using an instance secret assigned to the compute instance from which the compute instance originates. In at least some embodiments, SSS 160 may be responsible for generating the instance secret. The security artifact may be sent along with the resource access request to a resource manager 167 responsible for the data item being accessed, and access to the data item may be provided by the resource manager only after the security artifact has been verified to be valid, in the illustrated embodiment. A given compute instance 134 may be assigned one or more authorization roles (also referred to as access management roles) at the request of a VCS client from which the compute instance is invoked on its behalf. In various embodiments, a given role may include rules indicating the types (or specific lists) of remote resources that can be accessed from compute instances, and instance secrets may be generated based at least partially on the role. In the illustrated embodiment, information about the role may be stored in IRMS162.

[0028] In the embodiment illustrated in Figure 1, one or more control plane servers (such as an instance secret processing coordinator 118 and / or an instance state change manager 114) may automatically start each instance secret management isolation runtime environment (ISM-IRE) within at least some compute instances (e.g., using isolated portions 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 ISM-IRE. While the CIs themselves may be started in response to programmatic requests from VCS clients, the ISM-IRE may, in at least some embodiments, be started without receiving a specific client request to do so. Communication to and from ISM-IRE may be severely restricted in various embodiments, for example, network communication may not be permitted, or input / output to persistent storage may be prohibited. 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 may be implemented, for example, using one or more processes or threads. In some embodiments, the VCS control plane may invoke only the ISM-IRE on the client's CI in response to an indicator that the client has opted in to using 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 ISM-IRE secret manager may obtain, determine, or retrieve a set of instance secrets associated with the roles assigned to its parent compute instance (the compute instance on which the ISM-IRE is configured). For example, a highly secure communication path may be established between the ISM-IRE and the SSS160 (using a local communication channel) to retrieve instance secrets. In response to receiving an indicator of a resource access request originating from an application running within the parent CI (e.g., an access request directed to data item 166 of storage service 164), 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 the appropriate instance secrets and provide the security artifact to the application. The application may then send the security artifact along with the request to the resource manager 167. After the security artifact is validated (e.g., by the resource manager itself or by an authentication / authorization service invoked by the resource manager) and the resource manager confirms that the compute instance is authorized to access the target resource (e.g., based on the roles assigned to the compute instance), access to the resource may be granted in the illustrated embodiment. In various embodiments, access to the target resource may be denied if a security artifact is found to be unacceptable or invalid, or if the associated role does not permit access to the target resource.

[0030] In some embodiments, a given CI may be assigned multiple authorization roles (each enabling an application to access a different set of resources), each set of instance secrets may be generated in accordance with each role, and each set of instance secrets may be used in the manner described above to enable resource access according to the corresponding role. In some embodiments, in addition to the automated 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 may be 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 in those CIs, forcing 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 virtualization server may be verified, for example, using proof documents prepared by the VMC, before the instance secrets are provided to the SM running on the virtualization server's ISM-IRE. In one embodiment, at least some instance secrets may be acquired by the SM when the parent CI and ISM-IRE start up (or immediately thereafter), and in another embodiment, some or all instance secrets may be acquired only in response to detecting that a request to access a remote resource was generated by an application running on the parent CI.

[0031] VCS110 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, and graphical user interfaces. Such interfaces may be used by VCS clients to request various types of configuration actions from 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 start or instantiate compute instances (CIs) 134, opt in or opt out of using ISM-IRE, or submit preferences regarding instance secret expiration criteria. In various embodiments, each compute instance 134 may include its respective virtual machine and / or other type of program execution platform (such as a bare-metal instance with direct control granted to more hardware devices than are granted to guest virtual machines).

[0032] In some embodiments, at least some client requests may be directed to the VCS control plane 112. In the illustrated embodiments, control plane servers such as the instance state change manager 114, provisioning manager 116, instance secret processing coordinator 118, and client request handler 119 may each be implemented using some combination of hardware and software on one or more computing devices. A client request for a compute instance may be processed first, for example, by the request handler 119. The request handler may perform some initial checks (for example, to verify that the client has permission for the type of operation being requested) 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, for example, in the illustrated embodiments, be responsible for starting, stopping, and migrating compute instances implemented on virtualization servers in the VCS virtualization server fleet 130. The provisioning manager 116 may, for example, in the illustrated embodiments, be responsible for identifying the specific virtualization server on which one or more requested compute instances will be started.

[0033] A virtualization manager component (VMC) 137 (which may include a hypervisor) in a virtualization server can act as an intermediary between compute instances 134 and at least some of the hardware elements of the VS, including, for example, physical processors (e.g., a central processing unit (CPU), a graphical processing unit (GPU), etc.), memory, persistent storage devices, networking cards, peripheral devices, etc. In some embodiments, at least a portion of the virtualization management responsibilities may be offloaded from the primary processor or CPU to a hardware card (e.g., a card linked to the CPU of the VS via a peripheral connectivity interface or PCI-Express interconnect, referred to as an offload card) in order to free up more primary processor computing power for compute instances.

[0034] In the illustrated embodiments, after a request to start a compute instance is sent by the client to the VCS control plane, a corresponding internal command to start the instance may 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, may be allocated to the compute instance by the virtualization manager component. In some embodiments, the control plane server may send a request to the VMC to start the ISM-IRE, for example, as part of an internal command that results in the startup of the CI itself. In other embodiments, a separate request and / or command may be sent to the virtualization server to start the ISM-IRE after, for example, the compute instance 134 has already been configured. In some embodiments, at least a portion of the memory allocated to the compute instance may be isolated or reserved by the VMC 137 for the ISM-IRE 136. As shown in Figure 1, the resources of a given virtualization server 132 (e.g., 132A and 132B) may, in at least some embodiments, be used for multiple compute instances, some of which may be configured on behalf of different VCS clients. Other virtualization servers may have one or more compute instances configured on behalf of a single client. Each subset of resources allocated to a given compute instance may be isolated or partitioned for multiple IREs in several scenarios (e.g., including an ISM-IRE and one or more client-requested IREs). In at least some embodiments, the lifetimes of client-requested IREs and their parent compute instance (or other client-requested IREs on the same compute instance) may differ, 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, an ISM-IRE may only terminate when its parent CI terminates.In at least some embodiments, resources of a parent compute instance that are isolated or reserved for the IRE may not be accessible to programs or processes running on the parent compute instance. For example, if 4 gigabytes of the total 32 gigabytes of memory initially allocated to a CI are reserved for the ISM-IRE, programs / processes within the CI can only access and use the remaining 28 gigabytes.

[0035] As described above, when configuring or instantiating an IRE, in various embodiments, several constraints may be enforced to limit the manner in which a program or process within the IRE can communicate or interact with other entities (e.g., processes / programs running inside or outside the parent compute instance). In at least one embodiment, for example, an IRE process / program may be prohibited from over-the-wire networking communication with any entity outside 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 to prohibit access to persistent storage devices and / or file systems, i.e., processes / programs within the IRE may not be able to perform reads or writes to persistent storage. In some embodiments, one or more communication intermediary processes (CIPs) or daemons may be instantiated in the parent compute 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 compute 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 bidirectional communication between the CIP and the IRE, for example, notifications 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 the buffer, when the IRE is ready to send an outbound message in 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 VS, including at least some parts of the VMC itself. The security manager may perform measurement and / or proof 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 result of the hash function may be compared to the hash result 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 a unique identifier for IRE and / or its parent compute instance, may also be provided in at least some embodiments.

[0037] In embodiments where SSS160 generates the instance secret, a mechanism may be employed to prevent the unencrypted version of the instance secret from being interfered with or accessed by any party other than the SSS and ISM-IRE itself. In some embodiments, for example, a logical equivalent of a TLS (Transport Layer Security) session may be established between the SSS and the 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 Intermediation Process (CIP) on its way from the client to ISM-IRE, but it should be noted that in various embodiments, the CIP may not have the shared secret key necessary to decrypt the secret. 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, in at least some embodiments. In the illustrated scenario, an application program 236 running on a compute instance (CI) 234 needs to access a data item 266 in a storage service 264, configured by a request from client 1, which is a client of a VCS similar to VCS 110 in Figure 1. 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 for a cloud provider network where VCS and storage services are implemented may include several steps in the illustrated embodiment. In the first step, labeled as step A in Figure 2, a canonical or standardized request may be created for data items such as a well-structured version of an HTTP GET or PUT request. The elements of the request, including, for example, the HTTP request method, the target service name or service host name represented as a URI (Uniform Resource Identifier), a query string, and various HTTP headers, may have to be arranged in a specific order using a specified delimiter (such as a newline token) to separate 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 a digest of the canonical request, a representation of the data and time the request is generated, a representation of the credential 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 may be generated or computed. As part of the process of generating the signature, a signing key may be created using the CI's instance secret. In some embodiments, a set of hash-based message authentication codes (HMACs) may be generated to ultimately obtain the signing key. The signing key and the string to be signed (generated in step B) may be provided as input to a keyed hash function, the output of which may represent the signature. In some embodiments, the instance secret itself may be generated (e.g., in the provider network's security secrets service) based at least in part on the authorization role assigned to the CI by client 1. 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) from which the instance secret is created in some implementations.

[0041] In step D, the signature and request may 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 may be provided to the requesting application in step E; if the signature is invalid, access may be denied in at least some embodiments.

[0042] Protocol 277 does not necessarily impose strict requirements in some embodiments regarding how or by which entity / program the signature is computed, 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 use the ISM-IRE-based techniques described above, the secret key may be stored in plain text on the CI, hardcoded in application 236, read from a file by the application, or handled in any other way chosen 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 application program 236 itself.

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

[0044] In various embodiments, a Communication Intermediary Process (CIP) 348 may be instantiated within a compute instance 344. 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 for establishing the ISM-IRE 346, and in other embodiments, the CIP daemon may be started 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 to the ISM-IRE 346 from any other entity that wishes to communicate with the ISM-IRE (including, for example, an external source 355 of instance secrets such as a security secrets service similar to the SSS 160 in Figure 1), and in various embodiments, it 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 a configuration step to ensure isolation of ISM-IRE from any external entities (e.g., VMC334), the ISM-IRE346 process / program may not be permitted to transfer data to any entity or endpoint via a network connection using the virtualization server's network interface card, and in such embodiments, all communication to and from ISM-IRE may have to pass through CIP. Similarly, in some embodiments, the configuration settings of ISM-IRE346 may also prohibit interaction between IRE and persistent storage, and in such embodiments, interaction between ISM-IRE346 and the file system. That is, reading from and writing to persistent storage may not be permitted from the ISM-IRE process / program. The local communication channel 349 may be configured for data transfer between CIP and ISM-IRE in at least some embodiments. For example, in one embodiment, a portion of shared memory accessible to both CIP and ISM-IRE may be designated or mapped to store data being transferred into / out of ISM-IRE.In some embodiments, bidirectional notification or interrupt-based mechanisms can be used to indicate when data is ready to be read by ISM-IRE (for data inbound to ISM-IRE) or when it is ready to be read by CIP (for data outbound from ISM-IRE). Compute instance 344 may include various other processes / programs, such as application components 356 and / or operating system components of the compute instance, which in the illustrated embodiments may be less reliable than ISM-IRE (from the perspective of the VCS control plane and / or VCS client) with respect to performing computations using security secrets.

[0045] In at least some embodiments, a configuration verification operation may be performed with respect to ISM-IRE at one or more points in the lifetime of 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 in Figure 1) to CIP348, which may pass the query to ISM-IRE. The IRE security manager (IRESM) 336 may determine that the query is directed to ISM-IRE 346 based, for example, on indicators provided by CIP348 or ISM-IRE 346. The IRESM 336 may then perform a configuration verification / analysis operation on the software stack of 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 ISM-IRE 346, and the output hash value may represent the signature of the software stack. In at least some embodiments, the IRESM 336 may perform proof of the IRE software stack. In the illustrated embodiments, the results of configuration measurement / verification tests employed by IRESM336 may be provided to the verification requester. In such scenarios, the results may be passed from IRESM to ISM-IRE, from ISM-IRE to CIP, and ultimately to the verification requester. In other embodiments, a different path than that used for querying may be used for the verification results. In at least some embodiments, in addition to the authentication / verification results and nonce, the verification requester may also be provided with (a) an indicator of IRESM's identity similar to a TLS certificate rooted in a trusted certificate authority, and (b) an indicator of ISM-IRE and / or its parent computation instance (e.g., including one or more public keys of their respective asymmetric key pairs). The verification requester can then verify that the proof results and identity information are acceptable, and if acceptable, ISM-IRE may be designated as trusted and verified for computations involving the use of instance secrets. In some embodiments, hash value-based verification of the ISM-IRE software state may be performed by VMC334.In embodiments where a client-requested IRES is established on a compute instance, it should be noted that similar state verification procedures may be initiated by the client at various stages of the client-requested IRE's lifetime.

[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 ISM-IRE as part of operation 391, for example, at the request of a secret manager 388 in 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 ISM-IRE. Within compute instance 344, CIP and 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 CIP even if CIP passes the session's messages to / from ISM-IRE may be securely transferred to ISM-IRE 346. The secret manager 388 in IRE 346 may then begin performing compute using the instance secret, such as generating a signature for a request to access a remote resource from a less trustworthy application component 356. In some embodiments, a secret provisioning agent 357, such as a privileged operating system thread of the compute instance, may prompt the secret manager to obtain the instance secret 387.

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

[0048] In response to receiving an AcquireSecret request, the ISM-IRE secret manager 404 may send a GetNonce request 451 to the provider network's Security Secrets Service (SSS) 407 using a secure communication path, for example, with the use of CIP and local communication channels. A nonce (e.g., a pseudorandom number) may be used to tie together the various messages of the secret acquisition procedure shown in Figure 4, and the sender of the request for the operation may include a nonce in the request, and may trust the response only if, for example, the response contains the same nonce. Such a nonce may be used in a cryptographic system to prevent a copy of the request from succeeding (e.g., submitted by a malicious program or entity that has somehow accessed the content of the request). In some embodiments, the identifier of the parent compute instance and the role assigned to the parent compute instance may be provided as part of the GetNonce request and used in the computation used to generate the nonce in the STS. In one embodiment, the VCS may maintain an instance profile for each compute instance, which describes various characteristics of the compute instance, including the roles assigned to the compute instance. The profile may be included in a GetNonce request and may be used to generate a nonce. The nonce may be provided to the ISM-IRE by the STS, as indicated by arrow 452.

[0049] According to at least some embodiments, as previously shown, the software state of the virtualization server may be verified before the SSS generates an instance secret for the secret manager. In the embodiment illustrated in Figure 4, the secret manager 404 may request a proof document or proof object indicating the software state from the virtualization management component (VMC) (e.g., hypervisor) 410 of the virtualization 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 one embodiment, where the virtualization server includes a physical trusted platform module (TPM) or a virtualized TPM, the contents of the TPM indicating a measure of the virtualization server's software state may be included in the GetAttestation request. In other embodiments, data obtained from the TPM may not be used for proof. In some embodiments, the software of the ISM-IRE may be proven without proving the rest of the virtualization server's software stack. In other embodiments, the software of the ISM-IRE, the parent compute instance, and / or the VMC itself may be proven. The VMC generates a certification document 454 and, in the illustrated embodiment, may provide the secret manager with a digitally signed version of the certification document / object. The certification document or object may actually indicate that the VMC has verified that the ISM-IRE is legitimate (i.e., that the state of the software used in the ISM-IRE has been verified).

[0050] In the illustrated embodiment, the secret manager may include a signed certification document or object in the GetSecret request 455 sent to the SSS 407. In some implementations, the parameters of the GetSecret request may 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, if the certification information is satisfactory or has been successfully validated, the SSS may examine the certification document and generate an instance secret 456. 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, which are also used in the process of signing requests to, for example, remote applications. In some implementations, the secret manager may then provide a response to the secret provisioning agent's AcquireSecret request 450. An instance secret identifier or a token referred to as 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 one such embodiment, the InstanceSecretID may be provided by the secret provisioning agent to an application program 413 that makes a request to access a remote resource.Note that the InstanceSecret itself may not be exposed to the secret provisioning agent by the secret manager, but instead, the InstanceSecretID (and in some implementations, other security data such as session tokens and / or key identifiers) which can be provided as a pointer or reference to the InstanceSecret may be exposed to the secret provisioning agent (and from the agent to application program 413).

[0051] Figure 5 illustrates an exemplary interaction associated with sending an access request, in at least some embodiments, where the signature is generated by a secret manager running within an isolated runtime environment. After the instance secret has been obtained in the secret manager using the operation 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-signed portion of preparing the remote request. Such a request may include a GetAdditionalSecurityData request 551, whose parameters may include an InstanceSecretID previously provided to the application program by the secret manager via a secret provisioning agent. The response, an AdditionalSecurityData message 552, may include, for example, the account key identifier of the client on which the parent compute instance was established on behalf of the client, a session token that can be used to control the expiration of the request and / or the instance secret. In at least some embodiments, the additional security data may not need to be protected to the same degree 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 may be generated in application program 413, and the corresponding string for signing may be generated in or by the application (e.g., by an SDK component or command-line tool), as described above in the context of Figure 2. The string for signing may be shown in SignAccessRequest553 sent from application program 413 to the secret manager using, for example, a communication mediation process (CIP) and local communication channel of the type shown in Figure 3. The InstanceSecretId may be included in the parameters of the SignAccessRequest message in some embodiments. The signature 554 of at least a portion of the request may be generated by the secret manager using the instance secret and sent to application program 413 in the illustrated embodiments. The application program may then send AccessRequest555 to the resource manager of the remote service 514 that manages the target resource for which access is desired, along with the signature generated for the request. The resource manager may then, in some embodiments, send a request to the authentication service 517 (also referred to as the authorization service) to verify the validity of the signature (in the CheckSignature message 556). If the signature is verified as valid, in the illustrated embodiment, a SignatureOK message 557 may be sent from the authentication service to the resource manager of the remote service 514; if the signature is invalid, in at least some embodiments, a message indicating that the signature is invalid may be sent instead. After the resource manager determines that the signature is valid, access to the resource may be granted, for example, to an application program, and the requested data (in the case of a read request) may be provided in a RequestedData message 558. If the access involves writing to a data object, in one embodiment, the write may be performed on the data object, and an indicator of the write's success may be provided.In some embodiments, the authentication service 517 may not be required, and the resource manager of the remote service 514 may validate the signature itself. In one embodiment, in addition to the signature, a session token or other metadata identifying the compute instance from which the access request is originating and / or the ISM-IRE of that compute 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 checks before the signature is approved.

[0053] Figure 6 illustrates an exemplary scenario in which, in at least some embodiments, multiple authorization roles, each having its own associated instance secret, may be assigned to a single compute instance. A compute instance 634 of the VCS, similar to the VCS 110 in Figure 1, includes application programs 636 and 637 in the exemplary scenario illustrated in Figure 6. The ISM-IRE 680, with its secret manager 682, is started using a subset of the memory of compute instance 634.

[0054] Application program 636 needs to access a remote external resource 652, while application program 637 needs to access a remote external resource 653. In some cases, external resource 652 may be part of, or managed by, a network-accessible service of a different provider network than external resource 653, while 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 the provider network's data center; for example, one set of external resources may be located in a client facility of the provider network.

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

[0056] As mentioned above, in some embodiments, a VCS client may want to start its own IRE and use the IRE to manage secrets other than the instance secret assigned to the compute instance. Figure 7 illustrates an exemplary scenario in which multiple isolated runtime environments may be established within a compute instance, in at least some embodiments. In the illustrated scenario, compute instance (CI) 734 is started on the VCS virtualization server in response to an instance start request from VCS client C1. ISM-IRE 740 is automatically started by the VCS within compute instance 734, and an isolated memory subset 778 of the total memory 777 initially allocated to the parent compute instance 734 is reserved for use by ISM-IRE 740. A secret manager running within ISM-IRE 740 utilizes the instance secret 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 authorization role assigned to CI 734.

[0057] Client C1 may also wish to use the isolated runtime environment to perform other security-related calculations in the illustrated embodiment. Since the ISM-IRE is configured by the VCS in particular to manage instance secrets, in the illustrated embodiment, client C1 may not be provided with access to the ISM-IRE. Instead, client C1 may submit a programmatic request to the VCS control plane requesting the establishment of a second IRE, labeled as client-requested IRE744 in Figure 7. In the illustrated embodiment, a second isolated memory subset 779 may be utilized for client-requested IRE744, and a second secret manager may be executed within client-requested IRE744. This secret manager may be provided with security secrets from a source indicated by client C1 (for example, used on behalf of application program 737) using a local communication channel similar to channel 349 shown in Figure 3. In some implementations, the same communication mediation process (similar to CIP348 in Figure 3) may be shared by the ISM-IRE and the client-requested IRE, while in other implementations, an isolated CIP may be used. A client-requested IRE may share many of the characteristics and features previously discussed for ISM-IRE (e.g., limitations on network and persistent storage I / O). Differences between a client-requested IRE and ISM-IRE may include: (a) the VCS control plane may initiate ISM-IRE without receiving a request from the client, while a client-requested IRE may only be initiated when requested by the client; (b) the sources of security secrets used may differ; and (c) a client-requested IRE may be terminated at the client's request, while ISM-IRE cannot. In some embodiments, multiple client-requested IREs may be established as needed.In one embodiment, multiple ISM-IREs may be launched in a single compute instance to which multiple roles are assigned, and each ISM-IRE is used to manage and use the respective instance secret corresponding to one of the multiple roles.

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

[0059] In the illustrated embodiments, a client may submit a LaunchCI request 817 to request 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 the program running within the CI. If the ISM-IRE property is enabled for the type of instance requested by the client (e.g., by default or after the client opts in), in some embodiments, the VCS control plane may invoke 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, invocation of ISM-IRE may be deferred until later in the compute instance's lifetime, for example, until an indicator 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 invoked.

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

[0061] A client may want to modify (or remove) an authorization role assigned to a compute instance. In some embodiments, a ModifyRole request 833 specifying the change (e.g., granting access to additional remote resources, or removing permissions to access certain resources) may be submitted via a programmatic interface 877. An indicator of the change 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 in Figure 1, or an identity and role management service, instead of being stored in the VCS itself, or in addition to the VCS. In such an embodiment, if a client wants to modify a role, it may send a corresponding request to the access management service or IRMS, which 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 ISM-IRE secret manager 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 a maximum amount of time an instance secret remains valid, or a maximum number of remote resource access requests that can use a given instance secret, after which a new version of the instance secret must be obtained by the ISM-IRE secret manager. Expiring secrets in this way further reduces the extent to which they could be misused. In the illustrated embodiment, the client may submit an InstanceSecretsExpirationPreferences message 843 indicating one or more criteria that should be used for one or more instance secrets among the client's compute instances. The preferences may be stored by the VCS control plane, and an ExpirationPreferencesApplied message 845 may be sent to clients for whom the preferences are enforced.

[0063] The VCS control plane (and / or the control plane of any other service managing remote resources accessed from compute instances) may, in some embodiments, capture various metrics related to remote access where instance secrets are used, such as the number of remote accesses per unit time and log records of such accesses indicating which specific remote resources were accessed. In one embodiment, a client may submit a GetInstanceSecretsUsageMetrics request 847 to view at least some 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 accompanying the use of ISM-IRE other than those shown in Figure 8 may be supported by the VCS.

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

[0065] Compute instance CI1 can be started on the virtualization server VS in response to an instance startup request from a client (element 904). In various embodiments, ISM-IRE can be started automatically within CI1 without receiving a request to start ISM-IRE (element 907). In various embodiments, a portion of the memory allocated to CI1 may be reserved for use by ISM-IRE. This isolated portion of memory may be inaccessible to any program not running within ISM-IRE itself (including other programs running in CI1). Network communication may be prohibited from ISM-IRE, and access to persistent storage may also be prohibited from ISM-IRE in at least some embodiments. A secure local communication channel of the kind with an associated communication mediation process (CIP), as shown in Figure 3, may, in some embodiments, provide a means of communication between ISM-IRE and an external entity.

[0066] In the illustrated embodiment, a secret manager (SM) running within ISM-IRE may retrieve or determine one or more instance secrets (such as cryptographic keys) associated with an authorization role assigned to CI1 (element 910). The role may, in at least some embodiments, be defined by a client on 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 ISM-IRE.

[0067] The SM may obtain an index of requests generated by applications running within CI1 to access one or more remote resources outside of CI1 (element 913). Remote resources may include data stored in another service on the provider network where the VCS is implemented, such as a storage service, a machine learning service, or a database service.

[0068] In various embodiments, the SM may use the instance secret to generate a security artifact associated with a remote access request (such as a digital signature of at least a portion of the request) (element 916). The security artifact may be transferred, transmitted, 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 artifact, along with the request itself, to the resource manager of the remote resource for which access is desired (element 922). If the resource manager determines that the security artifact is valid and therefore CI1 is permitted to access the requested resource, the application may, in the illustrated embodiment, obtain access to the resource (element 928). In some embodiments, the resource manager may utilize another service, such as an authorization / authentication service on the provider network, to determine whether the artifact is valid, and in other embodiments, the resource manager may perform the validity / invalidity determination itself.

[0069] It should be noted that in various embodiments, some of the operations shown in the flowchart of Figure 9 may be implemented in a different order than shown in the figure, or may be performed in parallel rather than sequentially. Furthermore, some of the operations shown in Figure 9 may not be necessary in one or more implementations.

[0070] In at least some embodiments, a server implementing the types of techniques described herein (e.g., including VCS, security secrets service, storage service, database service, authorization / authentication service, identity and role management service, and / or other services of a cloud provider network) may include a general-purpose computer system configured to include or access one or more computer-accessible media. Figure 10 illustrates such a general-purpose computing device 9000. In the illustrated embodiment, the 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. The computing device 9000 further includes a network interface 9040 coupled to the I / O interface 9030.

[0071] In various embodiments, the 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 preferred number). The processors 9010 may be any preferred processor capable of executing instructions. For example, in various embodiments, the processors 9010 may be general-purpose or embedded processors implementing one of a variety of instruction set architectures (ISAs), such as x86, PowerPC, SPARC, ARM, or MIPS ISA, or any other preferred ISA. In a multiprocessor system, each of the processors 9010 may implement the same ISA, though this is usually not always the case. In some implementations, graphics processing units (GPUs) and / or field-programmable gate arrays (FPGAs) may be used instead of, or in addition to, conventional processors.

[0072] The system memory 9020 may be configured to store instructions and data accessible by the processor 9010. In at least some embodiments, the system memory 9020 may include both volatile and non-volatile portions, while in other embodiments, only volatile memory may be used. In various embodiments, the volatile portion of the system memory 9020 may 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, for example, 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 may include a power source, such as a supercapacitor or other energy storage device (e.g., a battery). In various embodiments, one of memristor-based resistive random-access memory (ReRAM), three-dimensional NAND technology, ferroelectric RAM, magnetoresistive RAM (MRAM), or various types of phase-change memory (PCM) may be used for at least the non-volatile portion of the system memory. In the illustrated embodiment, program instructions and data that implement one or more desired functions, such as the methods, techniques, and data described above, are stored and shown in system memory 9020 as code 9025 and data 9026.

[0073] In one embodiment, the I / O interface 9030 may be configured to coordinate I / O traffic between any peripheral devices within the device, including the processor 9010, system memory 9020, and other peripheral interfaces such as the network interface 9040 or various types of persistent and / or volatile storage devices. In some embodiments, the I / O interface 9030 may perform any necessary protocols, timing, or other data conversions to convert data signals from one component (e.g., system memory 9020) into a format suitable for use by another component (e.g., 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 divided into two or more separate components, such as a northbridge and a southbridge. Furthermore, 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 directly incorporated into the processor 9010.

[0074] The network interface 9040 may be configured to enable data exchange between a computing device 9000 and other devices 9060 attached to the network 9050, such as other computer systems or devices illustrated in Figures 1 to 9. In various embodiments, the network interface 9040 may support communication over any suitable wired or wireless general data network, such as an Ethernet network. Furthermore, the network interface 9040 may support communication over telecommunications / telephony networks, such as analog voice networks or digital fiber optic networks, communication over storage area networks, such as Fibre Channel SANs, or communication over any other suitable type of network and / or protocol.

[0075] In some embodiments, system memory 9020 may represent an embodiment of a computer-accessible medium configured to store at least a subset of program instructions and data used to implement the methods and apparatus discussed in the context of Figures 1 to 9. However, in other embodiments, 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-temporary storage media or memory media such as disks or magnetic or optical media such as DVDs / CDs coupled to computing device 9000 via I / O interface 9030. Non-temporary 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, multiple non-temporary computer-readable storage media may collectively store program instructions, which, when executed on one or more processors or across multiple processors, perform at least one subset of the methods and techniques described above. The computer-accessible media may further include transmission media or signals, such as electrical, electromagnetic, or digital signals, transmitted over communication media such as networks and / or wireless links, which may be implemented via network interface 9040. Some or all of a plurality of computing devices, as illustrated in Figure 10, may be used to implement the functionality described in various embodiments, for example, software components running on various different devices and servers may cooperate to provide functionality. In some embodiments, some of the functionality described may be implemented using storage devices, network devices, or dedicated computer systems, in addition to, or instead of, being implemented using a general-purpose computer system.As used herein, the term “computing device” refers to, but is not limited to, at least all of these types of devices.

[0076] Embodiments of this disclosure may be described in consideration of the following provisions. Clause 1. A system, The control plane server for virtualized computing services in a cloud provider network, Virtualized servers for virtualized computing services, A resource manager for a collection of resources of another service on the cloud provider network, The control plane server, The instance secrets management isolation runtime environment is started on the virtualization server, wherein the instance secrets management isolation runtime environment uses a subset of the memory allocated to the compute instances of the virtualization server, the instance secrets management isolation runtime environment is started without receiving a start request to the instance secrets management isolation runtime environment from a client of the virtualized computing service on which the compute instances are started on behalf of the instance secrets management isolation runtime environment, the subset of memory is inaccessible to programs running outside the instance secrets management isolation runtime environment, network communication with endpoints outside the virtualization server is prohibited from the instance secrets management isolation runtime environment, and the instance secrets management isolation runtime environment is configured to start, including the secrets manager. The secret manager said, Determining the cryptographic key associated with the authorization role assigned to a compute instance from the security services of the cloud provider network without receiving a request from the client to determine the cryptographic key, wherein the cryptographic key is (a) not accessible by a program running on the virtualization server and (b) not running within the instance secret management isolation runtime environment. This involves obtaining an index of requests for accessing a set of resources generated by applications running within a compute instance, and The application is configured to provide a signature associated with at least a portion of the request, wherein the signature is generated by a secret manager using at least a cryptographic key, and to provide the signature. The resource manager, A system configured to grant an application access to a resource in response to a determination that the signature is acceptable and that the authorization role permits access to the resource. Clause 2. The control plane server, The system described in Clause 1 is further configured to verify that the client has not opted out of using the Instance Secrets Management Isolation Runtime Environment before initiating the Instance Secrets Management Isolation Runtime Environment. Clause 3. The control plane server, The client is further configured to obtain, via a programmatic interface, an expiration criterion for one or more security secrets managed by the secret manager, including cryptographic keys. The secret manager said, The system described in Clause 1 or 2, further configured to obtain replacement cryptographic keys in accordance with expiration criteria. Clause 4. The system described in any one of Clauses 1 to 3, in which the encryption key is obtained in the secret manager after validating at least a portion of the software installed on the virtualization server. Clause 5. The control plane server, A system described in any one of Clauses 1-4, further configured to obtain, via a programmatic interface, an indicator from the client that an authorization role is assigned to a compute instance. Article 6. Computer implementation method, The process involves starting an instance secrets management isolation runtime environment using a first subset of memory allocated to a compute instance of a virtualization server of a virtualized computing service, without receiving a request to the instance secrets management isolation runtime environment from a client on which a compute instance is started on behalf of the client, wherein the first subset of memory is inaccessible to programs running outside the instance secrets management isolation runtime environment, and the instance secrets management isolation runtime environment includes a first secrets manager. The first secret manager provides an application within a compute instance with a first security artifact associated with a request from the application to access a first resource, wherein the first security artifact is generated by the first secret manager using a first security secret associated with the compute instance, and the first security secret is not accessible to programs running within the compute instance and not running within the instance secret management isolation runtime environment. A computer implementation method that includes, in response to a determination that a first security artifact is valid, obtaining access to a first resource by an application. The computer implementation method described in Clause 7, further comprising obtaining a request from a client via a programmatic interface 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. Clause 8. Obtaining a request from a client via a programmatic interface to assign a second authorization role to a compute instance, the second authorization role granting the compute instance permission to access the second resource, The computer implementation method described in Clause 7, further comprising providing a first secret manager to another application within a compute instance with another security artifact associated with a request from the other application to access a second resource, wherein the other security artifact is generated by the first secret manager using a second security secret associated with a second authorization role, and the second security secret is not accessible to programs running within the compute instance and not running within the instance secret management isolation runtime environment. Clause 9. A computer implementation method according to Clause 6 or 7, further comprising obtaining an indicator, through a programmatic interface, that a client has opted in to using the Instance Secrets Management Isolation Runtime Environment, and that the Instance Secrets Management Isolation Runtime Environment is launched at least in part based on the indicator. Clause 10. Obtaining, from the client, via a programmatic interface, an expiration criterion indicator for one or more security secrets managed by the First Secret Manager, including the First Security Secret, A computer implementation method as described in Clause 6, 7, or 9, further comprising obtaining a replacement security secret for the first secret in accordance with the expiration criteria by the first secret manager. Clause 11. The computer implementation method described in Clause 6, 7, 9, or 10, further comprising validating at least a portion of the installed software on the virtualization server before providing the first security secret to the first secret manager. The computer implementation method described in any one of Clauses 6, 7, or 9-11, further comprising obtaining the first security secret by the first secret manager during the boot procedure of the instance secret management isolation runtime environment, prior to the generation of a request to access the first resource. A computer implementation method as described in any one of Clauses 6, 7, or 9-11, further comprising obtaining the First Secret by the First Secret Manager in response to an indicator of a request for access to the First Resource. Clause 14. A computer implementation method described in any one of Clauses 6, 7, 9-11, or 13, further comprising using one or more shared memory buffers by a first secret manager to communicate with entities outside the instance secret management isolation runtime environment. Clause 15. Using a second subset of the memory allocated to the compute instance, launch the client-requested isolation runtime environment. A computer implementation method according to any one of Clauses 6, 7, 9-11, 13, or 14, further comprising using a second security secret by a second secret manager running in a client-requested isolation runtime environment to generate a second security artifact to be used by another application running within a compute instance, wherein the second security secret is obtained from a source indicated by the client and is not accessible by the first secret manager. Article 16. A non-temporary computer-accessible storage medium for storing program instructions, wherein when the program instructions are executed on a processor, The instance secrets management isolation runtime environment is started on the virtualization server of the virtualized computing service, the instance secrets management isolation runtime environment utilizes a subset of the memory allocated to the compute instances of the virtualization server, the subset of memory is inaccessible to programs running outside the instance secrets management isolation runtime environment, and the instance secrets management isolation runtime environment includes a secret manager. The secret manager provides security artifacts to applications within compute instances that are associated with requests from the applications to access resources, wherein the security artifacts are generated by the secret manager using security secrets associated with the compute instance, and the security secrets are not accessible to programs running within the compute instance and not within the instance secret management isolation runtime environment. A non-temporary computer-accessible storage medium that, in response to an application's determination that a security artifact is valid, obtains access to a resource. Clause 17. A non-transient computer-accessible storage medium as described in Clause 16, where the security secret is generated at least in part based on an authorization role assigned to the compute instance by the client on which the compute instance is launched, and the authorization role grants the compute instance permission to access the resource. Clause 18. A non-transient computer-accessible storage medium as described in Clause 16 or 17, in which the instance secrets management isolation runtime environment is launched after it has been determined that a client on which a compute instance is launched has opted in to the use of at least one instance secrets management isolation runtime environment. Clause 19. Store further program instructions, and when program instructions are executed below, A non-temporary computer-accessible storage medium as described in any one of Clauses 16-18, which causes the secret manager to obtain replacement security secrets in accordance with the expiration criteria for security secrets, where the expiration criteria are indicated by the client on which the compute instance is launched on behalf of the secret manager. Clause 20. A non-temporary computer-accessible storage medium as described in any one of Clauses 16 to 19, wherein the resource includes one or more data items stored in an object storage service, or (b) data items stored in a database service.

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

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

[0079] Various modifications and changes may be made, as will be apparent to those skilled in the art who are interested in this disclosure. The above description is intended to be illustrative and not restrictive, and is intended to encompass all such modifications and changes.

Claims

1. It is a system, Equipped with one or more computing devices, The one or more computing devices include an instruction, and when the instruction is executed on or across one or more computing devices, The process involves starting an instance secrets management isolation runtime environment on a virtualization server of a virtualized computing service, wherein the instance secrets management isolation runtime environment utilizes a subset of the memory allocated to the compute instances of the virtualization server, the subset of memory is inaccessible to programs running outside the instance secrets management isolation runtime environment, and the instance secrets management isolation runtime environment includes a secrets manager. The secret manager provides to an application within the compute instance a security artifact associated with a request from the application to access a resource, wherein the security artifact is generated by the secret manager using a security secret associated with the compute instance, and the security secret is not accessible to any program running within the compute instance and not within the instance secret management isolation runtime environment. A system that, in response to a determination that the security artifact is valid, obtains access to the resource through the aforementioned application.

2. One or more computing devices further include instructions, and when such instructions are executed on or across one or more computing devices, the one or more computing devices, To obtain an indicator of the expiration criteria for the security secret through a programmatic interface, The system according to claim 1, further comprising obtaining a replacement security secret in accordance with the expiration criteria.

3. The system according to claim 1 or 2, wherein the security secret is obtained by the secret manager after the validity of at least a portion of the software installed on the virtualization server has been verified.

4. A computer implementation method, The method involves starting an instance secret management isolation runtime environment on a virtualization server of a virtualized computing service, wherein the instance secret management isolation runtime environment utilizes a subset of memory allocated to the compute instances of the virtualization server, the subset of memory is 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. The first secret manager provides to an application within the compute instance a security artifact associated with a request from the application to access a first resource, wherein the security artifact is generated by the first secret manager using a first security secret associated with the compute instance, and the first security secret is not accessible to programs running within the compute instance and not running within the instance secret management isolation runtime environment. A computer implementation method comprising: obtaining access to the first resource in response to a determination by the application that the security artifact is valid.

5. The computer implementation method according to claim 4, further comprising obtaining a request to assign a first authorization role to the compute instance via a programmatic interface, wherein the 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 the first resource.

6. Obtaining a request to assign a second authorization role to the compute instance via the aforementioned programmatic interface, wherein the second authorization role grants the compute instance permission to access a second resource, The computer implementation method according to claim 5, further comprising providing the first secret manager with another security artifact associated with a request from the other application to access the second resource, wherein the other security artifact is generated by the first secret manager using a second security secret associated with the second authorization role, and the second security secret is not accessible to any program running within the compute instance and not within the instance secret management isolation runtime environment.

7. The computer implementation method according to claim 4 or 5, further comprising obtaining an indicator that a client on which the compute instance is launched has opted in to using the instance secret management isolation runtime environment, and the instance secret management isolation runtime environment is launched, at least in part, based on the indicator.

8. Obtaining an expiration criterion for one or more security secrets managed by the first secret manager, including the first security secret, The computer implementation method according to claim 4 or 5, further comprising obtaining a replacement security secret for the first security secret in accordance with the expiration criteria using the first secret manager.

9. The computer implementation method according to claim 4 or 5, further comprising obtaining the first security secret by the first secret manager during the boot procedure of the instance secret management isolation runtime environment, prior to the generation of the request to access the first resource.

10. The computer implementation method according to claim 4 or 5, further comprising obtaining the first security secret by the first secret manager in response to an indicator of the request for access to the first resource.

11. The computer implementation method according to claim 4 or 5, further comprising the first secret manager utilizing one or more shared memory buffers to communicate with entities outside the instance secret management isolation runtime environment.

12. Using a second subset of the memory allocated to the aforementioned computing instance, the client-requested isolation runtime environment is launched. A computer implementation method according to claim 4 or 5, further comprising using a second security secret by a second secret manager running in the client-requested isolation runtime environment to generate a second security artifact to be used by another application running in the compute instance, wherein the second security secret is obtained from a source indicated by a client on which the client-requested isolation runtime environment is invoked, and the second security secret is not accessible by the first secret manager.

13. A non-temporary computer-accessible storage medium for storing program instructions, wherein when the program instructions are executed on a processor, The process involves starting an instance secrets management isolation runtime environment on a virtualization server of a virtualized computing service, wherein the instance secrets management isolation runtime environment utilizes a subset of the memory allocated to the compute instances of the virtualization server, the subset of memory is inaccessible to programs running outside the instance secrets management isolation runtime environment, and the instance secrets management isolation runtime environment includes a secrets manager. The secret manager provides to an application within the compute instance a security artifact associated with a request from the application to access a resource, wherein the security artifact is generated by the secret manager using a security secret associated with the compute instance, and the security secret is not accessible to any program running within the compute instance and not within the instance secret management isolation runtime environment. A non-temporary computer-accessible storage medium that, in response to the application determining that the security artifact is valid, obtains access to the resource.

14. The non-temporary computer-accessible storage medium according to claim 13, wherein the instance secret management isolation runtime environment is started after it is determined that the client on which the compute instance is started has opted in to use at least one instance secret management isolation runtime environment.

15. The non-temporary computer-accessible storage medium according to claim 13 or 14, wherein the resource includes one or more of (a) data items stored in an object storage service, or (b) data items stored in a database service.

Images