Isolated runtime environment for protecting secrets for accessing remote resources from computing instances

Abstract

An instance secret management isolated runtime environment is launched at a virtualization server and utilizes a subset of memory allocated to compute instances. The subset of memories is not accessible from entities external to the runtime environment. A secret manager of the runtime environment provides a secure workpiece to an application running at the compute instance, the application having requested access to a resource. The workpiece is generated by the secret manager using a security secret associated with the compute instance; the secret is inaccessible to a program external to the runtime environment. In response to determining that the workpiece is valid, the application obtains access to the resource.

Description

Background Art

[0001] The advent of virtualization technology for commodity hardware has provided benefits in managing large-scale computing resources for many customers with different needs, thereby allowing multiple customers to efficiently and securely share various computing resources. For example, virtualization technology can allow a single physical computing machine to be shared among multiple users by providing each user with one or more virtual machines hosted by a single physical computing machine. Each such virtual machine can be viewed as a software simulation that acts as a different logical computing system that provides the user with the illusion that the user is the only operator and administrator of a given hardware computing resource, while also 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 at other services, and may need to protect requests to access remote resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 An example system environment is presented in accordance with at least some embodiments in which an automatically launched isolated runtime environment can be utilized to enhance the security of secrets used to access remote resources from a computing instance at a virtualized computing service of a cloud provider network.

[0003] Figure 2 An example remote request submission protocol that may be employed at a cloud provider network in accordance with at least some embodiments is presented.

[0004] Figure 3 Components of a virtualization server are presented according to at least some embodiments, wherein an instance secret management isolation runtime environment can be launched at the virtualization server.

[0005] Figure 4 Example interactions associated with obtaining instance secrets with a secret manager executing within an isolated runtime environment are shown in accordance with at least some embodiments.

[0006] Figure 5 Example interactions associated with transmission of an access request for which a signature is generated by a secret manager executing within an isolated runtime environment are shown in accordance with at least some embodiments.

[0007] Figure 6 Example scenarios are presented in which multiple authorization roles can be assigned to a single computing instance, with each authorization role having a corresponding associated instance secret, in accordance with at least some embodiments.

[0008] Figure 7 Example scenarios are presented in which multiple isolated runtime environments may be established within a computing instance in accordance with at least some embodiments.

[0009] Figure 8 Example programmatic interactions between a client and a virtualized computing service related to instance secret management are presented in accordance with at least some embodiments.

[0010] Fig. 9 is a flow diagram illustrating aspects of operations that may be performed to manage instance secrets using an isolated runtime environment in accordance with at least some embodiments.

[0011] Fig.10 is a block diagram illustrating an example computing device that may be used in at least some embodiments.

[0012] Although embodiments are described herein for several embodiments and illustrative drawings by way of example, those skilled in the art will recognize that embodiments are not limited to the described embodiments or drawings. It should be understood that the drawings and detailed descriptions thereof are not intended to limit the embodiments to the specific forms disclosed, but rather are intended to cover all modifications, equivalents and alternatives falling within the spirit and scope defined by the appended claims. The titles used herein are for organizational purposes only and are not intended to be used to limit the scope of this specification or claims. As used throughout this application, the word "may" is used in a permissive sense (i.e., meaning "possibly"), rather than a mandatory sense (i.e., meaning "must"). Similarly, the words "include, including and includes" are meant to include but are not limited to. When used in a claim, the term "or" is used as an inclusive rather than an exclusive or. For example, the phrase "at least one of x, y or z" means any one of x, y and z, and any combination thereof. Unless otherwise expressly stated, articles such as "a or an" should generally be interpreted as including one or more items described throughout this application. Thus, phrases such as "a device configured to..." are intended to include one or more of the enumerated devices. Such one or more of the enumerated devices may also be configured together to perform the stated enumeration. For example, "a processor configured to perform enumeration A, B, and C" may include a first processor configured to perform enumeration A working in conjunction with a second processor configured to perform enumeration B and C. Unless otherwise expressly stated, the term "set" should generally be interpreted as including one or more of the described items throughout this application. Thus, phrases such as "a collection of devices configured to..." are intended to include one or more of the enumerated devices. Such one or more of the enumerated devices may also be configured together to perform the stated enumeration. For example, "a collection of servers configured to perform enumeration A, B, and C" may include a first server configured to perform enumeration A working in conjunction with a second server configured to perform enumeration B and C. DETAILED DESCRIPTION

[0013] The present disclosure relates to methods and devices for reducing the probability of misuse of security secrets associated with computing instances of virtualized computing services using an isolated runtime environment. Typically, credentials / security secrets are accessible to all software and users of the instance that use the credentials to gain access to other resources, which may increase the probability of misuse of the credentials. Specifically, the present disclosure relates to a "credentialless" authentication protocol for computing instances, which refers to an authentication protocol through which the security secrets used by the instance to authenticate are never directly exposed to the instance itself. Security secrets, such as unique encryption keys assigned to computing instances, can be used to prepare requests to access remote resources within a cloud provider network (e.g., remote resources managed at a service other than the virtualized computing service) from the computing instance. In order to securely access remote resources (such as data items stored at a storage service of the provider network) from a program running at the computing instance, programmatic requests for remote resources (such as hypertext transfer protocol (HTTP) GET requests) are formatted and digitally signed according to protocols enforced by the provider network. For example, at the request of a virtualized computing service (VCS) client for which a computing instance is established, an authorization role is assigned to the computing instance so that a program running within the computing instance can access or utilize a remote resource or service indicated in the role. One or more security secrets generated for the computing instance based on the authorization role and referred to herein as "instance secrets" are used in the preparation process of programmatic requests transmitted to a service that manages remote resources.

[0014] In order to support various types of secure computing, including signing requests for remote resources using instance secrets, an isolated runtime environment with a verified software configuration can be established within a computing instance. Such an isolated runtime environment (IRE) can be referred to as a "software enclave". A computing instance associated with an IRE and that can utilize the IRE for secure computing is referred to as the "parent" computing instance of the IRE. The IRE can utilize a separate subset of the memory allocated to its parent computing instance; other programs running within the computing instance (i.e., programs not running within the IRE itself) cannot access the separate subset of memory. Programs within the IRE can only communicate with external entities through special local communication channels and communication intermediaries running at the computing instance, and are prohibited from accessing persistent storage devices or establishing network connections. The local communication channel can be used to obtain or provide security secrets of various applications at a trusted program running within the IRE, without exposing the secrets to less trusted programs of the computing instance not running within the IRE. Such secrets can later be used by trusted programs within the IRE to perform computing, such as at the request of a less trusted program.

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

[0016] An application running within a parent computing instance can send a representation of its access request to a remote resource to the secret manager. The secret manager can use the instance secret to generate a corresponding signature (or other similar security artifact) for the remote resource access request, and provide the signature or artifact to the application that is going to access the remote resource. The application can send the security artifact with the request to the service, where the requested resource is managed according to the remote access protocol of the provider network without the application accessing the instance secret. If the security artifact is determined to be valid, for example, if the authorization role assigned to the computing instance and associated with the instance secret allows or permits the computing instance to access the resource, the resource manager or request processor at the remote service can provide access to the resource. At the virtualization server running the parent computing instance, the instance secret cannot be saved or stored at a location outside the ISM-IRE; the instance secret cannot be transmitted to any other entity over the network. Therefore, the use of ISM-IRE can significantly reduce the probability of inadvertent or intentional damage or "leakage" of instance secrets.

[0017] As will be appreciated by those skilled in the art in light of the present disclosure, certain embodiments may be able to achieve a variety of advantages, including some or all of the following: (a) eliminating or at least significantly reducing the probability of inadvertent or intentional misuse of security secrets used to access remote resources from a computing instance implemented at a provider network, even if a malicious entity somehow gains access to the computing instance or runs a program at the computing instance, and / or (b) reducing the amount of computing and other resources that might otherwise have to be specifically detected and debugged for unauthorized access to resources at the provider network.

[0018] According to some embodiments, a system may include one or more control plane servers (CPS) of a virtualized computing service (VCS) of a cloud provider network, one or more virtualized servers or hosts of the VCS, and one or more resource managers of a collection of resources at another service of the provider network (such as a storage service or a database service). The CPS may cause an instance secret management isolation runtime environment (ISM-IRE) containing a secret manager (SM) to be automatically started within a computing instance running at a virtualized server. The ISM-IRE may be granted access to a subset of memory allocated to the computing instance. The ISM-IRE may be started without receiving a specific launch request to the ISM-IRE from a client of the VCS, for which a request to launch the computing instance may have been received at the VCS control plane. In various embodiments, the memory subset may not be accessible from a program running outside the ISM-IRE. Network communication from the ISM-IRE to endpoints outside the virtualized server may be prohibited. In some embodiments, for example, the ISM-IRE can be configured without external networking (networking outside the local host that started it), and can be configured only with a secure local channel for communicating with the parent instance, which can be a local socket, such as a VM socket (vsock). The ISM-IRE can also be configured without persistent storage, remote storage, or interactive access. Even the root user or administrator user on the parent instance cannot access or enter the ISM-IRE through SSH. In some embodiments, the ISM-IRE can be started as part of the initialization or boot program of the computing instance using, for example, a specific machine image of a virtualization management component (VMC) provided to the virtualization server from a control plane server. In other embodiments, the ISM-IRE can be started at a certain point after the computing instance is started.

[0019] In some embodiments, the SM (Secret Manager) may be configured to automatically determine or obtain (e.g., from a provider network's security service) a set of one or more instance secrets (e.g., encryption keys) associated with an authorized role assigned to a compute instance without receiving a request from a client to determine / obtain instance secrets. In at least one embodiment, instance secrets are not accessible to programs that (a) run within a compute instance and (b) do not run within the ISM-IRE itself.

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

[0021] In at least one embodiment, prior to using the ISM-IRE for a request generated at a compute instance, a VCS client that initiates the ISM-IRE at the request of a parent compute instance may submit a programming request to a VCS control plane indicating an authorization role to be assigned to the parent compute instance. In various embodiments, such role assignment requests may be submitted using any of a variety of programming interfaces of the VCS (e.g., a web-based console, a command line tool, a graphical user interface, an application programming interface (API), etc.). In one embodiment, an instance launch request that establishes a parent compute instance may include a role as a parameter. In various embodiments, a set of instance secrets may be associated with a role (or generated using a role).

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

[0023] According to one embodiment, the VCS may support multiple options for handling instance secrets. One of the options may involve establishing an ISM-IRE and a secret manager of the type described above; another option may, for example, involve obtaining instance secrets from a metadata service running at a virtualization server. In some embodiments, a VCS client that wishes to use the metadata service may notify the VCS control plane server accordingly through a programming interface. If a VCS client decides to use the metadata service for a specific computing instance or for all clients' computing instances, the ISM-IRE may not be set for these computing instances. In at least some embodiments, the VCS control plane may obtain an indication that the client has opted in (or not opted out) of the ISM-IRE option, and only after the client approves the use of the ISM-IRE, sets the corresponding ISM-IRE for the client's computing instance.

[0024] In some embodiments, to further enhance the security of instance secrets, the validity of a given instance secret may automatically expire after a period of time, and therefore the SM may have to obtain updated versions of the secret at any time. In one embodiment, the VCS client may provide an indication of the expiration criteria of one or more instance secrets managed by the SM through a programming interface. The expiration criteria may be specified as a time interval (e.g., equivalent to "the instance secret will expire T minutes after it is generated"), specified based on usage (e.g., "the instance secret will expire after it is used for N resource access requests"), specified as a combination of time and usage ("the instance secret will remain valid for a maximum of N resource access requests and will expire no later than T minutes after the secret is generated"), or using other factors. In various embodiments, after (or shortly before) the expiration of a given secret, the SM may obtain a replacement for the secret and continue using the replacement version.

[0025] In some embodiments, before generating an instance secret for a computing instance running at a virtualized server, the validity of the software (and / or hardware) state of at least a portion of the virtualized server at which the ISM-IRE is started can be verified. For example, a certification document indicating the state of the software (including virtualization management component software, ISM-IRE software including SM, etc.) can be provided to a security service of a provider network responsible for generating instance secrets, and before issuing the instance secret or providing the instance secret to the SM, the security service can ensure that the state information provided to it is acceptable or valid.

[0026] In some embodiments, at least some instance secrets may be obtained by the SM during a boot or startup procedure of the ISM-IRE (e.g., before any resource access request from an application running at a parent computing instance of the ISM-IRE). In other embodiments, the instance secrets may be obtained when they are first needed, e.g., in response to an indication obtained at the SM of a resource access request from an application running at a parent computing instance.

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

[0028] In at least one embodiment, multiple IREs (including at least one ISM-IRE) may be established for a given parent computing instance. For example, while the VCS control plane automatically causes the establishment of an ISM-IRE, a client that sets up a parent computing instance on its behalf may request the establishment of other IREs that may be used to perform security operations unrelated to the use of instance secrets. In such embodiments, each IRE (including such client-requested IREs) may contain its own secret manager, and the client-requested IREs may be restricted to using the same type of local communication channels as the channels used by the ISM-IRE. In some embodiments, 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 may be 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, rather than a client-requested IRE.

[0029] As indicated above, in various embodiments, the VCS may be implemented as part of a suite of services for a cloud provider network or cloud computing environment. A cloud provider network (sometimes referred to simply as a "cloud") refers to a network-accessible pool of computing resources (such as computing, storage, and networking resources, applications, and services) that may be virtualized or bare metal. A cloud may provide convenient, on-demand network access to a shared pool of configurable computing resources that may be programmatically provisioned and released in response to customer commands. These resources may be dynamically provisioned and reconfigured to accommodate variable loads. Cloud computing may therefore be viewed as both applications delivered as services over a publicly accessible network (e.g., the Internet or a cellular communications network) and the hardware and software in a cloud provider's data center that provides these services.

[0030] The cloud provider network can be formed into multiple zones, where the zone is a separate geographic area in which the cloud provider clusters data centers. Such zones can also be referred to as zones defined by the provider network, because their boundaries are not necessarily consistent with the boundaries of countries, states, etc. Each zone can include two or more availability zones connected to each other by a dedicated high-speed network (e.g., fiber optic communication connection). An availability zone (also referred to as an availability domain, or simply "zone") refers to an isolated failure domain, which includes one or more data center facilities, which have separate power, separate networking, and separate cooling separated from the facilities in another availability zone. A data center refers to a physical building or enclosure that houses and provides power and cooling for the servers of the cloud provider network. Preferably, the availability zones within a zone are far enough apart from each other that the same natural disaster should not simultaneously take more than one availability zone offline. Customers can connect to the availability zones of the cloud provider network through a transit center (TC) via a publicly accessible network (e.g., the Internet, a cellular communication network). The TC can be considered the primary backbone location that connects customers to the cloud provider network and can be collocated with other network provider facilities (e.g., Internet service providers, telecommunications providers) and securely connected (e.g., via a virtual private network (VPN) or direct connection) to availability zones. Two or more TCs can be operated per region for redundancy. The zones are connected to a global network that connects each zone to at least one other zone. The cloud provider network can deliver content from points of presence (points of presence or PoPs) outside of these zones but networked to these zones through edge locations and regional edge cache servers. This partitioning and geographic distribution of computing hardware enables the cloud provider network to provide customers with low-latency access to resources on a global scale with a high degree of fault tolerance and stability.

[0031] In some embodiments, the virtualization server can be located in the VCS zone, at the edge location of the VCS, or at the VCS extension location. The edge location (or "edge area") referred to herein can be constructed in several ways. In some embodiments, the edge location can be an extension of the cloud provider network foundation, including a limited amount of capacity provided outside the availability zone (for example, in a small data center or other facilities of a cloud provider located close to the customer workload and possibly away from any availability zone). Some edge locations can be referred to as local areas (due to being more localized or closer to a group of users than traditional availability zones). The local area can be connected to a public accessible network such as the Internet in various ways (for example, directly, through another network, or through a dedicated connection to a zone). Although local areas usually have more limited capacity than zones, in some cases, local areas may have considerable capacity, such as thousands of racks or more. Some local areas can use infrastructure similar to typical cloud provider data centers. The extended location of VCS can include a part of the resident owned by the client, wherein one or more data plane servers that can start VCS computing instances are located at the part. In various embodiments, a special highly secure channel using various tunneling techniques can be established to transmit commands (e.g., commands to launch compute instances and / or containers) from the control plane servers of the VCS (which are maintained at the provider network data center) to the extended location data plane servers.

[0032] The cloud provider network may implement a variety of computing resources or services, which, in addition to the VCS, may include data processing services (e.g., map reduce, data streaming, 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 any other types of network-based services (which may include various other types of storage, processing, analysis, communication, event processing, visualization, and security services). The resources required to support the operation of such services (e.g., computing and storage resources) may be provisioned in an account associated with the cloud provider, as distinct from resources requested by users of the cloud provider network, which may be provisioned in a user account.

[0033] In various embodiments, various network-accessible services may be implemented at one or more data centers, edge locations, and / or extended locations of a provider network. Network-accessible computing services may include elastic computing cloud services or VCS (referred to as elastic computing services, virtual machine services, computing cloud services, computing engines, or cloud computing services in various embodiments). Such services may provide computing instances (also referred to as client virtual machines, or simply "instances") with different computing and / or memory resources, which are managed by computing virtualization services (referred to as elastic computing services, virtual machine services, computing cloud services, computing engines, or cloud computing services in various embodiments). In one embodiment, each of the virtual computing instances may correspond to one of several instance types or series. 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 suitable descriptive characteristics (e.g., a "bursting" instance type that has a baseline performance guarantee and can periodically burst above the baseline, or a non-bursting or dedicated instance type that allocates and guarantees a fixed number of resources). In some embodiments, one or more of the instance types may support the automatic establishment of an ISM-IRE of the type described above. Each instance type may have a specific ratio of processing, local storage, memory, and networking resources, and different instance families may also 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 function, an instance type may be selected for a customer, for example, based (at least in part) on input from the customer. For example, a customer may select an instance type from a predefined set of instance types. As another example, a customer may specify the resources desired by an instance type and / or the requirements of a workload that the instance will run, and the instance type selection function may select an instance type based on such specification. A host suitable for the requested instance type may be selected based at least in part on factors such as collected network performance metrics, resource utilization levels at different available hosts, etc. In some embodiments, instances of several different instance types may be started at an extended location in response to a programmatic request from a client. In some embodiments, other types of network accessible services such as packet processing services, database services, wide area network (WAN) services, etc. may also be implemented at the cloud provider network.

[0034] In various embodiments, traffic and operations of a cloud provider network (or individual services of a cloud provider network, including VCS) can be broadly broken down into two categories: control plane operations carried on a logical control plane and data plane operations carried on 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 typically includes one or more control plane components distributed across and implemented by one or more control servers. Control plane traffic typically includes management operations such as system configuration and management (e.g., resource placement, hardware capacity management, diagnostic monitoring, or system status information). The data plane includes customer resources (e.g., compute instances, containers, block storage volumes, databases, or file storage devices) implemented on the cloud provider network. Data plane traffic typically includes non-management operations such as transferring customer data into and out of customer resources. Certain control plane components (e.g., first-tier control plane components, such as a control plane for virtualized compute services) are typically implemented on a set of servers separate from the data plane servers, while other control plane components (e.g., second-tier 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 sent over separate / different networks.

[0035] Figure 1 An example system environment according to at least some embodiments is shown, in which an automatically launched isolated runtime environment can be utilized to enhance the security of secrets for accessing remote resources from a computing instance at a virtualized computing service of a cloud provider network. As shown, the system 100 includes resources and artifacts of several network-accessible services of a cloud provider network 102, including a virtualized computing service (VCS) 110, a security secret service 160, an identity and role management service (IRMS), and a storage service 164. The VCS control plane 112 can include multiple control plane servers, including, for example, an instance state change manager 114, a configuration manager 116, an instance secret handling coordinator 118, a client request processor 119, etc. The VCS can include a virtualization server cluster 130 including virtualization servers (VS) 132A and 132B, where various types of computing instances or virtual machines can be launched in response to programmatic requests from VCS clients. A given virtualization server 132 can include a virtualization manager component (VMC) 137 (such as a hypervisor) and zero or more computing instances at a given point in time. For example, VS 132A includes VMC 137A and compute instances (CIs) 134A and 134B, while VS 132B includes VMC 137B and CIs 134K and 134L.

[0036] Some of the computing instances may include applications that need to access resources at other services of the provider network, such as data items 166 of storage service 164. In the depicted embodiment, to help ensure that only authorized entities can access data items 166, a protocol for submitting resource access requests from computing instances 134 may be adopted and enforced at provider network 102. Figure 2 An example of such a protocol is described in the context of . As part of such a protocol, a security artifact (such as a digital signature representing at least a portion of a formatted string of a resource access request) may be generated using an instance secret assigned to a computing instance that initiates the computing instance. In at least some embodiments, SSS160 may be responsible for generating the instance secret. In the depicted embodiment, the security artifact may be transmitted along with the resource access request to the resource manager 167 responsible for the data item being accessed, and the resource manager may provide access to the data item only after the security artifact has been verified to be valid. A given computing instance 134 may be assigned one or more authorization roles (also referred to as access management roles) at the request of a VCS client on whose behalf the computing instance is launched. In various embodiments, a given role may include rules indicating the types (or specific lists) of remote resources that may be accessed from the computing instance, and the instance secret may be generated based at least in part on the role. In the depicted embodiment, information about the role may be stored at IRMS162.

[0037] exist Figure 1In the depicted embodiment, one or more control plane servers (such as instance secret handling coordinator 118 and / or instance state change manager 114) can cause a corresponding instance secret management isolation runtime environment (ISM-IRE) to be automatically launched within at least some computing instances (e.g., using a separate portion of its memory). For example, CI 134A includes ISM-IRE 136A, CI 134B includes ISM-IRE 136B, and CI 134K includes ISM-IRE 136K. In the depicted embodiment, some CIs such as CI 134L may not include an ISM-IRE. In at least some embodiments, although the CI itself can be launched in response to a programmatic request of a VCS client, the ISM-IRE can be launched without receiving a specific client request to do so. In various embodiments, communications to / from the ISM-IRES may be strictly restricted, for example, network communications may not be allowed, input / output to persistent storage devices may be prohibited, etc. A local communication channel may be established for messages originating from or directed to the ISM-IRE, for example, using a shared memory buffer. Each ISM-IRE may include a corresponding secret manager implemented, for example, using one or more processes or threads. In some embodiments, in response to an indication that the client has opted in to use the ISM-IRE, the VCS control plane may initiate the ISM-IRE only at the client's CI. In other embodiments, using the ISM-IRE may be a default option provided to the VCS client, and an ISM-IRE may be automatically created for each CI unless the client chooses not to use the default option.

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

[0039] In some embodiments, a given CI may be assigned multiple authorization roles (each authorization role may enable an application to access a different set of resources), a corresponding set of instance secrets corresponding to each role may be generated, and each set of instance secrets may be used in the manner described above to implement resource access according to the corresponding role. In some embodiments, in addition to the automatic or system-initiated ISM-IRE, other IREs may be initiated at the parent CI at the explicit request of the VCS client and used for other secure computations or operations that do not necessarily require instance secrets. In one embodiment, the VCS client may provide input to the VCS control plane regarding the expiration criteria of the instance secrets of one or more CIs in its CIs, forcing the SM to refresh or replace the instance secrets based on the expiration criteria. According to some embodiments, before providing the instance secrets to the SM running at the ISM-IRE of the virtualization server, the status of at least some of the installed software of the virtualization server may be verified, for example, using a certification document prepared by the VMC. In one embodiment, at least some of the instance secrets may be obtained by the SM at the time (or shortly thereafter) when the parent CI and ISM-IRE are initiated; in other embodiments, some or all instance secrets may be obtained only in response to detecting that an application running at the parent CI has generated a request to access a remote resource.

[0040] The VCS 110 may implement one or more programming interfaces 177, including, for example, one or more web-based consoles, a set of application programming interfaces (APIs), command line tools, graphical user interfaces, etc. Such interfaces may be utilized by VCS clients to request various types of configuration operations to various VCS client devices 150 (e.g., desktop computers, laptop computers, mobile computing devices, etc.) and receive corresponding responses, etc. For example, a client may submit a programmatic request to launch or instantiate a compute instance (CI) 134, opt-in to use or opt-out of using ISM-IRE, submit preferences regarding expiration criteria for instance secrets, etc. In various embodiments, each of the compute instances 134 may include a respective virtual machine and / or other type of program execution platform (e.g., a bare metal instance, where direct control is granted to more hardware devices than is granted to a client virtual machine).

[0041] In some embodiments, at least some client requests may be directed to the VCS control plane 112. In the depicted embodiment, control plane servers such as the instance state change manager 114, the configuration manager 116, the instance secret handling coordinator 118, and the client request processor 119 may be implemented at one or more computing devices using some combination of hardware and software, respectively. Client requests for computing instances may be processed, for example, initially at the request processor 119. The request processor may perform some initial checks (e.g., verify that the client has permission for the requested type of operation), and then pass the internal version of the request to one or more other components of the control plane for implementation. In the depicted embodiment, the instance state change manager may be responsible for, for example, starting, terminating, and migrating computing instances implemented on virtualized servers in the virtualized server cluster 130 of the VCS. For example, in the depicted embodiment, the configuration manager 116 may be responsible for, for example, identifying a specific virtualized server where one or more requested computing instances will be started.

[0042] A virtualization manager component (VMC) 137 (which may include a hypervisor) at the virtualization server may act as an intermediary between the compute instance 134 and at least some of the hardware elements of the VS, including, for example, physical processors (e.g., central processing unit (CPU), graphics processing unit (GPU), etc.), memory, persistent storage, network cards, peripherals, etc. In some embodiments, at least a portion of the virtualization management responsibilities may be offloaded from the main processor or CPU to a hardware card (e.g., a card connected to the CPU of the VS via a peripheral connection interface or PCI Express interconnect, and referred to as an offload card) to free up more computing power of the main processor of the compute instance for use.

[0043] In the depicted embodiment, after a client sends a request to the VCS control plane to launch a compute instance, a corresponding internal command to launch the instance may be transmitted to a virtualization manager component (e.g., a hypervisor or an offloaded virtualization management component) running at the selected virtualization server. A collection of resources, including memory segments of the virtualization server, 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 launch the ISM-IRE, for example, as part of an internal command to cause the CI itself to be launched. In other embodiments, a separate request and / or command may be transmitted to the virtualization server to launch the ISM-IRE, for example after the compute instance 134 has been set up. In some embodiments, at least a portion of the memory allocated to the compute instance may be separated or set aside by the VMC 137 for the ISM-IRE 136. In at least some embodiments, as Figure 1 As indicated, the resources of a given virtualization server 132 (such as 132A and 132B) can be used for multiple computing instances, some of which can be set up in the name of different VCS clients. Other virtualization servers may include one or more computing instances set up in the name of a single client. In some scenarios (e.g., including an ISM-IRE and one or more client-requested IREs), the corresponding subset of resources allocated to a given computing instance can be separated or divided into multiple IREs. In at least some embodiments, the life cycle of a client-requested IRE and its parent computing instance (or other client-requested IREs at the same computing instance) may be different. For example, it may happen that a client-requested IRE terminates before its parent CI, or a client-requested IRE terminates before another client-requested IRE with the same parent CI. In some embodiments, the ISM-IRE may terminate only when its parent CI terminates. In at least some embodiments, resources of the parent computing instance separated or set aside for the IRE may be inaccessible to programs or processes running at the parent computing instance - for example, if 4 gigabytes of a total of 32 gigabytes of memory initially allocated to the CI are set aside for the ISM-IRE, programs / processes within the CI may only be able to access and use the remaining 28 gigabytes.

[0044] In various embodiments, as mentioned above, when configuring or instantiating an IRE, a number of constraints may be enforced to limit the manner in which programs or processes within the IRE may communicate or interact with other entities (e.g., processes / programs running in or outside a parent computing instance). In at least one embodiment, for example, an IRE process / program may be prohibited from communicating with any entity outside the IRE over a wired network (e.g., by not configuring a virtual or physical network interface that can access the IRE). Similarly, in various embodiments, the IRE may be configured such that access to a persistent storage device and / or a file system is prohibited—that is, a process / program within the IRE may not be able to read or write to a persistent storage device. In some embodiments, one or more communication intermediary processes (CIPs) or daemons may be instantiated in a parent computing instance of the IRE, and the one or more CIPs or daemons are allowed to communicate with the IRE on behalf of other processes / programs inside or outside the parent computing instance using a local communication channel. For example, in some embodiments, one or more buffers mapped to a shared memory of both the CIP and the IRE may be used for such communications. 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—e.g., a notification may be generated by the CIP when a message is ready for the IRE, and similar notifications may be used to indicate when the IRE has finished reading a buffer, when the IRE has an outbound message ready in a buffer, when the CIP has finished transmitting the outbound message, etc. In some embodiments, such a communication mechanism may be referred to as a "doorbell" mechanism.

[0045] In at least some embodiments, the VMC (e.g., a hypervisor) of VS 132 may include a security manager responsible for verifying or measuring the software configuration of IRE 136 and / or other software components of the VS (including at least some portions of the VMC itself). In various embodiments, the security manager may perform measurements and / or certifications of the software stack and other software components of the IRE, and the results of such configuration verification or analysis operations may be provided to one or more destinations (e.g., to SSS 160). In at least one embodiment, one or more hash functions may be applied by the security manager to the installed software, and the results of the hash functions may be compared to hash results of acceptable configurations for the client. In at least some embodiments, evidence that the security manager itself can be trusted (e.g., a digital certificate identifying the security manager) may also be provided, as well as a unique identifier for the IRE and / or its parent computing instance.

[0046] In embodiments where the SSS 160 generates an instance secret, a mechanism may be employed that does not allow any party other than the SSS and the ISM-IRE itself to intercept or access an unencrypted version of the instance secret. In some embodiments, for example, a logical equivalent of a TLS (Transport Layer Security) session may be set up between the SSS and the IRE, and the instance secret may be encrypted using a shared secret key determined / generated by both the ISM-IRE and the SSS during the session. In various embodiments, it should be noted that even though an encrypted version of the secret may be passed through a communication intermediary process (CIP) on the way from the client to the ISM-IRE, the CIP may not have the shared secret key required to decrypt the secret. In at least some embodiments, a decrypted version of the secret may be generated within the IRE using the shared secret key.

[0047] Figure 2 An example remote request submission protocol that can be employed at a cloud provider network according to at least some embodiments is presented. In the depicted scenario, in an application similar to Figure 1 Application 236 running at compute instance (CI) 234 of VCS client Client1 of VCS 110 needs to access data item 266 at storage service 264. Storage service may, for example, implement a web service interface that can be used to request access via HTTP or similar protocols.

[0048] In the depicted embodiment, implementing a remote request submission protocol for a cloud provider network of VCS and storage services may involve several steps. Figure 2 In step A), a canonical or standardized request for a data item may be created, such as an appropriately 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 by a URI (Uniform Resource Identifier), a query string, various HTTP headers, etc.) may have to be arranged in a specific order and separated by specified delimiters (such as newline markers) to separate the corresponding elements of the request. In step B, a string to be signed may be created from the canonical request. The string may include, for example, an identifier of a hashing algorithm used to generate a digest of the canonical request, a representation of the data and time at which the request was generated, a representation of the scope of the credentials associated with the request (e.g., a zone of a provider network, an s name of a target service, etc.), and a hashed representation of the canonical request itself.

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

[0050] In step D, the signature and request may be sent to the target storage service 264 where the data item resides. In at least some embodiments, in step E, if the signature is valid and accepted, access to the data item may be provided to the requesting application; if the signature is invalid, access may be denied.

[0051] In some embodiments, protocol 277 may not necessarily have any strict requirements on the way or approach of entity / program calculation signature, or the way / location of storing secret key. For example, steps A, B and C can be executed in a software development kit (SDK) provided by the provider network operator and used by the application to access external data, executed in a command line tool or other tools provided by the provider network operator or executed in a program code developed by the client. If the client does not want to utilize the ISM-IRE-based technology described above, the secret key can be stored in plain text on CI, hard-coded into the application 236, read from a file by the application or processed in any other way selected by the client. However, in various embodiments, by utilizing ISM-IRE, the security of the secret key can be significantly enhanced, which can ensure that the secret key cannot be accessed by any program running outside the ISM-IRE, including the application 236 itself.

[0052] Figure 3Components of a virtualization server are shown according to at least some embodiments, where an instance secret management isolation runtime environment can be launched at the virtualization server. In the depicted embodiment, a computing instance 344 can be launched at a virtualization server 332 of the VCS, for example, in response to a request submitted by a VCS client. In various embodiments, an ISM-IRE 346 can be automatically set up with the computing instance 344 as a parent computing instance using some of the resources previously allocated to the computing instance 344. In at least some embodiments, a virtualization management component 334 of the virtualization server 332 may include an IRE resource separation manager (IRERSM) 338, which is responsible for identifying resources to be configured for exclusive use by the ISM-IRE (via a thread or process launched within the ISM-IRE). For example, the IRE S M 338 may select or identify a memory subset 378 for exclusive use by the ISM-IRE from the memory segments 377 of the virtualized server originally allocated to the parent computing instance 344; when additional client-requested IREs or system-requested IREs are set up within the same parent CI, the IRE S M 338 may set aside corresponding additional subsets specifically for such IREs. In such embodiments, after the separated memory has been configured for use by the ISM-IRE, the separated memory may be inaccessible to processes / programs running within the parent CI. In some embodiments, subsets of other resources (such as virtual CPUs that may have been designated for use by the parent computing instance 344) may also be designated for exclusive use by the ISM-IRE.

[0053] In various embodiments, a communication broker process (CIP) 348 may be instantiated within a compute instance 344. In some embodiments, an operating system daemon may be used as a CIP. In one embodiment, such a CIP daemon may be established as part of the process of establishing an ISM-IRE 346; in other embodiments, the CIP daemon may be started as part of the initialization or boot sequence of a parent compute instance 344, or in response to an API call after the compute instance is booted. In various embodiments, CIP 348 may be configured to communicate data from any other entity that wishes to communicate with the ISM-IRE (e.g., including external sources of instance secrets 355, such as those similar to Figure 1In some embodiments, the ISM-IRE 346 may be configured to transmit data to the ISM-IRE 346 through the security secret service of the SSS 160 of the virtualization server, and transmit outbound data from the ISM-IRE 346 to one or more destinations. In at least some embodiments, as part of the configuration steps to ensure that the ISM-IRE is isolated from any external entity (e.g., other than the VMC 334), the processes / programs of the ISM-IRE 346 may not be allowed to transmit data to any entity or endpoint through a network connection using the network interface card of the virtualization server; in such embodiments, all communications to / from the ISM-IRE may have to pass through the CIP. In some embodiments, similarly, the configuration settings of the ISM-IRE 346 may also prohibit the interaction between the IRE and the persistent storage device, and in such embodiments, the interaction between the ISM-IRE 346 and the file system - that is, the processes / programs of the ISM-IRE may not be allowed to read from and write to the persistent storage device. In at least some embodiments, a local communication channel 349 may be set up for data transmission between the CIP and the ISM-IRE. In one embodiment, for example, a portion of a shared memory accessible to both the CIP and the ISM-IRE may be designated or mapped to store data that is transferred to / from the ISM-IRE. In some embodiments, a bidirectional notification or interrupt-based mechanism may be used to indicate when data is ready to be read by the ISM-IRE (for data inbound to the ISM-IRE) or by the CIP (for data outbound from the ISM-IRE). In the depicted embodiment, the compute instance 344 may include various other processes / programs, such as an application component 356 and / or an operating system component of the compute instance, which may be less trusted (from the perspective of the VCS control plane and / or VCS client) than the ISM-IRE for performing computations using secure secrets.

[0054] In at least some embodiments, a configuration check operation may be performed on the ISM-IRE at one or more points in time during the life cycle of the ISM-IRE. Figure 1348) transmits a configuration verification query to the CIP 348, which in turn may pass the query to the ISM-IRE. The IRE security manager (IRESM) 336 may determine, for example, based on an indication provided by the CIP 348 or the ISM-IRE 346 that the query has been directed to the ISM-IRE 346. The IRESM 336 may then perform a configuration verification / analysis operation on the software stack of the ISM-IRE 346, as indicated by arrow 392. In some embodiments, for example, one or more hash functions may be applied to various layers of the software of the ISM-IRE 346, and the output hash value may represent a signature of the software stack. In at least some embodiments, the IRESM 336 may perform an attestation of the IRE software stack. In the depicted embodiment, the results of the configuration measurement / verification test employed by the IRESM 336 may be provided to the verification requester. In such scenarios, the result can be passed from IRESM to ISM-IRE, from ISM-IRE to CIP, and finally to the verification requester. In other embodiments, a path different from the path used for the query can be used for the verification result. In at least some embodiments, in addition to the proof / verification result and the random number, (a) an indication of the identity of IRESM can be provided to the verification requester, similar to a TLS certificate rooted in a trusted certificate authority and (b) an indication of the identity of ISM-IRE and / or its parent computing instance (e.g., one or more public keys containing a corresponding asymmetric key pair). Then, the verification requester can verify that the proof result and identity information are acceptable, and if so, the ISM-IRE can be designated as trusted and verified for calculations involving the use of instance secrets. In some embodiments, the hash value-based verification of the ISM-IRE software state can be performed at the VMC 334. It should be noted that in an embodiment where a client-requested IRES is established at a computing instance, a similar state verification program can be initiated by the client at various stages of the life cycle of the client-requested IRE.

[0055] In the depicted embodiment, as part of operation 391, one or more instance secrets 387 may be transferred from an external source 355 (such as a secure secret service) to the ISM-IRE, for example, at the request of a secret manager 388 within the ISM-IRE. In various embodiments, to do so, a secure communication session or channel similar to a TLS session may be established between the external source 355 and the ISM-IRE. Within the computing instance 344, the 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 may be securely transferred to the ISM-IRE 346, the encrypted version of which cannot be decrypted by the CIP even if the CIP passes messages of the session to / from the ISM-IRE. The secret manager 388 of the IRE 346 may then begin performing computations using the instance secrets, such as generating a signature for a request from a less trusted application component 356 to access a remote resource. In some embodiments, a secret provisioning agent 357 (such as a privileged operating system thread of a computing instance) may prompt the secret manager to obtain the instance secret 387.

[0056] Figure 4 An example interaction associated with obtaining instance secrets by a secret manager running within an isolated runtime environment is shown according to at least some embodiments. In the depicted embodiment, a parent computing instance of an ISM-IRE may include a secret provisioning agent 401, which is implemented, for example, as a privileged operating system process or thread that a VCS client cannot directly control. In the depicted embodiment, the secret provisioning agent 401 may send an AcquireSecret request 450 to an ISM-IRE secret manager 404. In different embodiments, the timing of the AcquireSecret message relative to the ISM-IRE boot time may be different—for example, in some embodiments, the AcquireSecret message may be sent shortly after or during ISM-IRE boot or startup, while in other embodiments, the AcquireSecret message may be sent later, for example, in response to the secret provisioning agent determining that a remote access request has been generated by an application 413 or is about to be generated by an application 413 being launched. In some embodiments, the secret provisioning agent is therefore not necessarily implemented as part of the operating system; instead, for example, some user mode program or application 413 itself may request the ISM-IRE secret manager to obtain a secret. In at least one embodiment, the AcquireSecret request may indicate the authorized role for which the secret is to be acquired. Figure 4 Prior to the steps shown, the owner of the parent compute instance (the VCS client at whose request the parent compute instance was launched) can use a programming interface to create and assign roles, and notify the SSS that the role has been assigned to the parent compute instance.

[0057] In response to receiving the AcquireSecret request, the ISM-IRE secret manager 404 may send a GetNonce request 451 to a secure secret service (SSS) 407 of the provider network, for example using a secure communication path involving use of CIP and a local communication channel. A random number (e.g., a pseudo-random number) may be used to Figure 4 The various messages of the secret acquisition procedure shown are linked together; for example, the sender of an operation request can include a random number in the request, and the response is trusted only if it contains the same random number. Such random numbers can be used in encryption systems to prevent copies of requests (such as those submitted by malicious programs or entities that try to access the content of the request) from being successful. In some embodiments, the identifier of the parent computing instance and the role assigned to the parent computing instance can be provided as part of the GetNonce request and used in the calculation for generating a random number at the STS. In one embodiment, the VCS can maintain an instance profile for each computing instance indicating various characteristics of the computing instance (including the role assigned to the computing instance), and the profile can be included in the GetNonce request and utilized to generate a random number. As indicated by arrow 452, the random number can be provided by the STS to the ISM-IRE.

[0058] According to at least some embodiments, as previously indicated, before the SSS generates instance secrets for the secret manager, the software state of the virtualized server can be verified. Figure 4In the depicted embodiment, the secret manager 404 can request a certification document or certification object indicating the software state from the virtualization management component (VMC) (e.g., hypervisor) 410 of the virtualization server, which is performed by sending a GetAttestation request 453 to the VMC. In some embodiments, the parameters of the GetAttestation request 453 can include a random number (which can help to confirm to the VMC that the request comes from a legitimate ISM-IRE). In an embodiment in which the virtualization server includes a physical trusted platform module (TPM) or a virtualized TPM, the content of the TPM indicating the measurement of the software state of the virtualization server can be included in the GetAttestation request. In other embodiments, the data obtained from the TPM may not be used for certification. In some embodiments, the software of the ISM-IRE can be certified without certifying the rest of the software stack of the virtualization server. In other embodiments, the software of the ISM-IRE, the parent computing instance and / or the VMC itself can be certified. In the depicted embodiment, the VMC can generate a certification document 454 and provide a digitally signed version of the certification document / object to the secret manager. The certification document or object may actually indicate that the VMC has verified that the ISM-IRE is legitimate (ie, the status of the software for the ISM-IRE has been verified).

[0059] In the depicted embodiment, the secret manager may include a signed attestation document or object in a GetSecret request 455 sent to the SSS 407. In some embodiments, the parameters of the GetSecret request may indicate or include the role for which the secret is to be generated. For example, in one embodiment, the GetSecret request may indicate an identifier of the computing instance, and the VCS client may have informed the SSS in advance about one or more roles assigned to the computing instance. In the depicted embodiment, if the attestation information is satisfactory or successfully verified, the SSS may check the attestation document and generate an instance secret 456. The instance secret may then be sent back to the secret manager 404, for example, along with other security data generated by the SSS, such as a session token and key identifier that is also used in the process of signing the request of the remote application. In some embodiments, the secret manager may then provide a response to the AcquireSecret request 450 of the secret provisioning agent. A token referred to as an instance secret identifier or InstanceSecretID 457 may be sent to the secret provisioning agent, which in effect indicates 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 413 that initiates a request to access a remote resource. It should be noted that the secret manager may not expose the InstanceSecret itself to the secret provisioning agent; rather, the InstanceSecretID may serve as a pointer or reference to the InstanceSecret (and in some embodiments to other secure data such as a session token and / or key identifier) ​​that may be exposed to the secret provisioning agent (and from the agent to the application 413).

[0060] Figure 5 Example interactions associated with transmission of an access request for which a signature is generated by a secret manager executing within an isolated runtime environment are shown in accordance with at least some embodiments. Figure 4After obtaining the instance secret at the secret manager, the application 413 can send a request to the secret manager 404 for additional security data for use in preparing the pre-signed portion of the remote request. Such a request can include a GetAdditionalSecurityData request 551, whose parameters can include the InstanceSecretID previously provided to the application by the secret manager through the secret provisioning agent. The response AdditionalSecurityData 552 message can include, for example, an account key identifier of the client on whose behalf the parent computing instance was established, a session token that can be used to control the expiration of requests and / or instance secrets, and the like. In at least some embodiments, the additional security data need not be protected to the same degree as the instance secret; however, the secret manager 404 can still be used to provide the additional security data to the application.

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

[0062] Figure 6 An example scenario is presented in which multiple authorization roles may be assigned to a single computing instance, wherein each authorization role has a corresponding associated instance secret, in accordance with at least some embodiments. Figure 6 In the example scene depicted, something like Figure 1 The compute instance 634 of the VCS of the VCS 110 contains the application 636 and the application 637. The ISM-IRE 680 containing the secret manager 682 has been started using a subset of the memory of the compute instance 634.

[0063] Application 636 requires access to remote external resource 652, while application 637 requires access to remote external resource 653. In some cases, external resource 652 may be part of or managed by a network-accessible service of a provider network that is different from external resource 653; in other cases, both sets of external resources may be part of the same service. In some cases, one or both sets of external resources may not be located in a data center of the provider network; for example, one set of external resources may be located at the premises of a client of the provider network.

[0064] In the depicted embodiment, for example, to prevent application 636 from accessing external resource 653, and / or to prevent application 637 from accessing external resource 652, a client that launches computing instance 634 on its behalf can create and assign two different authorization roles to the computing instance, for example, using a programming interface implemented by VCS. Role 644A can enable access to external resource 652 (and not enable access to external resource 653), while role 644B can enable access to external resource 653 (and not enable access to external resource 652). Secret manager 682 can obtain and manage different instance secrets 662A and 662B corresponding to role 644A and role 644B, respectively. In the depicted example scenario, a request to access external resource 652 from application 636 can be signed by secret manager using instance secret 662A, while a request to access external resource 653 from application 637 can be signed by secret manager using instance secret 662B. In various embodiments, any number of roles may be assigned to a computing instance associated with an ISM-IRE, and secrets corresponding to each of the roles may be managed on a single ISM-IRE.

[0065] In some embodiments, as previously mentioned, a VCS client may wish to launch its own IRE and use the IRE to manage secrets in addition to instance secrets assigned to compute instances. Figure 7 An example scenario is shown in which multiple isolated runtime environments can be established within a compute instance according to at least some embodiments. In the depicted scenario, a compute instance (CI) 734 has been launched at a VCS virtualization server in response to an instance launch request from a VCS client C1. An ISM-IRE 740 has been automatically launched by the VCS within the compute instance 734, and a separate memory subset 778 of the total memory 777 originally allocated to the parent compute instance 734 has been set aside for use by the ISM-IRE 740. A secret manager running within the ISM-IRE 740 utilizes the instance secrets assigned to the CI 734 for remote resource access in accordance with a cloud provider agreement, enabling an application 736 to access remote resources in accordance with an authorized role assigned to the CI 734.

[0066] In the depicted embodiment, client C1 may also wish to use the isolated runtime environment to perform other security-related computations. In the depicted embodiment, since the ISM-IRE is set up by the VCS specifically for managing instance secrets, client C1 may not be provided access to the ISM-IRE. Instead, client C1 may submit a programmatic request to the VCS control plane to establish a second IRE (in Figure 7 In the depicted embodiment, a second separate memory subset 779 may be used for the client-requested IRE 744, and a second secret manager may be run within the client-requested IRE 744. Figure 3 The local communication channel of channel 349 shown in FIG. 1 provides secure secrets to the secret manager from a source indicated by client C1 (e.g., for use on behalf of application 737). In some embodiments, the ISM-IRE and the client-requested IRE may share the same communication broker process (similar to Figure 3 CIP 348); in other embodiments, a separate CIP may be used. The client-requested IRE may share many of the features and characteristics previously discussed for the ISM-IRE (e.g., restrictions on network and persistent storage I / O). Differences between the client-requested and ISM-IRE may include: (a) the VCS control plane may cause the ISM-IRE to start without receiving a request from the client, while the client-requested IRE may only start upon client request, (b) the source of security secrets used may be different, and (c) the client-requested IRE may terminate upon client request, while the ISM-IRE may not terminate. In some embodiments, multiple client-requested IREs may be established if desired. In one embodiment, multiple ISM-IREs may be started at a single computing instance to which multiple roles are assigned, with each ISM-IRE used to manage and use a corresponding instance secret corresponding to one of the multiple roles.

[0067] Figure 8 Example programming interactions between a client and a virtualized computing service related to instance secret management according to at least some embodiments are shown. In the depicted embodiment, the features and functions of the client are similar to Figure 1The VCS 812 of the VCS 110 may implement a collection of programming interfaces 877, such as a web-based console, a command line tool, an application programming interface (API), a graphical user interface, etc. The VCS client 810 may submit an OptInForISM-IREs message 814 through the programming interface, indicating that the client wishes to automatically set up ISM-IRE according to the needs of the client's computing instance. In the depicted embodiment, a record indicating that the client has opted in to use the instance secret protection technology using ISM-IRE may be stored at the VCS control plane, for example, with the client account metadata, and an OptInInfoSaved message 815 may be sent to the client. In some embodiments, the VCS may inform the client that the ISM-IRE feature is enabled by default for at least some categories of computing instances, rather than requiring the VCS client to explicitly opt in, and if desired, the client may programmatically opt out of using ISM-IRE. In some embodiments, the VCS may provide information about the amount of computing instance memory that can be set aside for ISM-IRE, for example, through a website, so that the client is aware that ISM-IRE will consume some computing instance memory.

[0068] In the depicted embodiment, a client may submit a LaunchCI request 817 for a compute instance. In one embodiment, the client may specify an authorization role intended to be used by a program running within the CI as a parameter of the LaunchCI request. In some embodiments, if the ISM-IRE feature is enabled for the instance type requested by the client (e.g., by default or after the client opts in), the VCS control plane may launch ISM-IRE using a subset of the compute instance memory as part of the initialization or setup of the requested compute instance. In other embodiments, the launch of the ISM-IRE may be postponed until later in the life cycle of the compute instance, such as until an indication is received that a program running in the compute instance wants to access a remote resource. In at least some embodiments, after launching the compute instance, a CILaunched message 819 may be sent to the client.

[0069] In various embodiments, the VCS client may submit an AddNewRoleToCI request 829 indicating a new authorization role to be assigned to the specified compute instance through programming interface 877. 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, the corresponding instance secret may be obtained through a secret manager running within the ISM-IRE of the compute instance.

[0070] A client may sometimes wish to modify (or remove) an authorization role assigned to a computing instance. In some embodiments, a ModifyRole request 833 specifying a change (e.g., permission to access additional remote resources, removal of permission to access some resources, etc.) may be submitted via programming interface 877. In the depicted embodiment, an indication of the change may be stored at the VCS control plane, and a RoleChanged message 835 may be sent to the client. In some embodiments, role information may be stored in an access management service or similar Figure 1 The identity and role management service of the IRMS 162 of the VCS may be stored at the access management service, rather than or in addition to being stored at the VCS itself. In one such embodiment, if a client wishes to modify a role, a corresponding request may be sent to the access management service or the IRMS, and the service may notify the VCS of any changes that the VCS may need to take action on. In some embodiments, in response to a role change, the VCS control plane may cause the secret manager of the ISM-IRE of the computing instance to which the role is assigned to refresh or reacquire the instance secrets corresponding to the changed role.

[0071] In various embodiments, the VCS client 810 may provide preferences or requirements related to instance secret expiration. For example, a client may wish to set a maximum amount of time that an instance secret remains valid, or a maximum number of remote resource access requests that can use a given instance secret, after which the ISM-IRE's secret manager must obtain a new version of the instance secret. Expiring secrets in this manner may further reduce the extent to which secrets are misused. In the depicted embodiment, a client may submit an InstanceSecretsExpirationPreferences message 843 indicating one or more criteria that should be used for instance secrets of one or more of the client's compute instances. The preferences may be stored by the VCS control plane, and an ExpirationPreferencesApplied message 845 may be sent to the client indicating that the preferences are being enforced.

[0072] In some embodiments, the VCS control plane (and / or the control planes of other services at which remote resources accessed from compute instances are managed) can capture various metrics related to remote accesses using instance secrets, such as the number of remote accesses per unit time, log records of such accesses indicating which specific remote resources were accessed, etc. In one embodiment, a client can submit a GetInstanceSecretsUsageMetrics request 847 to view at least some metrics associated with a given set of compute instances or a given set of roles. The requested metrics can be provided to the client in one or more MetricSet messages 849. It should be noted that in addition to the remote access request, the client can also submit a GetInstanceSecretsUsageMetrics request 847 to view at least some metrics associated with a given set of compute instances or a given set of roles. Figure 8 In some embodiments other than those shown, the VCS may support other types of programmatic interactions related to the use of the ISM-IRE.

[0073] Fig. 9 is a flowchart illustrating aspects of operations that may be performed to manage instance secrets using an isolated runtime environment according to at least some embodiments. As shown in element 901, the features and functions of Figure 1 A control plane server (CPS) of a VCS similar to VCS 110 may receive an indication that an enhanced secret management technique will be implemented using an IRE for secrets for protecting remote resource requests from one or more of the compute instances (CI) of a VCS client. For example, the client may submit a message indicating that the client has opted in to use such an IRE.

[0074] In response to an instance launch request from a client (element 904), a computing instance CI1 may be launched at a virtualization server VS. In various embodiments, the ISM-IRE may be automatically launched within CI1 without receiving a request to launch the ISM-IRE (element 907). In various embodiments, a portion of the memory allocated to CI1 may be set aside for use by the ISM-IRE. This separated portion of memory may be inaccessible to any program not running within the ISM-IRE itself (including other programs running at CI1). In at least some embodiments, network communications from the ISM-IRE may be prohibited, and access to persistent storage devices from the ISM-IRE may also be prohibited. In some embodiments, Figure 3 A secure local communication channel of the type shown and an associated broker process (CIP) may provide a means of communication between the ISM-IRE and external entities.

[0075] In the depicted embodiment, a secret manager (SM) running within the ISM-IRE may obtain or determine one or more instance secrets (e.g., encryption keys) associated with an authorized role (element 910) assigned to CI1. In at least some embodiments, the role may be defined and / or assigned to CI1 by a client on whose behalf CI1 is established. In various embodiments, the instance secrets may not be accessible from programs running within CI1 and not within the ISM-IRE.

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

[0077] In various embodiments, the SM may use the instance secret to generate a security artifact associated with the remote access request (e.g., a digital signature of at least a portion of the request) (element 916). The security artifact may be transmitted, transferred, or provided from the SM to the application without revealing the instance secret itself to the application (element 919). The application may then transmit the security artifact along with the request itself to the resource manager of the remote resource that is desired to be accessed (element 922). In the depicted embodiment, if the resource manager determines that the security artifact is valid and CI1 is therefore allowed to access the requested resource, the application may gain access to the resource (element 928). In some embodiments, the resource manager may utilize another service, such as an authorization / authentication service of a provider network, to determine whether the artifact is valid; in other embodiments, the resource manager may make validity / invalidity determinations on its own.

[0078] It should be noted that in various embodiments, Fig. 9 Some of the operations shown in the flowcharts of the drawings may be performed in a different order than that shown in the drawings, or may be performed in parallel rather than sequentially. In one or more embodiments, additionally, it may not be necessary to Fig. 9 Some of the operations shown.

[0079] In at least some embodiments, a server implementing the types of technologies described herein (e.g., including functionality of a VCS, security secrets services, storage services, database services, authorization / authentication services, identity and role management services, and / or other services of a cloud provider network) may include a general-purpose computer system that includes or is configured to access one or more computer-accessible media. Fig.10Such a general purpose computing device 9000 is shown. In the illustrated embodiment, the computing device 9000 includes one or more processors 9010 coupled to a system memory 9020 (which may include both non-volatile memory modules and volatile memory modules) through an input / output (I / O) interface 9030. The computing device 9000 further includes a network interface 9040 coupled to the I / O interface 9030.

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

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

[0082] In one embodiment, the I / O interface 9030 may be configured to coordinate I / O traffic between the processor 9010, the system memory 9020, and any peripheral devices in the device, including the network interface 9040 or other peripheral interfaces such as various types of persistent and / or volatile storage devices. In some embodiments, the I / O interface 9030 may perform any necessary protocol, timing, or other data transformations to convert data signals from one component (e.g., the system memory 9020) into a format suitable for use by another component (e.g., the processor 9010). In some embodiments, for example, the I / O interface 9030 may include support for devices (including various types of hardware accelerators) attached through various types of peripheral buses (such as variants of the peripheral component interconnect (PCI) bus standard or the universal serial bus (USB) standard). In some embodiments, for example, the functions of the I / O interface 9030 may be split into two or more separate components, such as a north bridge and a south bridge. Moreover, in some embodiments, some or all of the functions of the I / O interface 9030, such as the interface to the system memory 9020, may be directly incorporated into the processor 9010.

[0083] The network interface 9040 may be configured to allow data to be transferred between the computing device 9000 and other devices 9060 (e.g., Figures 1 to 9 In various embodiments, network interface 9040 may support communication via any suitable wired or wireless general purpose data network (e.g., Ethernet type), for example. Additionally, network interface 9040 may support communication via a telecommunications / telephone network (e.g., an analog voice network or a digital fiber optic communication network), via a storage area network (e.g., a Fiber Channel SAN), or via any other suitable type of network and / or protocol.

[0084] In some embodiments, system memory 9020 may represent one embodiment of a computer-accessible medium configured to store a program for implementing Figures 1 to 9At least a subset of the program instructions and data of the methods and devices discussed in the context of . However, in other embodiments, the program instructions and / or data may be received, sent or stored on different types of computer accessible media. In general, the computer accessible medium may include a non-transitory storage medium or a storage medium such as a magnetic or optical medium, such as a disk or DVD / CD coupled to the computing device 9000 via an I / O interface 9030. The non-transitory computer accessible storage medium may also include any volatile or non-volatile medium, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., which may be included in some embodiments of the computing device 9000 as a system memory 9020 or another type of memory. In some embodiments, a plurality of non-transitory computer readable storage media may store program instructions together, and when the program instructions are executed on one or more processors or across one or more processors, at least a subset of the methods and techniques described above is implemented. The computer accessible medium may further include a transmission medium or a signal such as an electrical signal, an electromagnetic signal or a digital signal, which is transmitted through a communication medium such as a network and / or a wireless link, such as can be implemented through a network interface 9040. You can use Fig.10 The functions described in various embodiments may be implemented using some or all of the computing devices shown in the figure; for example, software components running on various different devices and servers may collaborate to provide functions. In some embodiments, in addition to or instead of using a general-purpose computer system for implementation, a storage device, a network device, or a dedicated computer system may be used to implement part of the described functions. The term "computing device" as used herein refers to at least all of these types of devices and is not limited to these types of devices.

[0085] Embodiments of the present disclosure may be described in light of the following terms:

[0086] Clause 1. A system comprising:

[0087] Control plane servers for virtualized computing services in a cloud provider's network;

[0088] A virtualized server for the virtualized computing service; and

[0089] a resource manager for a collection of resources of another service of the cloud provider network;

[0090] The control plane server is configured to:

[0091] causing an instance secret management isolated runtime environment to be launched at the virtualization server, wherein the instance secret management isolated runtime environment uses a subset of memory allocated to a computing instance of the virtualization server, wherein the instance secret management isolated runtime environment is launched without receiving a launch request for the instance secret management isolated runtime environment from a client of the virtual computing service on whose behalf the computing instance is launched, wherein the subset of memory is inaccessible from programs running outside the instance secret management isolated runtime environment, wherein network communications from the instance secret management isolated runtime environment to endpoints outside the virtualization server are prohibited, and wherein the instance secret management isolated runtime environment includes a secret manager;

[0092] wherein the secret manager is configured to:

[0093] determining, from a security service of the cloud provider network, a cryptographic key associated with an authorization role assigned to the computing instance without receiving a request from the client to determine the cryptographic key, wherein the cryptographic key is not accessible to programs that (a) run at the virtualization server and (b) do not run within the instance secret management isolation runtime environment; and

[0094] obtaining an indication of a request generated by an application running within the computing instance to access a resource in the resource collection; and

[0095] providing a signature associated with at least a portion of the request to the application, wherein the signature is generated by the secret manager using at least the cryptographic key; and

[0096] The resource manager is configured as follows:

[0097] In response to determining that the signature is acceptable and the authorization role allows access to the resource, providing the application with access to the resource.

[0098] Clause 2. The system of clause 1, wherein the control plane server is further configured to:

[0099] Before causing the instance secret management isolation runtime environment to start, verify that the client does not opt ​​out of using the instance secret management isolation runtime environment.

[0100] Clause 3. The system of any one of clauses 1 to 2, wherein the control plane server is further configured to:

[0101] obtaining, via a programming interface from the client, an indication of expiration criteria for one or more secure secrets managed by the secret manager, including the encryption key; and

[0102] The secret manager is further configured to:

[0103] A replacement encryption key is obtained according to the expiration criteria.

[0104] Clause 4. The system of any one of clauses 1 to 3, wherein the encryption key is obtained at the secret manager after verifying at least a portion of the installed software of the virtualization server.

[0105] Clause 5. The system of any one of clauses 1 to 4, wherein the control plane server is further configured to:

[0106] An indication that the authorization role is to be assigned to the computing instance is obtained from the client through a programming interface.

[0107] Clause 6. A computer-implemented method comprising:

[0108] launching an instance secret management isolated runtime environment using a first subset of memory of a compute instance of a virtualized server allocated to a virtualized computing service without receiving a request for the instance secret management isolated runtime environment from a client on whose behalf the compute instance was launched, wherein the first subset of memory is not accessible from a program running outside of the instance secret management isolated runtime environment, and wherein the instance secret management isolated runtime environment includes a first secret manager;

[0109] providing, by the first secret manager, to an application within the computing instance, a first security artifact associated with a request to access a first resource from the application, wherein the first security artifact was generated by the first secret manager using a first security secret associated with the computing instance, wherein the first security secret is inaccessible to programs running within the computing instance and not running within the instance secret management isolation runtime environment; and

[0110] In response to determining that the first security artifact is valid, access to the first resource is obtained by the application.

[0111] Clause 7. The computer-implemented method of clause 6, further comprising:

[0112] A request is obtained from the client through a programming interface to assign a first authorization role to the computing instance, wherein the first security secret is generated based at least in part on the first authorization role, and wherein the first authorization role grants the computing instance permission to access the first resource.

[0113] Clause 8. The computer-implemented method of clause 7, further comprising:

[0114] Obtaining, from the client through the programming interface, a request to assign a second authorization role to the computing instance, wherein the second authorization role grants the computing instance permission to access a second resource; and

[0115] Another security artifact associated with a request to access the second resource from another application within the computing instance is provided by the first secret manager to the other application within the another application, wherein the other security artifact is generated by the first secret manager using a second security secret associated with the second authorization role, wherein the second security secret is inaccessible to programs running within the computing instance and not within the instance secret management isolation runtime environment.

[0116] Clause 9. The computer-implemented method of any one of clauses 6 to 7, further comprising:

[0117] An indication is obtained through a programming interface that the client has opted in to use the instance secret management isolation runtime environment, wherein the instance secret management isolation runtime environment is started at least in part based on the indication.

[0118] Clause 10. The computer-implemented method of any one of clauses 6 to 7 or 9, further comprising:

[0119] obtaining, via a programming interface from the client, an indication of expiration criteria for one or more security secrets managed by a first secret manager, the one or more security secrets including the first security secret; and obtaining, by the first secret manager, a replacement security secret for the first security secret based on the expiration criteria.

[0120] Clause 11. The computer-implemented method of any one of clauses 6 to 7 or 9 to 10, further comprising:

[0121] Prior to providing the first security secret to the first secret manager, at least a portion of the installed software of the virtualization server is authenticated.

[0122] Clause 12. The computer-implemented method of any one of clauses 6 to 7 or 9 to 11, further comprising:

[0123] The first security secret is obtained by the first secret manager during a boot procedure of the instance secret management isolation runtime environment before generating the request to access the first resource.

[0124] Clause 13. The computer-implemented method of any one of clauses 6 to 7 or 9 to 11, further comprising:

[0125] The first security secret is obtained by the first secret manager in response to an indication of the request to access the first resource.

[0126] Clause 14. The computer-implemented method of any one of clauses 6 to 7, 9 to 11 or 13, further comprising:

[0127] One or more shared memory buffers are utilized by the first secret manager to communicate with entities external to the instance secret management isolation runtime environment.

[0128] Clause 15. The computer-implemented method of any one of clauses 6 to 7, 9 to 11, or 13 to 14, further comprising:

[0129] launching the isolated runtime environment requested by the client using the second subset of memory allocated to the computing instance; and

[0130] A second secure secret is utilized by a second secret manager running within the isolated runtime environment requested by the client to generate a second secure artifact to be utilized by another application running within the computing instance, wherein the second secure secret is obtained from a source indicated by the client and wherein the second secure secret is not accessible to the first secret manager.

[0131] Clause 16. A non-transitory computer-accessible storage medium storing program instructions that, when executed on a processor:

[0132] causing launching of an instance secret management isolation runtime environment at a virtualization server of a virtualized computing service, wherein the instance secret management isolation runtime environment utilizes a subset of memory allocated to a computing instance of the virtualization server, wherein the subset of memory is inaccessible from programs running outside of the instance secret management isolation runtime environment, and wherein the instance secret management isolation runtime environment includes a secret manager;

[0133] providing, by the secret manager, to an application within the computing instance, a security artifact associated with a request to access a resource from the application, wherein the security artifact was generated by the secret manager using a security secret associated with the computing instance, wherein the security secret is inaccessible to programs running within the computing instance and not running within the instance secret management isolation runtime environment; and

[0134] In response to determining that the security artifact is valid, access to the resource is obtained by the application.

[0135] Clause 17. A non-transitory computer-accessible storage medium as described in Clause 16, wherein the security secret is generated at least in part based on an authorization role assigned to the computing instance by a client on whose behalf the computing instance was launched, and wherein the authorization role grants the computing instance permission to access the resource.

[0136] Clause 18. A non-transitory computer-accessible storage medium as described in any one of Clauses 16 to 17, wherein the instance secret management isolated runtime environment is started after determining that a client on whose behalf the computing instance is started has opted in to use at least one instance secret management isolated runtime environment.

[0137] Clause 19. A non-transitory computer accessible storage medium according to any one of clauses 16 to 18 storing further program instructions which, when executed:

[0138] The secret manager is caused to obtain a replacement for the security secret according to an expiration criteria for the security secret, wherein the expiration criteria is indicated by a client on whose behalf the computing instance was launched.

[0139] Clause 20. A non-transitory computer-accessible storage medium as described in any of Clauses 16 to 19, wherein the resource comprises one or more of: (a) data items stored at an object storage service, or (b) data items stored at a database service.

[0140] in conclusion

[0141] Various embodiments may further include receiving, sending or storing instructions and / or data implemented according to the foregoing description on a computer-accessible medium. In general, a computer-accessible medium may include a storage medium or memory medium (such as a magnetic medium or an optical medium, for example, a disk or a DVD / CD-ROM), a volatile or non-volatile medium (such as a RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), a ROM, etc.), and a transmission medium or signal (such as an electrical signal, an electromagnetic signal, or a digital signal transmitted through a communication medium (such as a network and / or a wireless link)).

[0142] The various methods shown in the accompanying drawings 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, reordered, combined, omitted, modified, etc.

[0143] It will be apparent to those skilled in the art having the benefit of this disclosure that various modifications and changes may occur. It is intended to cover all such modifications and changes, and, therefore, the above description is to be regarded as illustrative rather than restrictive.

Claims

1. A system comprising: one or more computing devices; wherein the one or more computing devices include instructions that, when executed on or across the one or more computing devices: causing launching of an instance secret management isolation runtime environment at a virtualization server of a virtualized computing service, wherein the instance secret management isolation runtime environment utilizes a subset of memory allocated to a computing instance of the virtualization server, wherein the subset of memory is inaccessible from programs running outside of the instance secret management isolation runtime environment, and wherein the instance secret management isolation runtime environment includes a secret manager; providing, by the secret manager, to an application within the computing instance, a security artifact associated with a request to access a resource from the application, wherein the security artifact was generated by the secret manager using a security secret associated with the computing instance, wherein the security secret is inaccessible to programs running within the computing instance and not running within the instance secret management isolation runtime environment; and In response to determining that the security artifact is valid, access to the resource is obtained by the application.

2. The system of claim 1 , wherein the one or more computing devices include further instructions that, when executed on or across the one or more computing devices, further cause the one or more computing devices to: obtaining, through a programming interface, an indication of an expiration criterion for the security secret; and A replacement security secret is obtained according to the expiration criteria.

3. The system of any one of claims 1 to 2, wherein the security secret is obtained at the secret manager after verifying at least a portion of the installed software of the virtualization server.

4. A computer-implemented method comprising: causing launching, at a virtualization server of a virtualized computing service, an instance secret management isolated runtime environment, wherein the instance secret management isolated runtime environment utilizes a subset of memory allocated to a computing instance of the virtualization server, wherein the subset of memory is inaccessible from programs running outside of the instance secret management isolated runtime environment, and wherein the instance secret management isolated runtime environment includes a first secret manager; providing, by the first secret manager, to an application within the computing instance, a security artifact associated with a request to access a first resource from the application, wherein the security artifact was generated by the first secret manager using a first security secret associated with the computing instance, wherein the first security secret is inaccessible to programs running within the computing instance and not running within the instance secret management isolation runtime environment; and In response to determining that the security artifact is valid, access to the first resource is obtained by the application.

5. The computer-implemented method of claim 4, further comprising: A request is obtained, through a programming interface, to assign a first authorization role to the computing instance, wherein the first security secret is generated based at least in part on the first authorization role, and wherein the first authorization role grants the computing instance permission to access the first resource.

6. The computer-implemented method of claim 5, further comprising: Obtaining, through the programming interface, a request to assign a second authorization role to the computing instance, wherein the second authorization role grants the computing instance permission to access a second resource; and Another security artifact associated with a request to access the second resource from another application within the computing instance is provided by the first secret manager to the other application within the another application, wherein the other security artifact is generated by the first secret manager using a second security secret associated with the second authorization role, wherein the second security secret is inaccessible to programs running within the computing instance and not within the instance secret management isolation runtime environment.

7. The computer-implemented method of any one of claims 4 to 5, further comprising: An indication is obtained that a client on whose behalf the computing instance was launched has opted in to use the instance secret management isolated runtime environment, wherein the instance secret management isolated runtime environment is launched at least in part based on the indication.

8. The computer-implemented method of any one of claims 4 to 5 or 7, further comprising: obtaining an indication of an expiration criteria for one or more security secrets managed by the first secret manager, the one or more security secrets including the first security secret; and A replacement security secret for the first security secret is obtained by the first secret manager based on the expiration criteria.

9. The computer-implemented method of any one of claims 4 to 5 or 7 to 8, further comprising: The first security secret is obtained by the first secret manager during a boot procedure of the instance secret management isolation runtime environment before generating the request to access the first resource.

10. The computer-implemented method of any one of claims 4 to 5 or 7 to 8, further comprising: The first security secret is obtained by the first secret manager in response to an indication of the request to access the first resource.

11. The computer-implemented method of any one of claims 4 to 5, 7 to 8 or 10, further comprising: One or more shared memory buffers are utilized by the first secret manager to communicate with entities external to the instance secret management isolation runtime environment.

12. The computer-implemented method of any one of claims 4 to 5, 7 to 8, or 10 to 11, further comprising: launching the isolated runtime environment requested by the client using the second subset of memory allocated to the computing instance; and The second security secret is utilized by a second secret manager running within the isolated runtime environment requested by the client to generate a second security artifact to be utilized by another application running within the computing instance, wherein The second secure secret is obtained from a source indicated by a client, the isolated runtime environment requested by the client being launched on behalf of the client, and wherein the second secure secret is not accessible to the first secret manager.

13. A non-transitory computer accessible storage medium storing program instructions which, when executed on a processor: causing launching of an instance secret management isolation runtime environment at a virtualization server of a virtualized computing service, wherein the instance secret management isolation runtime environment utilizes a subset of memory allocated to a computing instance of the virtualization server, wherein the subset of memory is inaccessible from programs running outside of the instance secret management isolation runtime environment, and wherein the instance secret management isolation runtime environment includes a secret manager; providing, by the secret manager, to an application within the computing instance, a security artifact associated with a request to access a resource from the application, wherein the security artifact was generated by the secret manager using a security secret associated with the computing instance, wherein the security secret is inaccessible to programs running within the computing instance and not running within the instance secret management isolation runtime environment; and In response to determining that the security artifact is valid, access to the resource is obtained by the application.

14. The non-transitory computer-accessible storage medium of claim 13, wherein the instance secret management isolated runtime environment is launched after determining that a client on whose behalf the computing instance is launched has opted in to use at least one instance secret management isolated runtime environment.

15. The non-transitory computer-accessible storage medium of any one of claims 13 to 14, wherein the resource comprises one or more of: (a) data items stored at an object storage service, or (b) data items stored at a database service.

Images