Techniques for persisting data across instances of cloud shell

Abstract

To provide a method, computer system and storage medium for persisting data across secure shell instances.SOLUTION: A method includes: causing a computer system to receive a request to reserve a block volume, the request being transmitted from a session manager service; reserving the block volume; identifying a data center identifier of the block volume; returning the data center identifier of the block volume to the session manager service; attaching the block volume to a volume management fleet machine; receiving an instruction from the session manager service to release the block volume; creating a backup of the block volume comprising the data stored in the block volume; and releasing the block volume.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] REFERENCE TO RELATED APPLICATIONS This application is related to U.S. Non-Provisional Patent Application No. 17 / 078,835 (filed October 23, 2020), entitled "TECHNIQUES FOR PERSISTING DATA ACROSS INSTANCES OF A CLOUD SHELL," U.S. Non-Provisional Patent Application No. 16 / 993,973 (filed August 14, 2020), entitled "TECHNIQUES FOR UTILIZING MULTIPLE NETWORK INTERFACES FOR A CLOUD SHELL," and U.S. Non-Provisional Patent Application No. 16 / 993,973 (filed August 14, 2020), entitled "TECHNIQUES FOR USING SIGNED NONCES TO SECURE CLOUD SHELLS." This application claims the benefit of and priority to application 16 / 993,970 (filed August 14, 2020), the disclosures of which are incorporated by reference in their entirety for all purposes. [Background technology]

[0002] background Cloud-based platforms provide users with scalable and flexible computing resources. Such cloud-based platforms, also known as Infrastructure as a Service (IaaS), may offer an entire suite of cloud solutions around a customer's data, such as solutions for authoring transformations, loading data, and presenting data. IaaS systems may implement security protocols to protect against unauthorized access to user data. Summary of the Invention

[0003] overview Techniques for persisting data across Cloud Shell instances Techniques are provided (e.g., methods, systems, non-transitory computer-readable media storing code or instructions executable by one or more processors) for persisting user data across secure shell instances, using restored block volumes, and terminating instances between sessions.

[0004] In one embodiment, a method includes a computer system receiving a request to reserve a block volume, the request being received from a session manager service. The method may include the computer system reserving the block volume. The method may include the computer system identifying a data center identifier for the block volume. The method may include the computer system returning the data center identifier for the block volume to the session manager service. The method may include the computer system attaching the block volume. The method may include the computer system receiving an instruction from the session manager service to release the block volume. The method may include the computer system creating a backup of the block volume including data stored in the block volume. The method may also include the computer system releasing the block volume.

[0005] In a variant, the request may include a user identifier, and reserving the block volume includes determining whether the registered block volume is assigned to a user corresponding to the user identifier, reserving the registered block volume according to the registered block volume being assigned to the user, and reserving an empty volume from a pool of empty volumes according to the registered block volume not being assigned to a user corresponding to the user identifier, the empty volume being pre-formatted to dock with the secure cloud shell. The method may include receiving a request to restore a block volume from a session manager service and creating a restore volume using a backup of the block volume, where the restore volume includes data stored in the block volume, and the method may further include returning a data center identifier of the restore volume to the session manager service. The backup of the block volume may further include an identifier of the backup, and creating the restore volume may include reserving an empty block volume from a pool of empty volumes, where the empty block volume is pre-formatted to dock with the secure cloud shell, and creating the restore volume may further include retrieving the backup of the block volume using the identifier of the backup, at least partially provisioning the empty block volume by loading the backup of the block volume into it, and identifying the data center identifier of the empty block volume as the data center identifier of the restore volume. Creating a backup of the block volume may include creating a disk image of the block volume. Creating a backup of the block volume may include converting data of the block volume into object data and storing the object data in an object storage system.

[0006] In one embodiment, a computer system includes one or more processors and memory in communication with the one or more processors, the memory configured to store computer-executable instructions, execution of which causes the one or more processors to perform one or more of the method steps described above.

[0007] In particular embodiments, a computer-readable storage medium stores computer-executable instructions that, when executed, cause one or more processors of a computer system to perform one or more steps of the methods described above.

[0008] Techniques for securing cloud shells using signed nonces Techniques are also provided (e.g., methods, systems, non-transitory computer-readable media storing code or instructions executable by one or more processors) for securing a cloud shell for operating one or more terminals using the signed nonce in coordination with one or more additional security operations.

[0009] In a first aspect, a method includes a session manager service receiving a request to connect a user device to a secure connection to a secure shell instance; the session manager service authorizing the user device; the session manager service configuring a secure shell instance described by a shell identifier of the secure shell instance; the session manager service generating a nonce token; the session manager service signing the nonce token to generate a signed nonce token; and the session manager service providing the signed nonce token, the shell identifier, and a router address to the user device.

[0010] In one example, authorizing the user device includes receiving a login token from the user device, the login token including a user identifier; requesting an authorization system public key from an authorization service; authenticating the user device based at least in part on decrypting the login token with the authorization system public key; requesting a delegation token from the authorization service by at least in part by providing the user identifier, a resource identifier of a resource identified in the request, and an expiration period for the request; and receiving the delegation token from the authorization service, wherein the authorization service grants access to the resource identified in the request within the expiration period. It is configured to generate a delegation token upon granting access.

[0011] In one example, signing the nonce token includes signing the nonce token using a system private key of a public / private key pair maintained by a session manager service and providing the system public key of the public / private key pair to the secure shell router at the router address.

[0012] In one example, the method further includes storing the nonce token in a data store, the nonce token including the key sequence, and the method further includes verifying whether the nonce token is valid based at least in part on looking up the data store on the key sequence, and removing the nonce token from the data store after the secure shell router establishes a secure connection between the user device and the secure shell instance.

[0013] In some examples, the method further includes terminating the secure shell instance after a period of inactivity or after termination of the secure connection by the user device.

[0014] In one example, configuring the secure shell instance includes reserving a block volume, receiving a domain identifier corresponding to the block volume, and allocating an instance on the block volume using the domain identifier, where the instance is allocated from a plurality of available instances, and configuring the secure shell instance further includes receiving a shell identifier corresponding to the instance and installing a configuration file on the instance, where the configuration file includes the requested information included in the request.

[0015] In one example, the secure shell instance runs a docker container such that the request includes instructions to run a terminal on the docker container.

[0016] In a second aspect, a computer system includes one or more processors and memory in communication with the one or more processors, the memory configured to store computer-executable instructions, and execution of the computer-executable instructions causes the one or more processors to perform steps including one or more steps of the method of the first aspect and subsequent examples.

[0017] In a third aspect, a non-transitory computer-readable storage medium stores computer-executable instructions that, when executed, cause one or more processors of a computer system to perform steps including one or more steps of the method of the first aspect and subsequent examples.

[0018] Techniques for utilizing multiple network interfaces for cloud shells Techniques are further provided (e.g., methods, systems, non-transitory computer-readable media storing code or instructions executable by one or more processors) for securing a cloud shell against unauthorized access by external devices using multiple network interfaces in coordination with multiple virtual cloud networks that isolate different IaaS subsystems.

[0019] In a first aspect, a method includes receiving a command to perform an operation by a computer system, the command being received from a router via a primary virtual network interface card (vNIC), the method further including performing the operation, generating an output of the operation, and sending a message including the output of the operation to a shell subnet via a secondary virtual network interface card, the secondary virtual network interface card receiving the shell from the computer system. The shell subnet may be configured to transmit the output of the operation to an external network via a network gateway.

[0020] In one example, the action may be requested by a user of a user device, and generating an output of the action may include generating a reply message for the user device and sending the reply message to the router via a primary virtual network interface card. The primary virtual network interface card may be configured to accept the reply message for the user device and to reject the message including the output of the action.

[0021] In one example, the computer system may be a virtual machine in a first virtual cloud network, the first virtual cloud network being configured in a private root compartment.

[0022] In one example, the router may be in a second virtual cloud network, the second virtual cloud network being different from the first virtual cloud network and configured in a private root compartment.

[0023] In one example, the shell subnet may be in a third virtual cloud network, which is different from the first virtual cloud network and configured in a public root compartment.

[0024] In one example, the private root compartment may be associated with a first block of IP addresses that may be attributed to network traffic from the private root compartment. The public root compartment may be associated with a second block of IP addresses, the second block of IP addresses being different from the first block of IP addresses. The second block of IP addresses may be attributed to network traffic from one or more users of the computer system.

[0025] In one example, the network gateway may be a network address translation (NAT) gateway configured to send messages using an IP address from a block of IP addresses that may be attributed to network traffic from one or more users of the computer system.

[0026] In a second aspect, a computer system includes one or more processors and memory in communication with the one or more processors, the memory configured to store computer-executable instructions, and execution of the computer-executable instructions causes the one or more processors to perform steps including one or more steps of the method of the first aspect and subsequent examples.

[0027] In a third aspect, a non-transitory computer-readable storage medium stores computer-executable instructions that, when executed, cause one or more processors of a computer system to perform steps including one or more steps of the method of the first aspect and subsequent examples. [Brief explanation of the drawings]

[0028] [Figure 1] FIG. 1 illustrates an exemplary system for managing secure shell instances, according to one or more embodiments. [Figure 2] FIG. 1 illustrates an example technique for reserving a block volume for a secure shell instance, according to one or more embodiments. [Figure 3] FIG. 1 illustrates an exemplary technique for releasing a block volume containing user data from a secure shell instance, according to one or more embodiments. [Figure 4] FIG. 1 illustrates an example technique for restoring block volumes for a restored Secure Shell instance, according to one or more embodiments. [Figure 5] FIG. 1 is a sequence diagram illustrating an exemplary data flow in which a block volume containing user data is released, according to one or more embodiments. [Figure 6]FIG. 10 is a sequence diagram illustrating an exemplary data flow in which user data is persisted to a restored Secure Shell instance, in accordance with one or more embodiments. [Figure 7] FIG. 1 illustrates an exemplary flow for releasing a block volume for a Secure Shell instance, according to one or more embodiments. [Figure 8] FIG. 1 illustrates an exemplary flow for reserving a block volume for a Secure Shell instance, according to one or more embodiments. [Figure 9] FIG. 1 illustrates an exemplary flow for restoring a block volume for a Secure Shell instance, according to one or more embodiments. [Figure 10] FIG. 1 illustrates an exemplary system for managing secure shell instances, according to one or more embodiments. [Figure 11] FIG. 1 illustrates an exemplary system for managing a secure shell session, according to one or more embodiments. [Figure 12] FIG. 1 illustrates an exemplary system for connecting a user device to a Secure Shell instance, according to one or more embodiments. [Figure 13] FIG. 1 illustrates an exemplary system for configuring a Secure Shell instance with a single-use nonce token, according to one or more embodiments. [Figure 14] FIG. 1 illustrates an example technique for authorizing user devices connecting to a secure shell instance, according to one or more embodiments. [Figure 15] FIG. 1 is a sequence diagram illustrating an exemplary data flow in which a user device connects to a Secure Shell instance, according to one or more embodiments. [Figure 16] FIG. 1 is a sequence diagram illustrating an exemplary data flow in which a user device connects to a Secure Shell instance using an authorization service, according to one or more embodiments. [Figure 17]FIG. 1 illustrates an exemplary flow for managing a secure shell session, according to one or more embodiments. [Figure 18] FIG. 1 illustrates an exemplary flow for configuring a Secure Shell instance with a single-use nonce token, according to one or more embodiments. [Figure 19] FIG. 1 illustrates an example technique for utilizing multiple network interfaces for a secure shell instance, according to one or more embodiments. [Figure 20] FIG. 1 illustrates an exemplary system that utilizes multiple network interfaces to manage communications for a secure shell instance, according to one or more embodiments. [Figure 21] FIG. 1 illustrates an example technique for unidirectional communication with a secure shell instance using multiple network interfaces, according to one or more embodiments. [Figure 22] FIG. 1 illustrates an example technique for using a first network interface for bidirectional communication with a secure shell instance, according to one or more embodiments. [Figure 23] FIG. 1 illustrates an example technique for unidirectional communication with a secure shell instance, according to one or more embodiments. [Figure 24] FIG. 1 illustrates an exemplary regional system for managing communications of secure shell instances, according to one or more embodiments. [Figure 25] FIG. 1 illustrates an exemplary flow for utilizing multiple network interfaces for a secure shell instance, according to one or more embodiments. [Figure 26] FIG. 1 illustrates an exemplary flow for bidirectional communication with a secure shell instance using a network interface, according to one or more embodiments. [Figure 27] FIG. 1 illustrates an exemplary flow for unidirectional communication from a secure shell instance using a network interface, according to one or more embodiments. [Figure 28] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 29] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 30] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 31] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 32] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0029] Detailed Description In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the described embodiments.

[0030] Techniques for persisting data across Cloud Shell instances Cloud-based platforms provide scalable and flexible computing resources to users. Such cloud-based platforms, also known as Infrastructure as a Service (IaaS), may offer an entire suite of cloud solutions around a customer's data, for example, solutions for authoring transformations, loading data, and presenting data. Users of IaaS resources may request to create a secure terminal within a secure shell instance (e.g., WebSocket Secure (ws)) so that operations and data transfers can be performed securely. s) using two-way encryption over the connection).

[0031] In some embodiments, a shell instance may be a dedicated compute instance that may run a Docker container (e.g., a host) and may allow a user device to run a terminal on that Docker container. A user device may be assigned to a single host but may create multiple active terminals on that host. A shell instance may be terminated after a period of inactivity. The instance may run a host, which may then run a secure shell (e.g., a terminal). In some embodiments, the instance and / or host may also be terminated when a terminal has not been active on the host for a period of time.

[0032] In some embodiments, an instance agent may run on the assigned instance and receive WebSocket traffic and process that traffic. The instance agent may handle sending the input and output to a secure shell running on the host. The agent may be an HTTP server that may be configured to redirect the agent to a terminal (e.g., a secure shell running on a Docker container) to create a terminal within the container. In some embodiments, the agent may identify an updated version of the Docker container, start the Docker container, and create a terminal within the container. In some embodiments, the agent may further customize the Docker container to include secure shell configuration information and may run a terminal within the Docker container at least in part by passing in certain environment variables.

[0033] In some embodiments, the volume manager service may persist user data from a terminated instance to a subsequently configured instance of the same user. The volume manager service may identify the user block volume and attach it to a secure shell instance if one is available, and may generate a backup of the user data for the instance as part of a termination operation at the end of the instance's life. The backup operation may include retaining the user data for a retention period, a backup in object storage, and / or a backup image (e.g., a volume image). The volume manager system may create the backup before releasing the user block volume. The volume manager service may communicate with a session manager service, which may query the instance agent to confirm idle time for the secure shell instance. The session manager service may request the volume manager service to release the user block volume after the idle time exceeds the instance's life. In some cases, the session manager service may request the volume manager service to release the user block volume after the retention period has elapsed. The retention period may provide reduced latency when a user requests a new secure shell instance by reattaching the user block volume without restoring the user data to a newly configured block volume from block storage.

[0034] To restore a user block volume as part of creating a secure shell instance, backed-up user data may be transferred from object storage or other backed-up storage format as part of the restore process. For example, the volume manager service may reserve an empty block volume (e.g., at least partially pre-configured for attachment to the secure shell instance) and request that the backed-up user data be transferred by a backup service to provision the empty block volume. The volume manager service may return a unique identifier for the restored user block volume to the session manager service as part of configuring the secure shell instance, thereby persisting the user data from the terminated instance to the new, restored instance.

[0035] In some embodiments, the techniques described herein may be incorporated as computer-executable instructions into a software developer kit (SDK) that may be used by web-based terminals to create and access these resources. In this way, the SDK may also be used by other providers to implement secure web-based terminals. Furthermore, the techniques described herein may enable user devices to connect to a secure shell that operates one or more terminals with improved security and latency. For example, by automatically persisting user data rather than relying on manual instructions to configure backups, a session manager may potentially improve inefficiencies introduced by uneven system loads and overhead introduced by UI backup system requests and by maintaining user block volumes for periods between user connections to secure shell instances (e.g., when the user is not accessing user data). Latency may be reduced in the termination process by automating block volume storage management rather than relying on user-initiated release. In this way, connection requests may experience shorter wait times for block volumes to be reserved during periods of high system demand and low storage availability in a given data center or IaaS region.

[0036] 1 illustrates an exemplary system 100 for managing secure shell instances, according to one or more embodiments. In some embodiments, system 100 may enable users to securely connect to compute instances (e.g., virtual machines (VMs) or dockers). Secure access may allow users to access resources, including but not limited to, distributed storage, compute cores, etc., over an encrypted connection (e.g., https and / or WebSocket Secure (wss)) for real-time data transfer with VMs in the IaaS system. The secure shell instance may allow the user device 110 to connect to unspecified distributed computing system resources (e.g., Infrastructure as a Service (IaaS)). In some embodiments, the user device 110 may generate a signed request for a secure shell instance and send the signed request to the session manager service 120. The session manager service 120 may perform operations as part of fulfilling the signed request to validate the user device 110 and as part of configuring the secure shell instance.

[0037] In some embodiments, the user device 110 may generate the signed request using a user interface, including, but not limited to, a graphical user interface console or a command line interface (CLI). The user interface includes an identity authorization service, which may generate a user public / private key pair. In some cases, the user public / private key pair may be a temporary key pair generated, for example, upon session initialization, upon generating a request for a secure VM connection, etc. The user device 110 may generate the signed request using the private key of the user public / private key pair.

[0038] In some embodiments, session manager service 120 may implement one or more authorization steps as part of managing and provisioning a secure shell instance. Authorization may include, for example, receiving a signed request (e.g., as a step to verify the identity of user device 110) and verifying the signed request by requesting a public key and using that key to verify the signature of the signed request.

[0039] In some embodiments, session manager service 120 may fulfill the signed request, at least in part, by reserving and configuring a secure shell instance. In some cases, session manager service 120 may communicate with volume manager service 130 to reserve a block volume 140. Volume manager service 130 may return a domain identifier for the block volume 140 to session manager service 120. In some embodiments, the domain identifier may describe one or more data centers within a geographic region (e.g., an availability domain (AD)) of the reserved block volume 140. As described in more detail below with reference to the figures, volume manager service 130 may facilitate one or more techniques for persisting user data across multiple secure shell sessions. For example, the techniques may include, in some cases, releasing the user block volume from the secure shell instance and generating a user data backup in response to receiving the release request by volume manager service 130 before terminating the secure shell session.

[0040] In some embodiments, session manager service 120 may provide the domain identifier of block volume 140 (e.g., the AD of the reserved block volume) to instance manager service 150. Instance manager service 150 may then create a compute instance in the AD provided by the volume manager service. The instance manager service 150 may allocate compute instances to the session manager service 120. The instance manager service 150 may provide instance identifier information (e.g., a cloud infrastructure ID) for the allocated instance to the session manager service 120. The allocation of compute instances may be done per user and / or per compartment (where a compartment is a logical container that controls access to cloud system resources and may include subcompartments). For example, the session manager service 120 may allocate separate instances to a user in different compartments. In contrast, the session manager service 120 may allocate a single compute instance for multiple containers (where a container is a packaged software application that may include application code, runtime, system tools, system libraries, and configuration) such that the separate containers share the same compute instance, one container per compartment.

[0041] In some embodiments, session manager service 120 may provide the instance identifier to user device 110 along with the router address of router 160. Router 160 may be configured to connect the user device to the secure shell instance (e.g., via a multiplexed WebSocket connection), as described in more detail below. Additionally, the router may also be configured to validate user device 110 and session manager service 120 as part of securely connecting user device 110 to the secure shell instance.

[0042] In some embodiments, the session manager service 120 may generate a nonce token as part of authorizing and validating a secure connection of the user device 110 to a secure shell instance. In some embodiments, the nonce token may be a web token (e.g., a JavaScript Object Notation "json" web token (jwt token)) that contains information including, but not limited to, a header, a validity period (e.g., minutes before expiration), a key, and / or a random string (e.g., an alphanumeric sequence of a set length). In some cases, the nonce token is generated and provided to the user device 110 along with an instance identifier and a router address.

[0043] As part of configuring a secure shell instance, session manager service 120 may select and configure an existing instance from a pool of available instances 180, as described in more detail with reference to the following figures. In some cases, the session manager service may install a configuration file and a delegation token on the selected instance. The configuration may include parameter information, including, but not limited to, an instance identifier, a domain identifier, request details (e.g., resource allocation, compartment, tenancy), etc. The delegation token may be installed in a user's shell environment on the instance. The token may provide proof that the user has been authenticated and may allow the user to execute commands against their account without the need for re-authentication. In some embodiments, the IaaS system may reject CLI commands executed against user accounts that do not have a delegation token installed in the user's shell environment.

[0044] In some embodiments, the configuration parameters installed by session manager service 120 may be stored in instance configuration store 190. Instance configuration store 190 may allow a new secure shell instance to be restored and / or reconfigured with the requested parameters following termination of the secure shell instance. In some embodiments, the secure shell instance will be terminated once the user has finished using the secure shell instance. In some embodiments, session manager service 120 may detect agent inactivity and / or reconfigure the instance configuration. The instance manager service 150 may be instructed to terminate the secure shell instance based on a period of time (e.g., idle time) and / or a period of activity through the router 160. The idle time may be provided as part of a configuration parameter. In some embodiments, a user of the user device 110 may request that the secure shell instance be terminated, which may be accomplished by the session manager service 120.

[0045] As described above, the exemplary system 100 may provide improved security and stability of IaaS systems by at least allowing user devices to connect to secure shell instances from a console and / or command line interface. Persisting user data during instance restore operations rather than maintaining user block volumes may reduce the potential impact of a breakout from a container by restoring data from a system service that retains data without read / write access when not in use, rather than maintaining potentially compromised block volumes.

[0046] Exemplary system 100 may further improve the security and performance of an IaaS system by implementing user data persistence techniques. For example, generating a user data backup and generating a restore volume in response to receiving a restore request may reduce system resource usage associated with maintaining a user block volume. Instead, the backup may be stored in a low-overhead storage format (e.g., a disk image, etc.) until the data is required for a restored Secure Shell session. Similarly, maintaining a user block volume may present a level of risk if system 100 is compromised. For example, in a system that does not allow read / write operations, keeping user data as a backup in long-term storage may reduce the risk of unauthorized access to user data between Secure Shell sessions.

[0047] 2 illustrates an example technique 200 for reserving a block volume for a secure shell instance, according to one or more embodiments. As described in more detail above with reference to FIG. 1, as part of reserving and configuring a shell instance, session manager service 120 may perform one or more operations in coordination with a configuration service of example system 100 of FIG.

[0048] In some embodiments, the session manager service may receive a request from the user device to connect to a secure shell (e.g., operation 202), as described above with respect to authorizing and validating user requests. In response to receiving the user request, the session manager service 120 may coordinate with the volume manager service 130 to reserve a volume (e.g., operation 204). Reserving a volume may involve steps including, but not limited to, the volume manager service 130 verifying (e.g., operation 206) whether one or more block volumes are already associated with and / or assigned to the user of the user device 110 (e.g., user block volumes 230) and available to host the secure shell instance 250. This may include checking the user identifier (e.g., username or login ID) against a registry of block volumes managed by the volume manager service 130. If the user block volume 230 is identified, domain identifier information (e.g., resource ID, data center infrastructure locator, etc.) may be returned to the session manager service 120 to indicate that the volume has been reserved to host the secure shell instance 250 (e.g., operation 208).

[0049] Volume manager service 130 may find that no user block volumes 230 are available for attachment to secure shell instance 250. In some embodiments, volume manager service 130 may reserve an empty block volume 240, which may include one or more of the block volumes 140 available in a given data center and / or IaaS region that may not yet be allocated to a user. Similarly, volume manager service 130 may provide resource identifier information for session manager service 120 to implement in subsequent operations. For example, session manager service 120 may allocate an instance in a block volume 140 returned by volume manager service 130 (e.g., operation 210).

[0050] In some embodiments, allocating the instance may include providing the domain identifier to instance manager service 150. As described in more detail with reference to FIG. 1, instance manager service 150 may select and reserve an existing instance maintained as part of several available instances (e.g., instance 180 of FIG. 1) that may be at least partially pre-configured for use as a secure shell instance. Instance manager service 150 may return an instance identifier (e.g., an instance ID) to session manager service 120, which may enable session manager service 120 to identify the selected instance in subsequent operations. In some embodiments, selecting and reserving an existing instance, rather than creating and configuring an instance when fulfilling the connection request, may potentially reduce system latency in processing the connection request.

[0051] 3 illustrates an example technique 300 for releasing a block volume containing user data from a secure shell instance, according to one or more embodiments. One or more subsystems of system 100 of FIG. 1 (e.g., session manager service 120, volume manager service 130, and instance manager service 150) may perform operations associated with terminating and / or restoring a secure shell instance (e.g., secure shell instance 250 of FIG. 2). For example, when a user of a user device (e.g., user device 110 of FIG. 1) requests to disconnect from a secure shell instance, terminating the secure shell session may include detaching the user block volume from the secure shell instance, as well as one or more additional and / or alternative operations, as described below.

[0052] In some embodiments, session manager service 120 requests idle time from instance agent 350 (e.g., act 302). As described above, instance agent 350 opens a secure WebSocket connection and communicates input and output. The agent may be an HTTP server that may be configured to redirect the agent to a terminal running on the Docker container instance (e.g., a secure shell running on a Docker container). In some embodiments, the agent may identify an updated version of the Docker container, start the Docker container, and create a terminal within the container. In some embodiments, the agent may further customize the Docker container to include secure shell configuration information and may run a terminal within the Docker container at least in part by passing in certain environment variables.

[0053] In some embodiments, session manager service 120 may be configured to terminate a secure shell instance after a period of time has passed since the last connection that exceeds a threshold time and / or after a user request to disconnect or terminate the secure shell instance. In some embodiments, session manager service 120 may send a request to instance manager service 150 to terminate the secure shell instance after the idle time returned by instance agent 350 exceeds the configured lifetime of the secure shell instance (e.g., operation 304). In response, instance manager service 150 (e.g., in coordination with instance agent 350) may perform additional operations to terminate the secure shell instance.

[0054] As part of the termination operation, volume manager service 130 may receive a request to release the block volume (e.g., operation 308). In some embodiments, the block volume (e.g., block volume 140 of FIG. 1) may contain user data generated and / or stored during the secure shell session that may be beneficial to a user of the user device (e.g., user device 110 of FIG. 1). In this manner, volume manager service 130 may perform one or more operations to facilitate termination of the secure shell instance, including, but not limited to, creating a backup of the block volume (e.g., operation 310).

[0055] In some embodiments, volume manager service 130 may create backups using backup service 340. Backup services may include external IaaS resources, including, but not limited to, block storage service 342, object storage service 344, volume image service 346, etc. In some embodiments, volume manager service 130 may maintain user block volumes for a retention period rather than creating backups. The retention period may reduce latency when a user requests a new secure shell instance by reattaching user block volumes without requiring the creation of a backup, or by restoring user data from block storage to a newly configured block volume.

[0056] In some embodiments, the volume manager service 130 may create the backup using the object storage service 344 so that the backup is formatted for transfer to an object storage system. In contrast to block volume storage, object storage may potentially reduce IaaS system overhead and reduce the resources required to maintain user block volumes by allowing data to be stored in a data store as chunk objects. In some embodiments, the object storage service 344 may allow the backup to store user data for a lower cost in terms of system resources, despite introducing additional data format conversion operations that may introduce latency into the secure shell session restoration process.

[0057] In some embodiments, the volume manager service 130 may create backups by creating a volume image (e.g., using the volume image service 346). A volume image (e.g., a disk image of a block volume) may include the contents and structure of a volume as a computer file. A volume image may be created by generating a copy of the original block volume along with a manifest of blocks that preserves the structure of the original block volume. In some cases, a volume image may be compressed relative to the block volume to potentially reduce the size of the image to the size of the data stored in the block volume (e.g., omitting excess or unused reserved capacity within the block volume). A volume image allows user data to be restored from a single file rather than a restore procedure that involves provisioning multiple block and / or chunk objects. Thus, it may enable system restore operations with potentially reduced latency and reduced resource demands due at least in part to not maintaining block volumes for user data between secure shell sessions.

[0058] 4 illustrates an example technique 400 for restoring block volumes for a restored secure shell instance, according to one or more embodiments. One or more subsystems of system 100 of FIG. 1 (e.g., session manager service 120, volume manager service 130, and instance manager service 150) may perform operations associated with terminating and / or restoring a secure shell instance (e.g., secure shell instance 250 of FIG. 2). Restoring a secure shell instance may include creating a new secure shell instance with an empty block volume and provisioning the empty block volume with backup data (also referred to as "hydrating" the empty block volume).

[0059] In some embodiments, session manager service 120 may receive a request from user device 110 to connect to a secure shell instance (e.g., operation 402), as described in more detail above with reference to Figure 1. In the restore operation of technique 400, the user request may include a request for session manager service 120 to reconnect to a secure shell instance after requesting an initial configuration and / or termination operation (e.g., technique 300 of Figure 3) rather than connecting to a secure shell instance.

[0060] In some embodiments, session manager service 120 may request a volume manager service to reserve a block volume 140 for attachment to a secure shell instance, as described in further detail above with reference to Figure 2. Instead of searching for a user block volume, as previously described, volume manager service 130 may reserve an empty block volume 240 (e.g., operation 404). The empty block volume 240 may be pre-configured for attachment to a secure shell instance, for example, as part of a pool of block volumes.

[0061] The volume manager service 130 may provision the backup user data 430 on an empty block volume 240 (e.g., operation 406). As described in more detail with reference to FIG. 2, the backup user data 430 may be stored in a number of different data formats, including, but not limited to, block storage and object storage, for example, as a disk image (e.g., as a single file), or may be distributed across multiple data subunits (e.g., blocks, objects, etc.). In some embodiments, the volume manager service 130 may request that a reserved empty block volume be provisioned with the backup user data 430 using a backup service (e.g., backup service 340 of FIG. 3). In some embodiments, the backup service may facilitate transfer of the backup user data 430 (e.g., blocks) via a distributed storage system (e.g., a cloud storage system). In some embodiments, provisioning the empty block volume 240 may include reformatting the backup user data 430 from object data to block data (e.g., if the backup is stored as object data), as described in more detail above with reference to FIG. 3.

[0062] In some embodiments, the volume manager service 130 may provide a data center (e.g., The volume manager service 130 may then identify a datacenter identifier (e.g., an AD) (e.g., operation 408). Identifying the datacenter identifier may include verifying the hardware address of an empty block volume 240 within the IaaS infrastructure (e.g., a datacenter), which may identify the system where the backup user data 430 is stored. Once identified, the volume manager service 130 may return the datacenter identifier to the session manager service 120 (e.g., operation 410). The session manager service 120 may use and provide the datacenter identifier to an instance manager service (e.g., instance manager service 150 of FIG. 1 ) as part of configuring and creating a secure shell instance, as described in more detail above with reference to FIGS. 1-2.

[0063] 5 shows a sequence diagram illustrating an exemplary data flow 500 in which a block volume containing user data is released, according to one or more embodiments. A user of user device 110 requests to connect to a secure shell instance, and session manager service 120 requests volume manager service 130 to reserve the volume. After session manager service 120 determines to terminate the secure shell instance, it requests volume manager service 130 to release the block volume.

[0064] In data flow 500, user device 110 (which may be an example of user device 110 of FIG. 1) may submit a request to connect to a secure shell instance, which may be received by session manager service 120, as described in more detail with reference to FIGS. 1-2. Upon receiving the request, session manager service 120 may configure the shell instance, as described in more detail with reference to the figures above. Configuring the shell instance may include multiple operations, including, but not limited to, reserving a volume, allocating an instance from several available instances that are created for the purpose of configuring the secure shell instance, and installing a configuration file on the allocated instance.

[0065] 2 and 4, reserving a volume may include one or more operations including requesting volume manager service 130 to reserve a block volume. For example, reserving a block volume may include searching existing block volumes for a user block volume (e.g., user block volume 230 of FIG. 2) that contains user data and returning a data center identifier of the user block volume to session manager service 120. In some cases, such as when the user block volume is not found by volume manager service 130, the volume manager service may identify and return a data center identifier (e.g., AD identifier) of the reserved block volume (e.g., empty block volume 240 of FIG. 2).

[0066] Configuring the shell instance may include session manager service 120 receiving a shell instance identifier (e.g., an IaaS resource identifier) from an instance manager service. As described in more detail with reference to FIGS. 1-2 , the instance may be reserved from a pool of at least partially pre-configured instances to which the reserved volume may be attached. Attaching the reserved volume may include, for example, one or more operations requesting volume manager service 130 to attach the volume. In response to the request by session manager service 120, volume manager service 130 may attach the volume and return a confirmation to session manager service 120.

[0067] When session manager service 120 determines that the secure shell instance is idle and / or the user of user device 110 requests to terminate the secure shell instance, session manager service 120 may request volume manager service 130 to release the block volume, as described in more detail with reference to FIG. 3. As part of releasing the block volume, the volume manager service may create a backup of the user data contained in the block volume. The volume manager service may receive a backup identifier from backup service 340 as part of the backup operation. In some embodiments, the backup operation may be performed by the backup service, as described in more detail with reference to FIG. 3.

[0068] Releasing a block volume may include removing user data from the block volume (e.g., reformatting) and returning the storage capacity to availability for future configuration of block volumes. As part of releasing a block volume, volume manager service 130 may confirm that the block volume has been released to session manager service 120.

[0069] 6 shows a sequence diagram illustrating an example data flow 600 by which user data is persisted to a restored secure shell instance, according to one or more embodiments. A user of a user device 110 may request a connection and / or reconnection to a secure shell instance, and the session manager service 120 may request the volume manager service 130 to restore the user volume. The volume manager service 130 may coordinate with the backup service 340 to provision the restoration volume.

[0070] In data flow 600, session manager service 120 may receive a connection request from user device 110. As described in more detail with reference to FIG. 3, when user device 110 was previously connected to a secure shell instance and data from that instance is stored in a backup, session manager service 120 may send a restore request to volume manager service 130. The restore request may include identifying information describing the user of user device 110 and / or backup user data (e.g., user identifier, username, last session identifier, backup identifier, etc.).

[0071] Instead of searching for an existing user block volume (e.g., user block volume 230 in FIG. 2), volume manager service 130 may reserve an empty block volume (e.g., empty block volume 240 in FIG. 2). In contrast to the operation described with reference to FIG. 2, volume manager service 130 may provide a backup identifier to backup service 340 as part of the provisioning process for restoring user backup data (e.g., user backup data 430 in FIG. 4).

[0072] Provisioning the restore volume may include transferring the backup data from the backup storage system to an empty block volume by the backup service 340. This may include restoring the structure of the data to recreate the user block volume. The volume manager service 130 may provide the data center identifier of the empty block volume to the backup service 340, and the backup service may provision the backup data into the empty volume. In some embodiments, the volume manager service 130 may The provisioning operation may be performed by providing the backup data identifier to the backup service 340, receiving the corresponding user backup data, and restoring the data to the reserved block volume.

[0073] Once provisioned, volume manager service 130 may provide a recovery volume identifier to session manager service 120, which may correspond to the datacenter identifier of the empty block volume. Using this identifier, session manager service 120 may perform operations such as those described in more detail with reference to FIG. 2, including, but not limited to, reserving an instance from a pool of pre-configured instances and requesting volume manager service 130 to attach the recovery volume to the reserved instance. Volume manager service 130 may optionally confirm the attachment of the recovery volume by returning an acknowledgement to session manager service 120.

[0074] 7 illustrates an exemplary flow for releasing a block volume for a Secure Shell instance, according to one or more embodiments. The operations of the flow may be implemented as hardware circuits and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as volume manager service 130 of FIG. 1. When implemented, the instructions represent modules including circuits or code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform certain operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0075] In one example, flow 700 includes an operation 702 in which a computer system receives a request to reserve a block volume. As described in more detail with reference to FIG. 2, the request may be generated by a session manager service (e.g., session manager service 120 of FIG. 1) in response to a request from a user device (e.g., user device 110 of FIG. 1) to connect to a secure shell instance (e.g., secure shell instance 250 of FIG. 2). The request may include a user identifier (e.g., username, login ID, session ID, network address, etc.) associated with user device 110.

[0076] In one example, flow 700 includes operation 704 in which a computer system reserves a block volume. Reserving the block volume may include the volume manager service verifying whether a user block volume (e.g., user block volume 230 of FIG. 2) is maintained by the block volume storage system of the IaaS system to which the volume manager service is connected, as described in more detail below with reference to FIG. 8. If not, the volume manager service may reserve an empty block volume (e.g., empty block volume 240 of FIG. 2).

[0077] In one example, flow 700 includes operation 706 in which a computer system identifies a data center identifier for the block volume. The data center identifier may describe the IaaS storage resources (e.g., networked storage infrastructure) that maintain the block volume (e.g., block volume 140 of FIG. 1 ) and may be specific to a single data center (e.g., a facility in a particular geographic region) of the IaaS system.

[0078] In one example, flow 700 includes operation 708, in which the computer system returns a data center identifier for the block volume. The volume manager system may provide the data center identifier for the reserved block volume identified as part of operation 708 to a session manager service. The session manager service may then provide the data center identifier for the reserved block volume to an instance manager service (e.g., instance manager service 150 of FIG. 1) as part of configuring a secure shell instance, as described in more detail with reference to FIGS. 1-2.

[0079] In one example, flow 700 includes an operation 710 in which a computer system attaches a block volume. The volume manager service may attach the reserved block volume to an instance allocated from a pool of partially pre-configured instances (e.g., instance 180 of FIG. 1 ) selected by the instance manager service for use in creating the secure shell instance.

[0080] In one example, flow 700 includes an operation 712 in which the computer system receives an instruction to release the block volume. The volume manager service may receive the request from the session manager service, as described in more detail with reference to FIG. 3, after the session manager service has confirmed an idle time for the secure shell instance that exceeds the lifespan of the secure shell instance. In some embodiments, a user of a user device may request to terminate the secure shell instance. The session manager service may request the volume manager service to release the reserved block volume as one of multiple operations associated with terminating the secure shell instance, e.g., disconnecting the secure shell instance from Docker (e.g., as a Docker container), deleting the instance, and disassociating the compute resources from the block volume, to potentially protect core IaaS resources and user data.

[0081] In some embodiments, a retention time may follow secure shell termination during which user block volume data may be maintained and / or retained. Retaining user block volume data may reduce the latency associated with initializing a new secure shell instance, for example, by attaching the user block volume data to the new secure shell instance without restoring the user data from a backup such as object storage. In some embodiments, the retention time may include hours or days, e.g., 12 hours, 24 hours, 36 hours, 48 hours, 72 hours, etc. In some embodiments, the retention time may be calculated from the end of an idle time, such that a secure shell instance timeout may trigger instance termination, but user block volumes may be retained until the retention period (e.g., 72 hours) has elapsed after the idle timeout.

[0082] In one example, flow 700 includes operation 714, in which the computer system creates a backup of the block volume. The volume manager service may request the creation of the backup as part of releasing the block volume. The backup may be created in different formats, including, but not limited to, block storage, object storage, and / or a volume image, as described in further detail with reference to FIG. 3. The backup data (e.g., user backup data 430 of FIG. 4) may be created by a backup service (e.g., backup service 340 of FIG. 3), which may be an IaaS core service with which the volume manager service communicates.

[0083] In one example, flow 700 includes operation 716, in which the computer system releases the block volume. The volume manager service may release the block volume, at least in part, by reformatting the volume (e.g., clearing data stored in the block volume) and disassociating storage resources previously identified with the block volume as available for other uses. Releasing the block volume, as opposed to maintaining a user block volume during a retention period, such as after terminating a secure shell instance, may enable the IaaS system described herein to operate with reduced computational overhead by potentially reducing resources dedicated to maintaining a user block volume during periods when the user is not connected to the secure shell instance.

[0084] 8 illustrates an exemplary flow for reserving a block volume for a Secure Shell instance, according to one or more embodiments. The operations of the flow may be implemented as hardware circuits and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as volume manager service 130 of FIG. 1. When implemented, the instructions represent modules including circuits or code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform certain operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0085] In one example, flow 800 includes one or more operations that may be performed by a volume manager service in response to receiving a request to reserve a block volume (e.g., operation 702 of FIG. 7). Accordingly, flow 800 includes operation 702, whereby the volume manager service receives a request to reserve a block volume from a session manager service (e.g., session manager service 120 of FIG. 1).

[0086] In one example, flow 800 includes operation 804 in which the computer system determines whether a registered block volume is allocated. The registered block volume may be a block volume associated with a user of a user device (e.g., user device 110 of FIG. 1 ). Accordingly, operation 804 may include the volume manager service verifying whether the user block volume (e.g., user block volume 230 of FIG. 2 ) is maintained by a block volume storage system of the IaaS system to which the volume manager service is connected.

[0087] In one example, flow 800 includes operation 806, in which the computer system reserves the registered block volume in response to the registered block volume being allocated. If operation 804 returns a data center identifier for the user block volume, the volume manager service may reserve the user block volume for attachment to the secure shell instance.

[0088] In one example, flow 800 includes operation 808, in which the computer system reserves an empty volume in response to a registered block volume being unallocated. In contrast to operation 806, when a user block volume is unavailable, the volume manager service may reserve an empty block volume (e.g., empty block volume 240 of FIG. 2). The empty block volume may be allocated to a secure compute instance. The device may be at least partially pre-configured with one or more settings and / or configuration parameters for attachment to the device.

[0089] FIG. 9 illustrates an example flow 900 for restoring a block volume for a Secure Shell instance, according to one or more embodiments. The operations of the flow may be implemented as hardware circuits and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as volume manager service 130 of FIG. 1 . When implemented, the instructions represent modules including circuits or code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform particular operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0090] In one example, flow 900 includes an operation 902 in which a computer system receives a request to restore a block volume. As described in more detail with reference to FIG. 4, a volume manager service may receive a request to restore a block volume from a session manager service (e.g., session manager service 120 of FIG. 1) after a user of a user device (e.g., user device 110 of FIG. 1) requests to reconnect to a secure shell instance (e.g., secure shell instance 250 of FIG. 2). In some embodiments, the request may include a user identifier, which may cause the volume manager service to perform one or more backup restore operations described below.

[0091] In one example, flow 900 includes operation 904, in which the computer system reserves an empty block volume from a pool of empty volumes. In contrast to the operations described with reference to flow 800 of Figure 8, the volume manager service may fulfill the restore request of operation 902, at least in part, by reserving an empty block volume (e.g., empty block volume 240 of Figure 2) without verifying whether a user block volume is maintained by the IaaS data storage system. For example, as described in more detail with reference to Figure 7, when a backup is created, the volume manager service may reserve an empty block volume without performing the operations described with reference to Figure 8.

[0092] Alternatively, the volume manager system may implement the operation described with reference to Figure 8 by checking whether the user block volume is maintained by an IaaS data storage system. In this way, the volume manager service may return the user block volume data center identifier rather than reserving an empty block volume.

[0093] In one example, flow 900 includes an operation 906 in which a computer system requests user backup data. A volume manager service may request that the user data backup (e.g., user data backup 430 of FIG. 4 ) be transferred to the reserved empty block volume in operation 904. The request may be made from a backup service (e.g., backup service 340 of FIG. 3 ), which may be a core IaaS service that facilitates data backup and restore operations.

[0094] In one example, flow 900 includes an operation 908 in which a computer system provisions an empty block volume. As described in more detail with reference to FIG. 4, provisioning an empty block volume may be performed during a backup operation (e.g., 2. The method may include an operation to recreate the structure of a user block volume (eg, user block volume 230 of FIG. 2) that precedes operation 714).

[0095] In one example, flow 900 includes operation 910, in which a computer system identifies a data center identifier for the empty block volume. The volume manager service may identify the data center identifier for the empty block volume as the data center identifier for the recovery volume so that the recovery volume may be attached to a Secure Shell instance. The data center identifier may be a unique identifier corresponding to a data center (e.g., an IaaS infrastructure) in which the empty block volume is maintained.

[0096] In one example, flow 900 includes operation 912 in which the computer system returns a data center identifier for the restoration volume. The data center identifier may be returned by the volume manager service to the session manager service for configuration of the secure shell instance, as described in more detail above with reference to FIGS. 1-2.

[0097] Techniques for Securing Cloud Shells with Signed Nonce Cloud-based platforms provide users with scalable and flexible computing resources. Such cloud-based platforms, also known as Infrastructure as a Service (IaaS), may offer an entire suite of cloud solutions around a customer's data, such as solutions for authoring transformations, loading data, and presenting data. Users of IaaS resources may request the creation of a secure terminal within a secure shell instance (e.g., using two-way encryption over a WebSocket Secure or WSS connection) so that operations and data transfers can be performed securely.

[0098] In some embodiments, a shell instance may be a dedicated compute instance that may run a Docker container (e.g., a host) and may allow a user device to run a terminal on that Docker container. A user device may be assigned to a single host but may create multiple active terminals on that host. A shell instance may be terminated after a period of inactivity. The instance may run a host, which may then run a secure shell (e.g., a terminal). In some embodiments, the instance and / or host may also be terminated when a terminal has not been active on the host for a period of time.

[0099] In some embodiments, an instance agent may run on the assigned instance and receive WebSocket traffic and process that traffic. The instance agent may handle sending the input and output to a secure shell running on the host. The agent may be an HTTP server that may be configured to redirect the agent to a terminal (e.g., a secure shell running on a Docker container) to create a terminal within the container. In some embodiments, the agent may identify an updated version of the Docker container, start the Docker container, and create a terminal within the container. In some embodiments, the agent may further customize the Docker container to include secure shell configuration information and may run a terminal within the Docker container at least in part by passing in certain environment variables.

[0100] In some embodiments, the session manager service may provide command line access to a user's resources from a browser. The session manager service may provide several available compute instances that may be allocated and / or specialized to support a particular user account. Providing a secure shell service (e.g., by creating one or more compute instances configured with default parameters before receiving a secure shell request) may enable the session manager service to improve system response latency (e.g., by creating and specializing the instances within 5 seconds, 10 seconds, 30 seconds, 60 seconds, etc.). The session manager service may also provide a web-based terminal that may allow users to use IaaS infrastructure resources (e.g., via proprietary and / or other Unix commands) on the specialized instances through a secure connection that is verified over multiple operations before final approval.

[0101] In some embodiments, the techniques described herein may be incorporated as computer-executable instructions into a software developer kit (SDK) that may be used by web-based terminals to create and access these resources. In this manner, the SDK may also be used by other providers to implement secure web-based terminals. Furthermore, the techniques described herein may enable a user device to connect to a secure shell operating one or more terminals with improved security and latency. For example, by selecting and configuring a secure shell instance from multiple available instances rather than creating a new instance upon a request to securely connect to the secure shell, a session manager may potentially improve system latency introduced by pre-configuring the instance.

[0102] Furthermore, implementing one or more techniques for securing one or more terminals may improve the operation and performance of the systems described herein. For example, providing a nonce token that may be signed by both the session manager service and the user device, along with a signature-checking operation (e.g., implemented by a router facilitating connection of the user device to the secure shell instance), may provide improved security and may prevent unauthorized access to data and / or IaaS resources via a terminal operating on the secure shell instance. Furthermore, implementing a single-use protocol in which the validity of a nonce token may be determined in relation to a database of unused nonce tokens may prevent the reuse of nonce tokens. In addition, a multi-step security protocol may also provide additional user authentication and resource authorization protection, which may enable the session manager service to prevent the reuse of login tokens (e.g., tokens generated by the identity authorization service after authenticating the user device) by unauthorized and / or unauthenticated user devices. Additionally, configuring a secure shell within a Docker container system may improve security by isolating data related to the secure shell, thereby potentially reducing the exposure of external data to compromise.

[0103] FIG. 10 illustrates an exemplary system 1000 for managing a secure shell instance, according to one or more embodiments. In some embodiments, the system 1000 may allow a user to securely connect to a compute instance (e.g., a virtual machine or “VM” or a Docker container). The secure access may allow the user to connect to distributed computing system resources (e.g., Infrastructure as a Service or “IaaS”), including, but not limited to, distributed storage, compute cores, etc., via an encrypted connection (e.g., https and / or WebSocket Secure “WSS”) for real-time data transfer with the VMs of the IaaS system. In some embodiments, the user device 1010 may generate a signed request for a secure shell instance and send the signed request to a session manager service 1020. Session Manager Service 1020 may perform actions as part of fulfilling the signed request, validating the user device 1010, and configuring a secure shell instance.

[0104] In some embodiments, the user device 1010 may generate the signed request using a user interface, including, but not limited to, a graphical user interface console or a command line interface (CLI). The user interface includes an identity authorization service, which may generate a user public / private key pair. In some cases, the user public / private key pair may be a temporary key pair generated, for example, upon session initialization, upon generating a request for a secure VM connection, etc. The user device 1010 may generate the signed request using the private key of the user public / private key pair.

[0105] In some embodiments, the session manager service 1020 may implement one or more authorization steps as part of managing and provisioning a secure shell instance. Authorization may include, for example, receiving a signed request (e.g., as a step to verify the identity of the user device 1010) and verifying the signed request by requesting a public key (e.g., from an authorization service) and using the key to verify the signature of the signed request. Additionally or alternatively, the public key may be included in a login token provided by the authorization service, as described in more detail below with reference to FIG. 29.

[0106] In some embodiments, the session manager service 1020 may fulfill the signed request, at least in part, by reserving and configuring a secure shell instance. In some cases, the session manager service 1020 may communicate with the volume manager service 1030 to reserve a block volume 1040. The volume manager service 1030 may return a domain identifier for the block volume 1040 to the session manager service 1020. In some embodiments, the domain identifier may describe one or more data centers within a geographic region (e.g., an availability domain, or "AD") of the reserved block volume 1040.

[0107] In some embodiments, the session manager service 1020 may provide the instance manager service 1050 with the domain identifier of the block volume 1040 (e.g., the AD of the reserved block volume). The instance manager service 1050 may allocate a compute instance in the AD provided by the volume manager service. The instance manager service 1050 may provide instance identifier information (e.g., a cloud infrastructure ID) for the allocated instance to the session manager service 1020. The allocation of compute instances may be done per user and / or per compartment (where a compartment is a logical container that controls access to cloud system resources and may include subcompartments). For example, the session manager service 1020 may allocate separate instances to users in different compartments. In contrast, the session manager service 1020 may allocate a single compute instance for multiple containers (where a container is a packaged software application that may include application code, runtime, system tools, system libraries, and configuration) such that the separate containers share the same compute instance, one container per compartment.

[0108] In some embodiments, the session manager service 1020 provides the instance identifier to the user device 1010 along with the router address of the router 1060. The router 1060 may be configured to connect the user device to the secure shell instance (e.g., via a multiplexed WebSocket connection), as described in more detail below. Additionally, the router may also be configured to validate the user device 1010 and the session manager service 1020 as part of securely connecting the user device 1010 to the secure shell instance, as described below.

[0109] In some embodiments, the session manager service 1020 may generate a nonce token as part of authorizing and validating a secure connection of the user device 1010 to a secure shell instance. In some embodiments, the nonce token may be a web token (e.g., a JavaScript Object Notation "json" web token or "jwt" token) that contains information including, but not limited to, a header, a validity period (e.g., minutes before expiration), a key, and / or a random or pseudo-random string (e.g., an alphanumeric sequence of a set length, a random number, or a pseudo-random number, etc.). In some cases, the nonce token is generated and provided to the user device 1010 along with an instance identifier and a router address.

[0110] In some embodiments, the session manager service 1020 may store the nonce token in a nonce and identifier store 1070. The nonce and identifier store 1070 may be a distributed data store (e.g., cloud storage) that stores nonstables, as described in more detail below with reference to FIG. 13, which may enable the session manager service 1020 to further secure a user device's access to a secure shell instance, for example, by tracking the nonce token and ensuring that the nonce token is valid for a single request from the user device 1010. Similarly, the nonce and identifier store 1070 may also store a login token provided by an authorization service, including the user public key of a user key pair, which may be used to validate the user device 1010 during fulfillment of a user request, as described in more detail below with reference to FIGS. 11, 14, and 16.

[0111] As part of configuring a secure shell instance, the session manager service 1020 may select and configure an existing instance from a pool of available instances 1080, as described in more detail with reference to the following figures. In some cases, the session manager service may install a configuration file and a delegation token on the selected instance. The configuration may include parameter information, including, but not limited to, an instance identifier, a domain identifier, request details (e.g., resource allocation, compartment, tenancy), etc. The delegation token may allow the user device 1010 to access IaaS system resources without additional authorization at the instance level.

[0112] In some embodiments, the configuration parameters installed by the session manager service 1020 may be stored in the instance configuration store 1090. The instance configuration store 1090 may allow a new secure shell instance to be restored and / or reconfigured with the requested parameters following termination of the secure shell instance. In some embodiments, the secure shell instance will be terminated when the user is finished using the secure shell instance. In some embodiments, the session manager service 1020 may instruct the instance manager service 1050 to terminate the secure shell instance based on a period of agent inactivity (e.g., idle time) and / or a period of activity through the router 1060. The idle time may be part of the configuration parameters. In some embodiments, a user of the user device 1010 may request that the secure shell instance be terminated, which may be accomplished by the session manager service 1020.

[0113] As described above, the exemplary system 1000 may provide improved security and stability of an IaaS system by allowing at least user devices to connect to a secure shell instance from a console and / or command line interface. For example, using single-use nonce tokens and instances may potentially involve the risk of breakout (software accessing data and / or resources outside of authorized limits). The single-use nonce token may be signed, for example, by the user device's private key, which may prevent another user from accessing the secure shell instance. As another example, single-use instances may reduce the potential impact of a breakout from a container by replacing the instance after it is no longer in use, rather than reusing the instance, which could potentially compromise a later user device using the same instance.

[0114] 11 illustrates an example system 1100 for managing secure shell sessions in accordance with one or more embodiments. With reference to the system described in FIG. 10 (e.g., example system 100), example system 1100 may include one or more of the components (e.g., volume manager service 130, instance manager service 150, instance 180, etc., of FIG. 10). In some embodiments, example system 1100 may implement one or more authorization and security protocols as part of providing a secure connection between a user device and a secure shell instance.

[0115] In some embodiments, session manager service 120 may receive a signed request from user device 110 (e.g., act 1102), or the signed request may be generated by user device 110. In some embodiments, a user may request a secure shell via a command line interface (CLI) and / or a graphical user interface (GUI), also referred to as a “console” interface. In some cases, system 1100 includes a GUI / CLI login service 1120 that may facilitate communication of identity and authorization information with session manager service 120. For example, a secure shell request may be signed by a private key generated by GUI / CLI login service 1120 as part of a public / private key pair associated with a user session. For example, user login and / or identity verification may include generating a temporary public / private key pair that may be used to sign the secure shell request with the private key. The public key may be provided to an authorization service 1130 as part of authorizing access for the user device 110 and generating a login token (e.g., an access token), which may be provided to a session manager service 120 to authorize the signed request (e.g., operation 1104).

[0116] In some embodiments, authorization service 1130 may perform identity authorization for user devices based on username / password account details to authorize access to specific IaaS resources and / or hierarchical resource layers (e.g., a root compartment including subcompartments associated with IaaS resources). Authorization service 1130 may communicate directly with GUI / CLI login service 1120 during the initial login / authorization step, from which GUI / CLI login service 1120 may provide a login token to session manager service 120. As described in more detail below with reference to Figures 14 and 16, session manager service 120 may perform additional operations (e.g., operation 1104) as part of authorizing access to the secure shell.

[0117] In some embodiments, session manager service 120 may reserve a shell instance for use in creating secure shell instance 1140 (e.g., act 1106). As described in more detail below with reference to FIGS. 12-4, reserving a shell instance may include one or more acts including, but not limited to, reserving a volume, assigning an instance to the reserved volume, and configuring the assigned instance. Session manager service 120 may receive a shell instance identifier as part of reserving the shell instance, and may provide information including, but not limited to, the shell instance identifier, a user identifier associated with user device 110, and an expiration time (e.g., validity period) as part of requesting a delegation token from authorization service 1130 (e.g., act 1108).

[0118] The authorization service 1130 may generate a delegation token and provide it to the session manager service 120 (e.g., act 1110) as a way to enable the user device 110 to securely connect to the secure shell instance 1140. In some embodiments, the session manager service 120 may configure the reserved shell instance by installing the delegation token received from the authorization service (e.g., act 1112). As described in more detail with reference to FIG. 13 , configuring the secure shell instance 1140 may include implementing the configuration of the instance (e.g., installing a configuration file that includes one or more aspects of the signed request).

[0119] Following receipt of the delegation token from authorization service 1130, session manager service 120 may provide the secure shell token to GUI / CLI login service 1120 (e.g., operation 1114). As described in more detail with reference to the following paragraphs, additional validation and access control operations may be implemented by session manager service 120, including, but not limited to, generating, signing, and / or storing a nonce token. In some embodiments, the secure shell token may include additional access control elements and may be associated with metadata that includes the delegation token.

[0120] In some embodiments, session manager service 120 may also provide the shell instance identifier to secure shell router 1150 (e.g., at operation 1116). In some embodiments, secure shell router 1150 may be an example of router 160 of FIG. 10. Secure shell router 1150 may store the shell instance identifier and may use the secure shell identifier as part of validating user device 110 during connection to secure shell instance 1140, as described in more detail below with reference to FIG. 12.

[0121] 12 illustrates an example system 1200 for connecting a user device to a secure shell instance, according to one or more embodiments. Similar to the technique described with reference to FIG. 11, session manager service 120 may facilitate connection of user device 110 to secure shell router 1150 as part of connecting to secure shell instance 1140.

[0122] In some embodiments, the session manager service 120 may include, with reference to FIG. As will be described in more detail, a signed request may be received from user device 110 to create a secure shell instance (e.g., via GUI / CLI login service 1120 of FIG. 11 ). The request may include a request to have session manager service 120 create a host for the secure shell instance (e.g., operation 1202). The host may reference a cloud resource container and / or volume implemented in IaaS resources. The request may include security and authorization information, as described with reference to FIG. 11 , and thus the operations and elements of system 1200 may include one or more elements and / or operations described above (e.g., authorization service 1130 of FIG. 11 generating a delegation token).

[0123] In some embodiments, session manager service 120 may configure the host for a secure shell instance (e.g., operation 1204). One or more configuration operations involved in configuring the host are described in more detail below with reference to FIG. 13. In some embodiments, session manager service 120 may reserve and allocate instances using one or more manager services 1230, including, but not limited to, volume manager service 130 and instance manager service 150, as described in more detail above with reference to FIG. 10.

[0124] As part of creating secure access to the secure shell instance 1140 of the user device 110, the session manager service 120 may generate and provide to the user device 110 (e.g., operation 1206) a nonce token, a shell identifier, and a router address. As described in more detail with reference to FIG. 10, the nonce token may include a web token (e.g., a JWT token) that may include a random string having a predetermined number of letters and / or numbers (e.g., an eight-character string of letters and numbers). The shell identifier may be included in the secure shell token described with reference to FIG. 11. The router address may identify the secure shell router 1150 and may be used by the user device to establish a secure connection (e.g., a WebSocket Secure, or "WSS," connection). ) to request a connection to the secure shell router 1150.

[0125] In some embodiments, session manager service 120 may sign the nonce token, for example, using the private key of a key pair identified with session manager service 120. As described in more detail with reference to FIG. 14, an additional verification procedure may include verifying a system-signed nonce generated by session manager service 120 signing the nonce token. To do so, session manager service 120 may provide the system-signed nonce along with the shell instance identifier to user device 110 and / or the secure shell router. In some embodiments, once session manager service 120 provides the system-signed nonce to user device 110, user device 110 may sign the system-signed nonce and provide the dual-signed nonce to secure shell router 1150.

[0126] Secure shell router 1150 may receive a connection request from user device 110, which may include a user-signed nonce token (e.g., act 1208). The user-signed nonce token, like the system-signed nonce, may be generated by signing the nonce token with a private key held by user device 110. As described above, the user private key may form part of a key pair (e.g., a temporary public / private key pair) generated by the GIU / CLI login service, and the public key may be provided to session manager service 120 and / or secure shell router 1150.

[0127] As part of authorizing the connection request, the secure shell router 1150 may verify the user and system signatures (e.g., operation 1210). The secure shell router 1150 may validate the nonce token at least in part by checking whether the nonce token has expired (e.g., if the nonce token includes a validity period). The validation may be accomplished by a request from the session manager service 120 (e.g., the session manager service 120 may check whether the nonce is valid and may provide an indication of validity). The secure shell router 1150 may also verify that the nonce token has not been previously used for a connection request, as described in more detail below with reference to FIG. 13.

[0128] In some embodiments, the secure shell router 1150 may verify one or more of the signatures, at least in part, by decrypting the user and system-signed nonce tokens using public keys for the user device 110 and the session manager service 120, respectively. In some embodiments, such as when the user device 110 signs a system-signed nonce token, the secure shell router 1150 may verify the user signature by decrypting the dual-signed nonce token using the user public key and decrypting the system signature using the system public key. Decrypting in this manner may allow the secure shell router 1150 to verify the nonce value and validate the nonce token. In some embodiments, verification may be achieved, for example, by comparing the decrypted nonce tokens to see if they match.

[0129] Following verification of the nonce token and user and system signatures, the secure shell router 1150 may connect the user device 110 to the secure shell instance 1140 (e.g., operation 1212). As described in more detail above with reference to FIG. 10 , the secure shell router 1150 may provide a WebSocket Secure (wss) connection, which may enable interaction (e.g., full-duplex communication) between a web browser (or other client application) and a web server hosting the secure shell instance 1140 via encrypted messages.

[0130] 13 illustrates an exemplary system 1300 for configuring a secure shell instance with a single-use nonce token, according to one or more embodiments. As described in more detail above with reference to FIGS. 11-3, as part of reserving and configuring a shell instance, session manager service 120 may perform one or more operations in coordination with a configuration service of exemplary system 1300.

[0131] In some embodiments, the session manager service may receive a request from the user device to connect to a secure shell (e.g., operation 1302), as described above with respect to authorizing and validating user requests. In response to receiving the user request, the session manager service 120 may coordinate with the volume manager service 130 to reserve a volume (e.g., operation 1304). Reserving a volume may involve steps including, but not limited to, the volume manager service 130 verifying (e.g., operation 1306) whether one or more block volumes are already associated with and / or assigned to the user of the user device 110 (e.g., user block volumes 1330) and available to host the secure shell instance 1140. This may include checking the user identifier (e.g., username or login ID) against a registry of block volumes managed by the volume manager service 130. If the user block volume 1330 is identified, domain identifier information (e.g., resource ID, data center infrastructure locator, etc.) is returned to the session manager service 120. 1140 (eg, act 1308).

[0132] Volume manager service 130 may find that no user block volumes 1330 are available to host secure shell instance 1140. In some embodiments, the volume manager service may reserve an empty block volume 1340, which may include one or more of the block volumes 140 available in a given data center that the user may not yet have allocated. Similarly, volume manager service 130 may provide resource identifier information for session manager service 120 to implement in subsequent operations. For example, session manager service 120 may allocate an instance in a block volume 140 returned by volume manager service 130 (e.g., operation 1310).

[0133] In some embodiments, allocating an instance may include providing a domain identifier to instance manager service 150. As described in more detail with reference to FIG. 10 , instance manager service 150 may select and reserve an existing instance maintained as part of several available instances that may be reconfigured for use as a secure shell instance. Instance manager service 150 may return an instance identifier (e.g., an instance ID) to session manager service 120, which may enable session manager service 120 to identify the selected instance in subsequent operations. In some embodiments, selecting and reserving an existing instance, rather than creating and configuring an instance when fulfilling a connection request, may potentially reduce system latency in processing a connection request.

[0134] The session manager service 120 may configure the selected instance (e.g., act 1312) at least in part by installing a configuration file. The configuration file may identify IaaS resource details (e.g., compartment, root compartment, domain identifier, etc.) and / or usage details to facilitate completion of the user connection request. The delegation token may be generated by an authorization service (e.g., authorization service 1120 of FIG. 11 ), as described in more detail above with reference to FIG. 11 . Installing the delegation token on the secure shell instance 1140 may enable the user device 110 to access IaaS system resources directly through the secure shell instance 1140 without an additional request to the authorization service for each resource and / or request.

[0135] The exemplary system 1300 may include additional validation operations, which are described in more detail with reference to FIG. 12 . For example, the session manager service 120 may generate, sign, and store a nonce token (e.g., a temporary JWT token) in the nonce and identifier store 170 (e.g., operation 1314) as part of implementing a single-use nonce approach as part of the nonce validation protocol. For example, the nonce and identifier store 170 may include a nonce containing a list of nonce tokens (e.g., a nonce “key” sequence that may be used to track whether a nonce is issued and valid) and, for each nonce, associated instance identifier information as a way to attribute the nonce token to the secure shell instance 1140 when performing one or more validation operations, as described in more detail with reference to FIG. 14 below. In some cases, the nonce token may be temporary, so the nonce may include timing information, including, but not limited to, time of issuance, validity period, etc. In this manner, a nonce token is found, its validity is confirmed, and so forth, as part of fulfilling a connection request. In some embodiments, after user device 110 connects to secure shell instance 1140 (e.g., operation 1214 of FIG. 12 ), the corresponding nonce token may be removed from the nonstable in nonce and identifier store 170. In such cases, session manager service 120 may enable the nonce token to be single-use, which may reduce the risk of unauthorized access to secure shell instance 1140 (e.g., by “spoofing” using a valid nonce token).

[0136] 14 illustrates an example technique 1400 for authorizing a user device to connect to a secure shell instance, according to one or more embodiments. In connection with the systems described above, one or more access control operations may be implemented as part of creating a secure connection between the user device 110 and the secure shell instance 1140. The operations described with respect to managing a secure shell session may include one or more of the operations described with reference to the preceding figures, for example, using user ID login controls, delegation tokens, and / or signed nonce tokens with signature verification.

[0137] In some embodiments, session manager service 120 receives a signed request to create a secure shell instance 1140, which is created and signed by user device 110. As described in more detail with reference to FIG. 11 , the request may be received from GUI / CLI login service 1120, which may generate a key pair used by user device 110 to sign the request.

[0138] The session manager service 120 may authenticate the user request using user login or IaaS ID authentication (e.g., operation 1410), as described in more detail with reference to FIG. 11 . For example, the user's identity may be authenticated, at least in part, by an authorization service (e.g., authorization service 1130) approving a username / password in combination with a data center identifier or other IaaS resource access parameters. The authorization service may generate a login token that includes the user public key of the key pair generated by the GUI / CLI login service 1120. The authorization service may sign the login token with the authorization service's private key and then provide the login token to the user device and / or the GUI / CLI login service 1120. In this manner, the session manager service 120 may authenticate both the signed request from the user device 110 and the user identity by requesting the authorization service public key from the authorization service. In some embodiments, the session manager service 120 may also extract the user public key from the login token and use the user public key to verify the signature on the signed request.

[0139] In some embodiments, session manager service 120 may authorize secure shell instance 1140 (e.g., operation 1420). As described in more detail with reference to FIG. 11 , authorizing secure shell instance 1140 may include requesting a delegation token from an authorization service. In some cases, the delegation token may be issued in response to authorizing access to IaaS system resources based at least in part on a combination of a user ID, an instance identifier, and whether the request has expired (e.g., whether a temporary key pair is still valid and / or whether the request itself has expired). Receiving the delegation token may enable session manager service 120 to configure secure shell instance 1140 to access IaaS system resources (e.g., compute resources, core services, storage resources, etc.) without further authentication and / or authorization once a secure connection between secure shell instance 1140 and user device 110 is established.

[0140] In some embodiments, session manager service 120 may generate a nonce token and provide the nonce token and other information to user device 110 and / or GUI / CLI login service 1120. In some embodiments, session manager service 120 provides a system-signed nonce token to secure shell router 1150. In some embodiments, the session manager service provides the system-signed nonce token to user device 110 as part of signature verification (e.g., operation 1430). User device 110 may sign the system-signed nonce to generate a dual-signed nonce. In doing so, session manager service 120 may provide a public key that matches the private key used to sign the system-signed nonce token. Secure shell router 1150 may receive the user-signed nonce token from user device 110 and may verify the signature to authenticate the request. In some embodiments, verifying the signature may include decrypting the dual-signed nonce using the user public key and system public key to verify the user signature and system signature, respectively. Verification may include comparing the decrypted nonce to a system-generated nonce stored, for example, in a database of nonce tokens (e.g., nonce and identifier store 170 of FIG. 10). In some embodiments, verifying the signature may include decrypting the user-signed and system-signed nonce tokens and comparing the nonce strings contained in them to confirm a match.

[0141] In one example, upon connecting to the session manager service 120 and receiving the nonce token, the secure shell router 1140 may extract the expiration from the nonce token. The nonce lifetime may be configurable (e.g., the expiration time may be five minutes or any other number of seconds, minutes, or hours). If the nonce token has expired, the secure shell router 1150 may return an error rather than establishing the secure connection. If the nonce token has not expired, the secure shell router 1150 may verify the nonce token (e.g., by signature verification), and if invalid, the secure shell router 1150 may return the same error. In some embodiments, the secure shell router 1150 may invalidate valid nonce tokens to prevent reuse of the same nonce token. After the three access control operations have successfully completed, the secure shell router 1150 may connect the user device 110 to the secure shell instance 1140 (e.g., via a WSS connection).

[0142] 15 shows a sequence diagram illustrating an example data flow 1500 in which a user device connects to a secure shell instance, according to one or more embodiments. A user of the user device 110 requests to connect to a secure shell instance through a GUI and / or CLI, and the session manager service 120 provides a nonce to the secure shell router 1150, which is used to coordinate IaaS resources, configure the instance, and verify the user device 110.

[0143] In data flow 1500, user device 110 (which may be an example of user device 110 of FIG. 10) may submit a request to connect to a secure shell instance. As described in more detail with reference to FIG. 11, the request may be submitted through a GUI / CLI login service (e.g., GUI / CLI login service 1110 of FIG. 11) and may be received by session manager service 120. The request may be signed with the private key of a public / private key pair generated by the GUI / CLI login service. The key pair may be ephemeral, and the validity of the key pair may serve as one of the verification parameters of the signed request, as described in more detail with reference to FIG. 14 above and FIG. 16 below.

[0144] Upon receiving the signed request, session manager service 120 may configure the shell instance, as described in more detail with reference to the above figures. Configuring the shell instance may include multiple operations, including, but not limited to, reserving a volume, allocating an instance from several available instances created for the purpose of configuring the secure shell instance, and installing a configuration file on the allocated instance, which may include a delegation token. As described in more detail below with reference to FIG. 16, one or more operations may be included to authenticate a user identity and authorize access to IaaS system resources via the secure shell instance.

[0145] Configuring the shell instance may include session manager service 120 receiving a shell instance identifier (e.g., an IaaS resource identifier) from the instance manager service. Using the shell instance identifier, session manager service 120 may generate a nonce token and may receive a router address corresponding to secure shell router 1150 (which may be an example of secure shell router 1150 in FIG. 11). Session manager service 120 may sign the nonce token using the private key of a public / private key pair maintained by session manager service 120. Session manager service 120 may provide the system-signed nonce, shell instance identifier, and router address to user device 110 (e.g., via a GUI / CLI login service), which may enable the user device to address secure shell router 1150 as part of connecting to the secure shell instance. In some embodiments, session manager service 120 may provide an unsigned nonce token to user device 110. In such cases, session manager service 120 may sign the nonce token to generate a system-signed nonce token.

[0146] Upon receiving information from session manager service 120 (e.g., the nonce token, the shell instance identifier, and the router address), user device 110 may sign the nonce token (e.g., using the private key of the key pair used to sign the request). User device 110 may then connect to secure shell router 1150 (e.g., at the router address) and provide the user-signed nonce token and the shell instance identifier. In some embodiments, the user-signed nonce token includes both a user signature and a system signature, thereby enabling signature verification of both user device 110 and session manager service 120 using a single dual-signed nonce token.

[0147] To verify a request received from user device 110, secure shell router 1150 may request a shell identifier and a system-signed nonce associated with the request from session manager service 120. In response, session manager service 120 may provide the shell instance identifier and the system-signed nonce to secure shell router 1150. In some embodiments, secure shell router 1150 may not request the system-signed nonce from session manager service 120, such as when session manager service 120 provides the system-signed nonce to user device 110.

[0148] As will be described in more detail with reference to Figure 14, the secure shell router may check the signature by decrypting the signed nonce token using the user public key and the system public key. Verification may also be performed by the user device 110 and the session manager. The process may include comparing the shell instance identifiers received from both the client and the server service 120.

[0149] Upon verifying the signature, secure shell router 1150 may connect user device 110 to the secure shell instance (e.g., secure shell instance 1140 in FIG. 11 ) over an encrypted connection (e.g., a wss connection). In some embodiments, similar to when session manager service 120 stores the nonce token and the corresponding shell instance identifier in a data store, session manager service 120 or secure shell router 1150 may, for example, verify the signed nonce token and remove the entry for the nonce token from the data store after connecting user device 110 to the secure shell instance.

[0150] 16 shows a sequence diagram illustrating an example data flow 1600 in which a user device connects to a secure shell instance using an authorization service 1130, according to one or more embodiments. The authorization service 1130 may include, but is not limited to, a general user identity authorization service that may be used, for example, to authorize access to IaaS resources by approving login credentials. The involvement of the authorization service 1130 may include one or more preliminary identity verification and access authorization operations, as described in more detail above with reference to FIG. 14.

[0151] In data flow 1600, session manager service 120 receives a signed request from user device 110, as described with reference to the previous figures. Upon receiving the signed request, session manager service 120 may request an authorization service public key from the authorization service. The authorization service public key may be used to decrypt a login token received with the signed request (e.g., the login token may be signed by an authorization service private key paired with the corresponding public key) and identify user identifier information (e.g., username / password combination, request identifier information, etc.). Authorization service 1130 may provide the public key to session manager service 120, which may then request authentication of the user identity using the identifier information from the login token. Authorization service 1130 may verify the user identity.

[0152] Upon receiving authentication of the identity of the user device 110, the session manager service 120 may request a delegation token from the authorization service 1130. As described in more detail with reference to FIG. 11, the delegation token may be used by the session manager service to indicate that the user device is authorized to connect to an IaaS system resource via a secure shell instance configured to fulfill the signed request. Authorizing the user to connect to an IaaS system resource via a secure shell may include providing the IaaS resource information included in the signed request so that the authorization service 1130 may determine whether the user device 110 is authorized to connect to the particular resource being requested.

[0153] Upon authorizing user device 110, authorization service 1130 may generate and provide a delegation token to session manager service 120. Session manager service 120 may install the delegation token on a secure shell instance (e.g., secure shell instance 1140 of FIG. 11 ). Configuring the secure shell instance may include additional and / or alternative operations, as described above.

[0154] As will be described with reference to FIG. 15, the session manager service 120 The session manager service 120 may generate a user-signed nonce token, sign the nonce token using the system private key of the session manager service 120's public / private key pair to generate a signed nonce token, and provide the signed nonce token to the user device 110 along with the shell instance identifier and a router address (e.g., a "router endpoint") corresponding to the secure shell router 1150. As part of the verification process, the user device 110 may sign the system-signed nonce token and send a request (e.g., a request to establish a WebSocket Secure or "wss" connection) to the secure shell router that includes the user-signed nonce token. The user-signed nonce, also signed by the session manager service, may be used by the secure shell router 1150 to verify the request. In some embodiments, as described in more detail with reference to FIG. 15 , the session manager service 120 may send an unsigned nonce to the user device 110 such that both the user-signed nonce and the system-signed nonce are provided to the secure shell router 1150 for verification.

[0155] The secure shell router 1150 may verify the signature as described in more detail above with reference to Figure 15. Upon verifying the system signature and the user signature and authenticating the nonce token and shell instance identifier, the secure shell router may connect the user device to the secure shell instance.

[0156] FIG. 17 illustrates an example flow 1700 for managing a Secure Shell session, according to one or more embodiments. The operations of the flow may be implemented as hardware circuits and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as the session manager service 120 of FIG. 10. When implemented, the instructions represent modules including circuits or code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform particular operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0157] In one example, flow 1700 includes operation 1702 in which a computer system receives a request to connect a user device (e.g., user device 110 of FIG. 10) to a secure shell instance (e.g., secure shell instance 1140 of FIG. 11). As described in more detail with reference to FIGS. 11 and 15, the request may be a signed request generated by the user device and / or a login service (e.g., GUI / CLI login service 1110 of FIG. 11) and provided to a session manager service for fulfillment. The request may be signed with a private key generated by the GUI / CLI login service and used to authenticate the identity of the user device, as described in more detail with reference to FIGS. 11 and 16.

[0158] In one example, flow 1700 includes operation 1704, in which the computer system authorizes the user device to access the secure shell instance. As described in more detail with reference to FIG. 18, authorizing the user device may include one or more operations involving an external authorization service (e.g., authorization service 1130 of FIG. 11). The authorization service may provide authentication of the user (e.g., by verifying a user identifier such as a username / password) and may authorize access to the IaaS resources described in the request.

[0159] In one example, flow 1700 includes operation 1706, in which the computer system creates a secure shell instance described by a shell identifier of the secure shell instance. Configuring. In some embodiments, configuring a secure shell instance may include, but is not limited to, reserving a block volume, allocating the instance to the block volume, and installing a configuration file and a delegation token on the instance. Optionally, reserving the block volume may include checking whether the user device is already associated with a block volume (e.g., user block volume 1330 of FIG. 13 ) or is not yet associated with a block volume, and if not, reserving an empty block volume (e.g., empty block volume 1340 of FIG. 13 ). Optionally, allocating the instance may include selecting an instance from multiple available instances. Maintaining multiple available instances, for example, with one or more default configurations that may be reconfigured by installing a configuration file, may allow the session manager service to respond more quickly (i.e., with lower latency) to requests. In some embodiments, reserving the block volume and allocating the instance may include communicating with a volume manager service (e.g., volume manager service 130 of FIG. 10 ) and an instance manager service (e.g., instance manager service 150 of FIG. 10 ).

[0160] In one example, flow 1700 includes operation 1708, in which a computer system generates a nonce token. The nonce token may be a web token (e.g., a JSON Web Token or a JWT token) that includes one or more types of information. Optionally, the nonce token includes a key sequence that may be used to track whether the nonce is valid for use. For example, the session manager service may store the nonce token in a data store (e.g., nonce and identifier store 1070 of FIG. 10). In some embodiments, the nonce token includes a random sequence of letters and / or numbers (e.g., 17 alphanumeric characters) that may be used to validate requests.

[0161] In one example, flow 1700 includes operation 1710, in which a computer system signs the nonce token to generate a signed nonce token. As described in more detail with reference to Figure 12, the system may sign the nonce token using a private key of a public / private key pair (e.g., asymmetric encryption). In this manner, the signed nonce token may be encrypted upon transmission to a user device (e.g., user device 1010 of Figure 10).

[0162] For example, flow 1700 includes operation 1712, in which the computer system provides the signed nonce token, the shell identifier, and the router address to the user device. As described in more detail with reference to FIG. 15, the user device may send a secure connection request (e.g., a WSS connection request) to a secure shell router (e.g., the secure shell router 1150 of FIG. 11). The user device may sign the nonce token with a private key (e.g., the same key used to sign the request) and may provide the public key paired with the private key to the secure shell router in the router address. The user device may also provide the shell identifier to the secure shell router as part of the connection request. Optionally, the computer system may provide the shell identifier to the secure shell router in the router address as an additional verification parameter implemented by the secure shell router.

[0163] 18 illustrates an example flow 1800 for configuring a Secure Shell instance with a single-use nonce token, according to one or more embodiments. The operations of the flow may be implemented as hardware circuitry and / or computer-readable on a non-transitory computer-readable medium of a computer system, such as the session manager service system 1020 of FIG. 10. The instructions may be stored as computer-readable instructions. When implemented, the instructions represent modules containing circuits or code executable by a processor of a computer system. Execution of such instructions configures the computer system to perform specific operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0164] In one example, flow 1800 begins following operation 1702 of Figure 17, where a computer system receives a request from a user device to create a secure shell instance. Specifically, the computer system (e.g., session manager service 1020 of Figure 10) may perform one or more operations to authenticate and / or authorize the user device from which the request was received, in communication with an authorization service (e.g., authorization service 1130 of Figure 11), as part of enabling the session manager service to proceed with the operations described in Figure 17.

[0165] In one example, flow 1800 includes operation 1804, in which the computer system receives a login token including a user identifier. As described in more detail with reference to FIG. 16 , the session manager service may request the authorization service to authenticate the identity of the user device (e.g., as expressed in the signed request) and authorize the user device's access to the IaaS resources identified in the request. As part of authenticating the user identity, the session manager service may receive a login token from the user device. The login token may include user information (e.g., username / password, login credentials, login session expiration information, etc.) as well as a user public key paired with a user private key used by the user device to sign requests and / or nonce tokens. The login token may be signed by a private key maintained by the authorization service.

[0166] In one example, flow 1800 includes operation 1806 in which the computer system requests a public key from an authorization service. The public key used to sign a login token may be provided. The session manager service may request the public key from the authorization service to decrypt the login token as part of authenticating the user device. For example, the login token may provide user identifier information (e.g., device identifier or session identifier information) used to authenticate the user device.

[0167] In one example, flow 1800 includes operation 1808, in which the computer system authenticates the user device. In some embodiments, the session manager service may extract user identifier information from the login token and compare the user identifier information to information provided with the request.

[0168] In one example, flow 1800 includes operation 1810 in which the computer system requests a delegation token. As described in more detail with reference to FIG. 11 , the delegation token may be generated by an authorization service and provided to a session manager service after a user device is authorized to access an IaaS resource identified in a user request to connect to a secure shell instance. For example, the session manager service may provide user identifier information, instance identifier information, expiration information, etc. based at least in part on which the authorization service may determine whether a delegation token is generated.

[0169] In one example, flow 1800 illustrates a computer system receiving a delegation token. 18. The session manager service may use the delegation token to enable the secure shell router to grant the user device access to IaaS resources without further authorization by the authorization service, e.g., by installing the delegation token on the secure shell instance, e.g., as part of configuring the secure shell instance, as described in more detail above with reference to FIG.

[0170] The following sections describe embodiments of the disclosed implementations: Item 1. A method comprising: receiving, by a session manager service, a request to connect a user device to a secure connection to a secure shell instance; a session manager service authorizing the user device; a session manager service configuring a secure shell instance described by a shell identifier of the secure shell instance; a session manager service generating a nonce token; a session manager service signing the nonce token to generate a signed nonce token; the session manager service providing the signed nonce token, the shell identifier, and the router address to the user device.

[0171] Section 2. Approving a User Device receiving a login token from a user device, the login token including a user identifier; requesting an authorization system public key from an authorization service; authenticating the user device based at least in part on decrypting the login token with the authorization system public key; requesting a delegation token from an authorization service by at least partly providing a user identifier, a resource identifier of a resource identified in the request, and an expiration period for the request; and receiving a delegation token from an authorization service, the authorization service configured to generate the delegation token upon approving access to the resource identified in the request within an expiration period.

[0172] Section 3. Signing a nonce token signing the nonce token using a system private key of a public / private key pair maintained by the Session Manager Service; and providing the system public key of the public / private key pair to the secure shell router at the router address.

[0173] Section 4.Furthermore, storing a nonce token in a data store, the nonce token including a key sequence; and determining whether the nonce token is valid based at least in part on searching a data store on the key sequence; and removing the nonce token from the data store after the secure shell router establishes a secure connection between the user device and the secure shell instance.

[0174] Section 5. Furthermore, 10. The method of claim 1, comprising terminating the secure shell instance after a period of inactivity or after termination of the secure connection by the user device.

[0175] Section 6. Steps to Configure a Secure Shell Instance reserving a block volume; receiving a domain identifier corresponding to a block volume; and allocating an instance to the block volume using the domain identifier, the instance being allocated from a plurality of available instances, and configuring the secure shell instance further comprising: receiving a shell identifier corresponding to the instance; and installing a configuration file on the instance, the configuration file including requested information included in the request.

[0176] Item 7. The method of item 1, wherein the secure shell instance operates the Docker container such that the request includes instructions to execute a terminal on the Docker container.

[0177] Section 8. A computer system comprising: one or more processors; and a memory in communication with the one or more processors, the memory configured to store computer-executable instructions, execution of the computer-executable instructions causing the one or more processors to perform steps, the steps including: receiving, by a session manager service, a request to connect a user device to a secure connection to a secure shell instance; a session manager service authorizing the user device; a session manager service configuring a secure shell instance described by a shell identifier of the secure shell instance; a session manager service generating a nonce token; a session manager service signing the nonce token to generate a signed nonce token; the session manager service providing the signed nonce token, the shell identifier, and the router address to the user device.

[0178] Section 9. Approving User Devices receiving a login token from a user device, the login token including a user identifier; requesting an authorization system public key from an authorization service; authenticating the user device based at least in part on decrypting the login token with the authorization system public key; requesting a delegation token from an authorization service by at least partly providing a user identifier, a resource identifier of a resource identified in the request, and an expiration period for the request; and receiving a delegation token from an authorization service, the authorization service configured to generate the delegation token upon approving access to the resource identified in the request within an expiration period.

[0179] Section 10. Signing a nonce token signing the nonce token using a system private key of a public / private key pair maintained by the Session Manager Service; and providing the system public key of the public / private key pair to the secure shell router at the router address.

[0180] Item 11. The computer-executable instructions, when executed, further cause one or more processors of a computer system to perform steps, said steps including: storing a nonce token in a data store, the nonce token including a key sequence, said step further comprising: determining whether the nonce token is valid based at least in part on searching a data store on the key sequence; and removing the nonce token from the data store after the secure shell router establishes a secure connection between the user device and the secure shell instance.

[0181] Item 12. The computer-executable instructions, when executed, further cause one or more processors of a computer system to perform steps, said steps including: 9. The system of claim 8, including terminating the secure shell instance after a period of inactivity or after termination of the secure connection by the user device.

[0182] Section 13. The steps to configure a Secure Shell instance are: reserving a block volume; receiving a domain identifier corresponding to a block volume; and allocating an instance to the block volume using the domain identifier, the instance being allocated from a plurality of available instances, and configuring the secure shell instance further comprising: receiving a shell identifier corresponding to the instance; and installing a configuration file and a delegation token on the instance, wherein the configuration file includes request information to be included in the request.

[0183] Item 14. The system of item 8, wherein the secure shell instance operates the docker container such that the request includes instructions to execute a terminal on the docker container.

[0184] Item 15. A non-transitory computer-readable storage medium storing computer-executable instructions that, when executed, cause one or more processors of a computer system to perform steps, said steps including: receiving, by a session manager service, a request to connect a user device to a secure connection to a secure shell instance; a session manager service authorizing the user device; a session manager service configuring a secure shell instance described by a shell identifier of the secure shell instance; a session manager service generating a nonce token; a session manager service signing the nonce token to generate a signed nonce token; a session manager service providing the signed nonce token, the shell identifier, and the router address to the user device.

[0185] Section 16. Approving User Devices receiving a login token from a user device, the login token including a user identifier; requesting an authorization system public key from an authorization service; authenticating the user device based at least in part on decrypting the login token with the authorization system public key; requesting a delegation token from an authorization service by at least partly providing a user identifier, a resource identifier of a resource identified in the request, and an expiration period for the request; receiving a delegation token from an authorization service, the authorization service receiving the delegation token from the authorization service; 16. The non-transitory computer-readable storage medium of claim 15, configured to generate a delegation token upon granting access to the resource identified in the request within that time period.

[0186] Section 17. Signing a nonce token signing the nonce token using a system private key of a public / private key pair maintained by the Session Manager Service; and providing the system public key of the public / private key pair to the secure shell router at the router address.

[0187] Item 18. The computer-executable instructions, when executed, further cause one or more processors of a computer system to perform steps, said steps including: storing a nonce token in a data store, the nonce token including a key sequence, said step further comprising: determining whether the nonce token is valid based at least in part on searching a data store on the key sequence; and removing the nonce token from the data store after the secure shell router establishes a secure connection between the user device and the secure shell instance.

[0188] Item 19. The computer-executable instructions, when executed, further cause one or more processors of a computer system to perform steps, said steps including: 16. The non-transitory computer-readable storage medium of claim 15, comprising terminating the secure shell instance after a period of inactivity or after termination of the secure connection by the user device.

[0189] Section 20. The steps to configure a Secure Shell instance are: reserving a block volume; receiving a domain identifier corresponding to a block volume; and allocating an instance to the block volume using the domain identifier, the instance being allocated from a plurality of available instances, and configuring the secure shell instance further comprising: receiving a shell identifier corresponding to the instance; and installing a configuration file on the instance, wherein the configuration file includes the requested information included in the request.

[0190] Techniques for utilizing multiple network interfaces for cloud shells Cloud-based platforms provide users with scalable and flexible computing resources. Such cloud-based platforms, also known as Infrastructure as a Service (IaaS), may offer an entire suite of cloud solutions around a customer's data, for example, solutions for authoring transformations, loading data, and presenting data. Users of IaaS resources can access and use the cloud services (e.g., with two-way encryption over a WebSocket Secure (wss) connection) to operate and It may also be required to create a secure terminal within a secure shell instance (e.g., a virtual machine running on a virtual cloud network (VCN)) so that communication and data transfers can be performed securely.

[0191] Aspects of secure communication may include controlling network traffic to and from a secure shell instance, which may be in communication with multiple instances and may control access to data and compute resources of the IaaS system. The network traffic control may include one or more techniques and / or methods for isolating the secure shell instance from one or more IaaS services (e.g., core cloud services) that may have access to and / or control over the secure shell instance. The network traffic control may include implementing direction restrictions on network communications into and out of the secure shell instance. The direction restrictions may then block some inbound traffic from external systems and block outbound traffic to the IaaS services. Isolating the secure shell instance may include, for example, implementing multiple virtual cloud networks to isolate core IaaS services from the secure shell instance, both being isolated from network communication services.

[0192] As an illustrative example, a user may submit commands to a secure shell instance via a user device (e.g., using a browser graphical user interface and / or a command line interface). The secure shell instance may be configured with a primary virtual network interface card (vNIC), and one or more security rules may define it as ingress only (unidirectional with respect to inbound network traffic to the secure shell instance). The commands may cause the secure shell instance to generate output, which may include instructions to send the output to an external address (e.g., via the Internet). The secure shell instance may send the output through a secondary vNIC rather than the primary vNIC. Like the primary vNIC, the secondary vNIC may be configured with security rules that restrict network traffic through the secondary vNIC as egress only (unidirectional with respect to outbound traffic from the secure shell instance). In this manner, authorized network traffic may arrive at the secure shell instance via the primary vNIC and leave the secure shell instance via the secondary vNIC. Additionally, the secure shell instance may run on a compute isolation VCN that is isolated from both the service VCN and the network isolation VCN, which may run IaaS services and network communication services, respectively.

[0193] Such a configuration may provide improved security for both the Secure Shell instance and the IaaS system as a whole. Improved security may result, in part, because the Secure Shell instance may be limited in its ability to send messages to the Service VCN via the primary vNIC and limited in its ability to receive messages from the external network via the network isolation VCN and secondary vNIC. In this way, unauthorized network traffic from the Internet (or other networks) may not be able to access the Secure Shell instance, and the Secure Shell instance may not be able to access core IaaS resources without authorization.

[0194] FIG. 19 illustrates an example technique 1900 utilizing multiple network interfaces for a secure shell instance, according to one or more embodiments. Controlling the direction of communication between virtual cloud networks may provide improved security for constituent IaaS resources and may limit and / or prevent security risks from reaching core IaaS resources. To that end, the example technique 1900 may include multiple techniques for controlling the flow of system communication using one or more system components, which may be implemented as virtual systems in a distributed computing system (e.g., a cloud network). In some embodiments, the techniques may be implemented to control the origin and / or destination of communications with a secure shell instance 1950, which may be an example of a virtual machine (VM) running on a virtual cloud network (VCN). In some embodiments, the secure shell instance may be configured to communicate with a secure shell instance, as further described below with reference to FIG. 20. As will be described in detail, it communicates with other components of the distributed computing system (eg, routers, subnets, etc.) through one or more virtual network interface cards (vNICs).

[0195] In some embodiments, the example technique 1900 includes receiving a command to perform an operation (e.g., operation 1902). In some embodiments, the command is generated and / or transmitted from a user device 1920. The user device 1920 may include any form of electrical device configured to access a network (e.g., the Internet and / or a private network), such as a personal computer, a digital workstation, a tablet, a smartphone, etc. The command may include any type of instruction generated by a user of the user device 1920 (e.g., via an IaaS provider's browser interface). For example, the command may include a computational task, a storage task (e.g., input / output operations, movement of stored data, data transformations, etc.), a configuration task (e.g., a command to access operating parameters of the secure shell instance 1950), etc. In some embodiments, the user device 1920 may communicate with a system service (e.g., a browser interface and / or a command line interface service) that directs the command to the appropriate subsystem and / or cloud network resources. Such a configuration may provide network isolation and / or improved system security through network isolation. For example, as described in more detail below with reference to FIG. 20, user-originated network traffic may be made identifiable by using a secondary vNIC in a VCN on a tenancy different from that of the IaaS service (e.g., the source IP address may come from a different IP address pool than that of the IaaS service).

[0196] In some embodiments, the command received in operation 1902 is sent to a cloud shell router 1930. The cloud shell router may be a virtual router implemented in a virtual cloud network, as described in more detail below with reference to FIG. 20 . The cloud shell router 1930 may transmit the command (e.g., at operation 1904) toward the appropriate destination (e.g., a secure shell instance 1950), which may be implemented in separate virtual cloud networks. In some embodiments, implementing separate subsystems performing different operations of the example technique 1900 in separate virtual cloud networks may provide improved security for core cloud resources and / or user data. In some embodiments, the cloud shell router 1930 may communicate with the secure shell instance 1950 via a primary virtual network access card 1940 (vNIC). In some embodiments, the primary vNIC 1940 may represent the network interface configuration for the virtual machine on which the secure shell instance 1950 is implemented. Thus, the primary vNIC 1940 may be configured with one or more operational parameters (e.g., a MAC address) along with security rules, which may enable the primary vNIC 1940 to selectively route communications to and from the secure shell instance 1950, as described in more detail below with reference to the figures.

[0197] In some embodiments, secure shell instance 1950 may perform the operation indicated in the command (e.g., operation 1906). As described above, secure shell instance 1950 may be a virtual machine (VM) configured to perform one or more types of operations, including database operations, computational operations, etc. For example, secure shell instance 1950 may execute the command to configure a compartment of a distributed computer system (e.g., to move data stored in one data center to another data center, to send data over a public network to an external server, etc.). The user may modify one or more aspects of the IaaS resources and / or data.

[0198] In some embodiments, secure shell instance 1950 may generate a reply message as a result of performing the operation included in the command (e.g., operation 1908). The reply message may be directed to a user of user device 1920 and / or user device 1920, rather than to a core IaaS service or an external server (e.g., on a public or private network). In some embodiments, the reply message may be generated to provide result information with reference to the operation performed by secure shell instance 1950. For example, secure shell instance 1950 may generate a reply message to indicate that the operation completed successfully, was aborted, failed, was rescheduled, etc. The reply message may include status information and specific data requested as part of the reply message (e.g., check bits, memory locations, etc.).

[0199] In some embodiments, the secure shell instance 1950 may send the reply message to the cloud shell router 1930 (e.g., operation 1910). The secure shell instance 1950 may send the reply message via the primary vNIC 1940. As described in more detail below with reference to FIG. 20 , the primary vNIC 1940 may be configured to send the reply message to the cloud shell router 1930 but reject other types of messages received from the secure shell instance 1950.

[0200] In some embodiments, secure shell instance 1950 may generate an output of the operation (e.g., operation 1912). The output of the operation may include, but is not limited to, communications, data, and / or instructions to an external system communicating with secure shell instance 1950 over a network (e.g., a public network and / or a private network). Secure shell instance 1950 may be instructed to generate an output, for example, when an operation included in a command from user device 1920 includes transferring data over an external network. If transferring data, secure shell instance 1950 may send instructions to a data management service of the IaaS system over the IaaS system's internal network.

[0201] As part of executing the command, for example, when the command is to transfer data or send a message to an external server, secure shell instance 1950 may send a message (e.g., operation 1914) containing the output of the operation to shell subnet 1970. Secure shell instance 1950 may communicate with shell subnet 1970 through secondary vNIC 1960. Similar to primary vNIC 1940, secondary vNIC 1960 may be configured with one or more operational parameters (e.g., a different MAC address) and input / output parameters (e.g., security rules) to control the flow of data and messages to secure shell instance 1940. As described in more detail below with reference to FIG. 20 , secondary vNIC 1960 may be configured to be unidirectional, allowing only outgoing messages from secure shell instance 1950 to shell subnet 1970 (e.g., an egress-only configuration). In some embodiments, a unidirectional, egress-only configuration for secondary vNIC 1960 may allow secure shell instance 1950 to operate with improved security against external risks of intrusion and / or interference by unauthorized access by non-user devices.

[0202] In some embodiments, the shell subnet 1970 may transmit the output of the operation to an external network. The external network 1980 may transmit the secure shell instance 1950 and / or shell subnet 1970 to the external network 1980 (e.g., operation 1916). In some embodiments, the external network 1980 is a public network. In some cases, connecting the secure shell instance 1950 and / or shell subnet 1970 to a public network may introduce a security risk due to the possibility that a malicious system may attempt to access the secure shell instance 1950 and / or core cloud resources. For example, adding the secure shell instance 1950 may provide access to core cloud resources, which may then allow access to user data for multiple users within a cloud service domain. For this reason, the shell subnet 1970 may communicate with the external network 1980 through a network address translation (NAT) gateway, as described in more detail below with reference to FIG. 20 .

[0203] Thus, the exemplary technique 1900 demonstrates how communications between the user device 1920, the secure shell instance 1950, and the external network 1980 can be managed to potentially reduce the risk of security threats posed by connecting the secure shell instance to the external network 1980. In some embodiments, the exemplary technique 1900 provides for one-way transmission of messages for some types of information, while allowing reply messages to be sent from the secure shell instance 1950 back to the user device 1920. Implementing such control may provide improved security for stored user data to which the secure shell instance 1950 has access and may isolate the secure shell instance 1950 from core cloud services.

[0204] 20 illustrates an example system 2000 that utilizes multiple network interfaces to manage communications for a secure shell instance, according to one or more embodiments. The various operations described above with reference to FIG. 19 may be implemented by the example system 2000, which may include one or more additional features to potentially improve the security of the secure shell instance 1950 and core cloud resources.

[0205] In some embodiments, the cloud shell router 1930, the secure shell instance 1950, and the shell subnet 1970 may be implemented as virtual systems within separate virtual cloud networks (VCNs). Furthermore, the separate VCNs may be implemented in multiple root compartments (also referred to as "tenancies"). As shown in FIG. 20 , the cloud shell router 1930 is implemented in a service VCN 2010, and the secure shell instance 1950 is implemented in a compute-isolated VCN 2020, both of which are implemented in a private root compartment 2030. In contrast, the shell subnet 1970 may be implemented in a network-isolated VCN 2040 within the public root compartment 2050. Generally, the private root compartment 2030 and the public root compartment 2050 may constitute different and / or separate logical containers of data and compute resources implemented in an IaaS system, such that system resources in the private root compartment 2030 cannot be accessed by system resources in the public root compartment 2050. The private root compartment 2030 and the public root compartment 2050 may be associated with different, distinguishable blocks of IP addresses, which may enable determining the origin of a message from the IaaS system, such as from the public root compartment 2050 or the private root compartment 2030.

[0206] In some embodiments, the public root compartment 2050 and the configuration system (e.g., network The shell subnet 1970 in the isolated VCN 2040 may be assigned an IP address from a block of IP addresses identified in a user-output operation (e.g., the message of operation 1916 in FIG. 19 ). In contrast, the private root compartment 2030 and configuration systems implemented within the private root compartment (e.g., cloud shell router 1930 in service VCN 2010) may be assigned an IP address from a block of IP addresses identified in an IaaS system communication operation (e.g., communication with an external network, such as external network 1980). Using a separate block of IP addresses whose origin can be attributed to either the IaaS system itself or a user of the IaaS system may improve the security of the overall IaaS network (e.g., across multiple data centers, regions, etc.). For example, some IaaS systems may be implemented in multiple data centers (also called domains) within a region, and a global IaaS system may include multiple regions communicating with each other via private and / or public networks. Separating user-sourced communications from system-sourced communications may reduce the risk of large-scale system traffic type attacks (e.g., distributed denial of service, or DDOS attacks) from reaching core services.

[0207] As an illustrative example, communications from shell subnet 1970 may be attributed to the user (albeit potentially anonymized) of user device 1920 by the IP address of shell subnet 1970. Thus, messages from shell subnet 1970 purporting to originate from the core cloud services of the IaaS system may be rejected at the receiver point, for example, with a mismatched source IP address and source identifier (e.g., username). In another example, isolating outgoing user traffic to the public root compartment may provide improved forensic information for determining the source of an intrusion into the IaaS system. For example, by tracing a source IP address to public root compartment 2050, an investigation may be able to identify the compromised user instance, potentially revealing that the core IaaS service is not compromised.

[0208] In some embodiments, a user device 1920 (e.g., a browser and / or command line interface running a secure shell client) may connect with a cloud shell router 1930. The user device 1920 may connect to the cloud shell router through an external network 1980 (e.g., a public network). The external network 1980 may include, for example, the Internet, an encrypted network, etc. The user device 1920 may communicate with the cloud shell router 1930 through an Internet gateway 2060 (e.g., a "NET" gateway). The Internet gateway 2060 may be a virtual router added to the service VCN 2010 to provide a path for network traffic between the service VCN 2010 and the external network 1980.

[0209] In some embodiments, the service VCN 2010 also implements additional IaaS core services, including, but not limited to, a secure session manager service, a volume manager service, an instance manager service, and / or a web server, which may facilitate the creation, management, termination, and cleanup of secure shell instances 1950 and their associated data (e.g., block volumes, object storage, etc.).

[0210] In some embodiments, the secure shell instance 1950 communicates with the cloud shell router 1930 through a primary virtual network interface card (vNIC) 1940. The vNIC allows the instance to connect to a VCN. The primary vNIC 1940 may be configured to manage traffic between the cloud shell router and the secure shell instance 1950 (e.g., using security rules), as described above with reference to FIG.

[0211] Security rules may specify the type of ingress or egress traffic allowed into or out of primary vNIC 1940. For example, primary vNIC 1940 may be configured to accept signals from cloud shell router 1930 to secure shell instance 1950, but reject outgoing messages from secure shell instance 1950. In some embodiments, primary vNIC 1940 may accept return messages from secure shell instance 1950 addressed to user device 1920, for example, in response to a request for a return message included in a message from user device 1920. Primary vNIC 1940 may be attached to secure shell instance 1950, and security rules (e.g., ingress / egress control) may be part of the configuration of secure shell instance 1950 at startup and / or may be a default feature of secure shell instance 1950.

[0212] In some embodiments, the secure shell instance 1950 may be a virtual machine (e.g., a software-based emulation of a full computer running within a physical host computer, also called a "VM") specific to the user of the user device 1920, accompanied by a configuration file provided by a configuration subsystem (e.g., a session manager service) of the service VCN 2010. In some embodiments, the secure shell instance 1950 may be selected from an instance pool 2022 that includes one or more pre-spawned instances configured with default parameters. The default parameters may include security rules that define traffic management rules for the primary vNIC 1940.

[0213] In some embodiments, secure shell instance 1950 includes a secondary vNIC 1960. The secondary vNIC 1960 may be attached to secure shell instance 1950 during configuration of a pre-spawned instance from instance pool 2022. Alternatively, a pre-spawned instance in instance pool 2022 may be pre-configured to include the secondary vNIC 1960. In some embodiments, the secondary vNIC includes egress-only security rules (e.g., controls on traffic flow to restrict communication to only a single direction, from secure shell instance 1950 to shell subnet 1970). This is described in more detail below with reference to the figures. As discussed above, restricting network traffic in this manner may provide additional and / or improved security for secure shell instance 1950 and service VCN 2010.

[0214] In some embodiments, shell subnet 1970 may be configured to communicate with external network 1980 and / or private IaaS network 2082 via one or more virtual routers implemented in network-isolated VCN 2040. In some embodiments, shell subnet 1970 may send outgoing traffic received from secure shell instance 1950 via secondary vNIC 1960 to external network 1980 using network address translation (NAT) gateway 2070. NAT gateway 2070 may be a virtual router configured to perform network address translation. A NAT gateway may give cloud resources without public IP addresses access to the Internet without exposing those resources to incoming Internet connections. For example, a secure shell instance Secure shell instance 1950 and shell subnet 1970 may lack access to external network 1980 as a security measure to potentially reduce the risk of intrusion from malicious attacks. In such cases, NAT gateway 2070 may provide connectivity to the Internet using IP addresses not directly identified with secure shell instance 1950 or shell subnet 1970 (e.g., from a public block of IP addresses attributable to public route compartment 2050).

[0215] In some embodiments, output from secure shell instance 1950, including requests for core IaaS resources, may be routed by shell subnet 1970 to service (SVC) gateway 2072. Service gateway 2072 may be a virtual router attached to network-isolated VCN 2040 that may enable VCN hosts to privately access IaaS services (such as database resources, object storage, metadata management, etc.) without exposing the VCN hosts or the IaaS to the public Internet. Thus, service gateway 2072 may enable shell subnet 1970 to send output traffic over internal network 2082 (e.g., a “private network”) configured to communicate with IaaS core services in that region and / or other regions.

[0216] FIG. 21 illustrates an example technique 2100 for unidirectional communication with a secure shell instance using multiple network interfaces, according to one or more embodiments. Configuring a secure shell instance 1950 may include adding one or more additional virtual network interface cards (vNICs) to the secure shell instance 1950. The vNICs may enable the secure shell instance 1950 to send outgoing messages over a communication path separate from a communication path that may be used to receive instructions and / or commands from a user device (e.g., user device 1920 of FIG. 19 ). In some embodiments, the vNICs may be configured with security rules to define directional control of communication with the secure shell instance 1950, as described in more detail below.

[0217] As described in more detail with reference to FIG. 20 , the primary vNIC 1940 may be configured to facilitate communication between the secure shell instance 1950 and the cloud shell router 1930. In some embodiments, the secure shell instance 1950 may operate in a compute-isolated virtual cloud network (VCN), and the cloud shell router 1930 may operate in a service VCN. In some embodiments, the secure shell instance 1950 may include the primary vNIC 1940 as a default configuration. In some embodiments, the primary vNIC 1940 may be configured with security rules that define ingress-only restrictions on communications with the secure shell instance 1950. The ingress-only restrictions may limit the types of communications that can be received by the secure shell instance 1950 and / or may limit the sources from which communications can be received by the secure shell instance 1950.

[0218] In some embodiments, primary vNIC 1940 may be configured to allow incoming communications from core cloud resources (e.g., whitelist IaaS system components). For example, cloud shell router 1930 may send a command to secure shell instance 1950 (e.g., operation 2110). Secure shell instance 1950 may receive the command via primary vNIC 1940, which may be configured to allow communications from cloud shell router 1930 (e.g., operation 2112). Secure shell instance 1950 may then perform the operation indicated in the command and may generate an output as described with reference to FIG. 19 (e.g., Operation 2114).

[0219] In some embodiments, secondary vNIC 1960 may be configured to serve as an egress point for communications to facilitate transmission of output from secure shell instance 1950 to an external network (e.g., external network 1980 of FIG. 19 ) via shell subnet 1970. As described in more detail with reference to FIG. 20 , shell subnet 1970 may operate in a network-isolated VCN to potentially improve security by reducing the risk of intrusion by malicious attacks originating from the external network. In some embodiments, secondary vNIC 1960 may be configured during setup of the secure shell instance as a pre-spawned instance (e.g., in instance pool 2022 of FIG. 20 ). In some embodiments, secondary vNIC 1960 may be configured during specialization of secure shell instance 1950 (e.g., by a session manager service, an instance manager service, and / or other core cloud resources). Secondary vNIC 1960 may be configured with security rules to allow outgoing messages from secure shell instance 1950, for example, addressed to shell subnet 1970. For example, secure shell subnet 1950 may send the output through secondary vNIC 1960 (e.g., operation 2116) and may direct a message including the output to shell subnet 1970 (e.g., operation 2118). In this manner, example technique 2100 may include implementing primary vNIC 1940 as an ingress point for communications to secure shell instance 1950 and secondary vNIC 1960 as a separate egress point for communications from secure shell instance 1950.

[0220] 22 illustrates an example technique 2200 for using a first network interface for bidirectional communication with a secure shell instance 1950, according to one or more embodiments. The secure shell instance 1950 may be configured (e.g., during setup and / or specialization) to send messages through both a primary virtual network access card 1940 (vNIC) and a secondary vNIC 1960, albeit following defined techniques for providing secure communications and potentially reducing the risk of compromise.

[0221] In some embodiments, the primary vNIC 1940 may include a security rule that defines a blanket prohibition on all outgoing messages from the secure shell instance 1950 (e.g., an ingress-only rule with no exceptions). In contrast, a security rule may define the type of communication, the destination of the communication, or other exceptions to the security rule. For example, the primary vNIC 1940 may be configured to allow transmission of a reply message addressed to a user device (e.g., user device 1920 of FIG. 19 ) from the secure shell instance 1950 to the cloud shell router 1930. Such a reply message may include status information of the operation (e.g., completed, aborted, finished, etc.) and may include other reply information requests by the user device as part of the command.

[0222] As an illustrative example, secure shell instance 1950 may send messages by two different paths depending on the type and / or destination of the message. In this example, cloud shell router 1930 sends a command to the secure shell router (e.g., operation 2210), and secure shell instance 1950 receives the command from cloud shell router 1930 via primary vNIC 1940 (e.g., operation 2212). Secure shell instance 1950 may perform the operation indicated by the command and may generate output and reply messages (e.g., operation 2213). 4). As described above with reference to FIG. 21 , the secure shell instance 1950 may send the output as a message addressed to the shell subnet 1970 via the secondary vNIC 1960 (e.g., operation 2216). In contrast, the secure shell instance 1950 may send a return message via a different route, via the primary vNIC 1940, back to the cloud shell router 1930 (e.g., operation 2218).

[0223] Configuring primary vNIC 1940 to allow return messages may provide additional security to a system implementing example technique 2200. For example, return messages containing status information may be used by core cloud services to track and manage resource usage by secure shell instance 1950. Additionally, configuring secure shell instance 1950 to send return messages to cloud shell router 1930 rather than to shell subnet 1970 may potentially reduce the risk of the secure shell instance being used by an external system if shell subnet 1970 were to be compromised and, at least in part, the external system were unable to receive feedback that would enable it to take over from the owner of secure shell instance 1950.

[0224] 23 illustrates an example technique 2300 for unidirectional communication with a secure shell instance, according to one or more embodiments. Consequences of the security rules described above with reference to FIGS. 21-4 may include that the secure shell instance 1950 may be limited in the types and manner of communication it may be configured to achieve regarding output from operations it performs.

[0225] In some embodiments, the primary virtual network interface card 1940 (vNIC) may be configured with security rules that do not allow outgoing messages from the secure shell instance 1950 to be sent through the primary vNIC 1940. This may be implemented to control access to core cloud services running on a service VCN (e.g., service VCN 2010 of FIG. 20) from the secure shell instance 1950, which may be running on a compute-isolated virtual cloud network (VCN) (e.g., compute-isolated VCN 2020 of FIG. 20). As described in more detail above with reference to FIG. 22, while some types of messages may be allowed (e.g., reply messages), additional and / or alternative types of outgoing messages (e.g., execution commands, data transformation instructions, input / output operation instructions, etc.) may be allowed. Thus, limiting the types of communications allowed by the primary vNIC 1940 may potentially reduce the risk of compromising the service VCN or core cloud services by the secure shell instance 1950.

[0226] In an illustrative example, the primary vNIC 1940 may be configured to be ingress-only with respect to outgoing messages from the secure shell instance 1950. Thus, when the secure shell instance 1950 executes a command from a user device (e.g., user device 1920 of FIG. 19 ) and generates output (e.g., operation 2310), transmission of the output addressed to the cloud shell router 1930 may be rejected by the primary vNIC 1940 (e.g., operation 2312). The rejection by the primary vNIC 1940 may describe any number of logical operations that prevent the outgoing message from being sent to the cloud shell router 1930 and / or any other component system of the service VCN. For example, a security rule may blacklist a particular destination by address (e.g., MAC address).

[0227] In some embodiments, the secondary vNIC 1960 is a secure shell instance. The secondary vNIC 1960 may be configured with security rules that do not allow the secure shell instance 1950 to receive network traffic through the secondary vNIC 1960. This may be implemented to control access to the secure shell instance 1950 by the shell subnet 1970, which may communicate with the Internet and therefore may be at risk of attack by external systems. The security rules implemented as part of configuring the secondary vNIC 1960 may include a blanket restriction on all inbound communications from the shell subnet 1970 or any other IaaS system to the secure shell instance. Alternatively, communications, sources, or specific message types may be allowed as part of configuring (e.g., whitelisting) the secondary vNIC 1960.

[0228] In an illustrative example, secondary vNIC 1960 may be configured to be egress-only with respect to communication to secure shell instance 1950. In this example, an external network request may be received at shell subnet 1970 (e.g., operation 2314). The external network request may be an instruction for shell subnet 1970 to send a command to secure shell instance 1950 (e.g., to read data stored in a block volume system attached to secure shell instance 1950). Secondary vNIC 1960, configured for egress only in this example, may be limited to unidirectional communication and may allow secure shell instance 1950 to send outgoing messages through the secondary vNIC but may reject external network requests from shell subnet 1970 (e.g., operation 2316).

[0229] In some embodiments, secondary vNIC 1960 may similarly reject any incoming messages, even if received from other sources. For example, the MAC address of secondary vNIC 1960 may be discovered by an external system that may attempt to directly address secondary vNIC 1960. An egress-only security configuration may similarly protect secure shell instance 1950 from such attempts.

[0230] FIG. 24 illustrates an example system 2400 for managing communications of secure shell instances in a regional cloud system, according to one or more embodiments. The techniques described with reference to the previous figure may be implemented in a regional IaaS system. The regional IaaS system may include multiple domains 2410, where a domain may be an IaaS identifier corresponding to a data center, which is a physical installation of computer hardware (e.g., servers, network infrastructure, etc.) configured to operate the IaaS system. Some components of the example system 2400 may be regional, while other components may be domain-specific. Implementing a regional system may potentially reduce system overhead and demands on system resources due to the use of multiple communication points (e.g., ingress and egress points). Additionally, implementing unified communication resources may provide improved security by limiting the number of access points to secure shell instances and core cloud services.

[0231] In some embodiments, as described in more detail with reference to FIG. 20, the exemplary system 2400 may include two or more root compartments associated with different blocks of IP addresses. For example, the private root compartment 2420 may include a regional jump host virtual cloud network (VCN) 2430, a regional services VCN 2440, and a regional compute isolation VCN 2450. Similarly, the public root compartment 2460 may include a regional network The VCN may include a regional network-isolated VCN 2470 configured to connect to an external network (e.g., external network 1980 in FIG. 19) via a Network Address Translation (NAT) gateway 2480 and to connect to core cloud services via a regional service gateway 2482.

[0232] In some embodiments, jump host VCN 2430 may include a regional network gateway 2432 (NET) that may enable network traffic between the configuration network of private root compartment 2420 and external networks (e.g., the Internet, private user networks, etc.). For example, commands may be received from user device 1920 via regional network gateway 2432. In some embodiments, jump host VCN 2430 may be configured to send commands to a regional router subnet 2442 operating on regional service VCN 2440. Regional router subnet 2442 can direct commands to pool subnet 2452 addressed to secure shell instances operating within a pool of instances 2454 (e.g., secure shell instance 1950 of FIG. 19 ). In some embodiments, each domain 2410 may include a pool 2454 of instances operating on pool subnet 2452. Pool 2454 may then include multiple secure shell instances associated with secure shells created for users of the IaaS secure shell service. Each Secure Shell instance may include multiple virtual network interface cards (vNICs), as described in more detail with reference to the preceding figures.

[0233] In some embodiments, outgoing messages from instances operating on pool subnet 2452 in compute isolation VCN 2450 may be directed to regional shell subnet 2472 operating on network isolation VCN 2470. In contrast, return messages addressed to user devices may be directed to router subnet 2442 operating on serving VCN 2440. The regional subnet may direct the message to an external destination via an appropriate gateway.

[0234] FIG. 25 illustrates an example flow 2500 for utilizing multiple network interfaces for a secure shell instance, according to one or more embodiments. The operations of the flow may be implemented as hardware circuits and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as the secure shell instance 1950 of FIG. 19. When implemented, the instructions represent modules including circuits or code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform certain operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0235] In one example, flow 2500 includes operation 2502, in which a computer system receives a command to perform an operation via a primary virtual network interface card (vNIC). As described above in more detail with reference to FIGS. 19 and 21-4, the primary vNIC (e.g., primary vNIC 1940 of FIG. 19) may be configured during creation and / or specialization of a secure cloud instance (e.g., secure cloud instance 1950 of FIG. 19) with security rules. The security rules may control network traffic to a secure shell instance, such that the primary vNIC may be configured to be ingress-only with respect to one or more types of network traffic. For example, the primary vNIC may be configured to be ingress-only with respect to a secure shell instance. The secure shell instance may be configured to restrict network traffic between the secure shell instance and external systems (e.g., core cloud services, external network devices, etc.) so that the instance may receive incoming traffic through the primary vNIC but may not send outgoing traffic through the primary vNIC.

[0236] In one example, flow 2500 includes operation 2504, in which a computer system performs an operation. The secure shell instance may be a virtual machine (VM) hosted on a virtual cloud network (VCN), as described in more detail above with reference to FIG. 20. Thus, the secure shell instance may include computational resources (e.g., cores, threads, etc.) and data storage (e.g., block volumes, etc.). In some cases, the secure shell instance may be configured to execute commands received via a secure shell (e.g., terminal, bash shell, etc.) created to securely connect a user of a user device (e.g., user device 1920 of FIG. 19) to the secure shell instance, for example, via an encrypted connection (e.g., a WebSocket Secure connection).

[0237] In one example, flow 2500 includes operation 2506, in which the computer system generates output of the operation. In some embodiments, the output may include movement of data, transmission of requested information, and / or other types of output from the secure shell instance. Given that such output may include sensitive information, implementing network traffic control may potentially reduce the risk of misdirecting the output to an unauthorized destination.

[0238] In one example, flow 2500 includes operation 2508, in which the computer system sends a message including the output of the operation to a shell subnet via a secondary virtual network interface card (e.g., second vNIC 1960 of FIG. 19 ). The secondary vNIC may be configured with security rules that define a unidirectional restriction on network traffic, for example, for sending output from the secure shell instance to the shell subnet (e.g., shell subnet 1970). As described in more detail with reference to FIG. 20 , the shell subnet and the secure shell instance may operate in different VCNs that are isolated from each other, which may potentially improve communication security.

[0239] FIG. 26 illustrates an example flow 2600 for bidirectional communication with a secure shell instance using a network interface, according to one or more embodiments. The operations of the flow may be implemented as hardware circuits and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as the secure shell instance 1950 of FIG. 19. When implemented, the instructions represent modules including circuits or code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform certain operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0240] In one example, flow 2600 begins following operation 2504 of Figure 25, where a computer system performs operations. In particular, a computer system (e.g., secure shell instance 1950 of Figure 19) may implement one or more operations associated with communicating the output of the operations described with reference to the operations described in Figure 26.

[0241] In one example, flow 2600 includes operation 2602, in which the computer system generates a reply message for the user device. As described in more detail with reference to FIGS. 19 and 22, the Secure Shell instance may generate the reply message as part of performing the operation. The reply message may be a message for the user device (e.g., user device 1920 of FIG. 19). For example, the reply message may be a confirmation, status, or check bit that may be included as part of a command received from the user device.

[0242] In one example, flow 2600 includes operation 2604 in which the computer system sends a return message to a router via a primary virtual network interface card (e.g., primary vNIC 1940 of FIG. 19). As described in more detail with reference to FIG. 22, the primary vNIC may be configured for unidirectional network traffic, allowing inbound traffic to reach the Secure Shell instance but not outbound traffic from the Secure Shell instance to the IaaS service (e.g., cloud shell router 1930 of FIG. 19). In some embodiments, the primary vNIC may be configured to allow the return message to be sent to the cloud shell router for transmission to the user device via one or more elements operating within the Service VCN (e.g., Service VCN 2010 of FIG. 20).

[0243] FIG. 27 illustrates an example flow 2700 for bidirectional communication with a secure shell instance using a network interface, according to one or more embodiments. The operations of the flow may be implemented as hardware circuits and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as the secure shell instance 1950 of FIG. 19. When implemented, the instructions represent modules including circuits or code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform certain operations described herein. Each circuit or code, in combination with the processor, performs a respective operation. While the operations are shown in a particular order, it should be understood that a particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0244] In one example, flow 2700 includes operation 2702, in which a computer system receives an external network request through a secondary virtual network interface card (vNIC). As described in more detail with reference to the preceding paragraph, the secondary vNIC (e.g., secondary vNIC 1960 of FIG. 19 ) may be configured for unidirectional network traffic from the secure shell instance (e.g., via configuration of security rules during setup of the secure shell instance). Thus, if an external network request arrives at the secondary vNIC, the request may be malformed or incorrectly addressed to the secondary vNIC.

[0245] In one example, flow 2700 includes operation 2704 in which the computer system denies the external network request. The secondary vNIC may be configured to deny incoming network requests in some cases. For example, security rules included in the configuration of the secondary vNIC may define the secondary vNIC as unidirectional with no exceptions.

[0246] In one example, flow 2700 includes operation 2706 in which the computer system returns an error message. In some embodiments, returning the error message includes storing identifier information (e.g., username, login credentials, IP address, etc.) describing the external network request for potential use by the IaaS security service. For example, auditing unauthorized inbound network traffic can help identify whether one or more IaaS services and / or user instances may be compromised. In some embodiments, an error message may be directed to the IaaS security service, e.g., as a notification that an unauthorized inbound request was received on a secondary vNIC (which is egress only).

[0247] The following sections describe embodiments of the disclosed implementations: Item 1. A method comprising: receiving, by the computer system, a command to perform an action by the computer system, the command being received from the router via a primary virtual network interface card (vNIC); a computer system performing an operation; a computer system generating an output of the operation; the computer system sending a message including the output of the operation to the shell subnet via a secondary virtual network interface card, the secondary virtual network interface card being configured for unidirectional transmission from the computer system to the shell subnet; The method, wherein the shell subnet is configured to send output of the operation to an external network through a network gateway.

[0248] 2. The action is requested by a user of the user device, and generating an output of the action comprises: generating a reply message for the user device; and sending a reply message to the router via a primary virtual network interface card, the primary virtual network interface card including: configured to accept a reply message for the user device; 10. The method of claim 1, configured to reject messages that include output of an operation.

[0249] Clause 3. The method of clause 1, wherein the computer system is a virtual machine in a first virtual cloud network, the first virtual cloud network being configured in a private root compartment.

[0250] Item 4. The method of item 3, wherein the router is in a second virtual cloud network, the second virtual cloud network being different from the first virtual cloud network and configured in a private root compartment.

[0251] Item 5. The method of item 3, wherein the shell subnet is in a third virtual cloud network, the third virtual cloud network being different from the first virtual cloud network and configured in a public root compartment.

[0252] Item 6. The private root compartment is associated with a first block of IP addresses that may be attributed to network traffic from the private root compartment; The public root compartment is associated with an IP address in a second block, and the IP address in the second block is different from the IP address in the first block. 6. The method of claim 5, wherein the second block of IP addresses can be attributed to network traffic from one or more users of the computer system.

[0253] Section 7. Network Gateway is a Network Address Translation (NAT) gateway. 10. The method of claim 1, wherein the method is a network interface configured to send messages using an IP address from a block of IP addresses attributable to network traffic from one or more users of the computer system.

[0254] Section 8. A computer system comprising: one or more processors; and a memory in communication with the one or more processors, the memory configured to store computer-executable instructions, execution of the computer-executable instructions causing the one or more processors to perform steps, the steps including: receiving, by the computer system, a command to perform an action by the computer system, the command being received from the router via a primary virtual network interface card (vNIC); a computer system performing an operation; a computer system generating an output of the operation; the computer system sending a message including the output of the operation to the shell subnet via a secondary virtual network interface card, the secondary virtual network interface card being configured for unidirectional transmission from the computer system to the shell subnet; The computer system, wherein the shell subnet is configured to send output of the operation to an external network through a network gateway.

[0255] Item 9. The action is requested by a user of the user device, and generating an output of the action comprises: generating a reply message for the user device; and sending a reply message to the router via a primary virtual network interface card, the primary virtual network interface card including: configured to accept a reply message for the user device; 9. The system of claim 8, configured to reject a message that includes an output of the action.

[0256] Clause 10. The system of clause 8, wherein the computer system is a virtual machine in a first virtual cloud network, the first virtual cloud network being configured in a private root compartment.

[0257] Clause 11. The system of clause 10, wherein the router is in a second virtual cloud network, the second virtual cloud network being different from the first virtual cloud network and configured in a private root compartment.

[0258] Item 12. The system of item 10, wherein the shell subnet is in a third virtual cloud network, the third virtual cloud network being different from the first virtual cloud network and configured in a public root compartment.

[0259] Item 13. The private root compartment is associated with a first block of IP addresses that can be attributed to network traffic from the private root compartment; The public root compartment is associated with an IP address in a second block, and the IP address in the second block is different from the IP address in the first block. 13. The system of claim 12, wherein the second block of IP addresses can be attributed to network traffic from one or more users of the computer system.

[0260] Section 14. A network gateway is a network address translation (NAT) gateway. 9. The system of claim 8, wherein the system is a network and is configured to send messages using an IP address of a block of IP addresses that can be attributed to network traffic from one or more users of the computer system.

[0261] Item 15. A computer-readable storage medium storing computer-executable instructions that, when executed, cause one or more processors of a computer system to perform steps, said steps including: receiving, by the computer system, a command to perform an action by the computer system, the command being received from the router via a primary virtual network interface card (vNIC); a computer system performing an operation; a computer system generating an output of the operation; the computer system sending a message including the output of the operation to the shell subnet via a secondary virtual network interface card, the secondary virtual network interface card being configured for unidirectional transmission from the computer system to the shell subnet; The computer-readable storage medium, wherein the shell subnet is configured to transmit output of the operation to an external network through a network gateway.

[0262] Item 16. The action is requested by a user of the user device, and the step of generating an output of the action comprises: generating a reply message for the user device; and sending a reply message to the router via a primary virtual network interface card, the primary virtual network interface card including: configured to accept a reply message for the user device; 20. The computer-readable storage medium of clause 15, configured to reject a message that includes an output of the operation.

[0263] Item 17. The computer-readable storage medium of Item 15, wherein the computer system is a virtual machine in a first virtual cloud network, the first virtual cloud network being configured in a private root compartment.

[0264] Clause 18. The computer-readable storage medium of clause 17, wherein the router is in a second virtual cloud network, the second virtual cloud network being different from the first virtual cloud network and configured in a private root compartment.

[0265] Item 19. The computer-readable storage medium of Item 17, wherein the shell subnet is in a third virtual cloud network, the third virtual cloud network being different from the first virtual cloud network and configured in a public root compartment.

[0266] Item 20. The private root compartment is associated with a first block of IP addresses that can be attributed to network traffic from the private root compartment; The public root compartment is associated with an IP address in a second block, and the IP address in the second block is different from the IP address in the first block. 20. The computer-readable storage medium of claim 19, wherein the second block of IP addresses can be attributed to network traffic from one or more users of the computer system.

[0267] As mentioned above, Infrastructure as a Service (IaaS) is one specific type of cloud computing. IaaS is a service that runs on a public network (such as a In an IaaS model, a cloud computing provider may host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider may also supply various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) to accompany those infrastructure components. Accordingly, these services may be policy-driven, so that an IaaS user may be able to implement policies to drive load balancing to maintain application availability and performance.

[0268] In some cases, IaaS customers may access resources and services over a wide area network (WAN), such as the Internet, and may use the cloud provider's services to install the remaining elements of their application stack. For example, a user may log in to an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer may then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application issues, monitoring performance, managing disaster recovery, etc.

[0269] In most cases, the cloud computing model will require the participation of a cloud provider, which may be, but need not be, a third-party service that specializes in providing (e.g., offering, renting, selling) IaaS. Entities may also choose to deploy private clouds and become their own provider of infrastructure services.

[0270] In some examples, IaaS deployment is the process of putting a new application or a new version of an application onto a prepared application server, etc. It may also include the process of provisioning the server (e.g., installing libraries, daemons, etc.), which is often managed below the hypervisor layer (e.g., server, storage, network hardware, and virtualization) by the cloud provider. Thus, the customer may be responsible for handling (e.g., on self-service virtual machines (which may be launched on demand, for example)), middleware, and / or application deployment, etc.

[0271] In some instances, IaaS provisioning may refer to obtaining computers or virtual hosts for use and even installing required libraries or services on them. In most cases, deployment does not include provisioning, which may need to be performed first.

[0272] In some cases, there are two distinct problems with IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything works. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) once everything is provisioned. In some cases, these two challenges may be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) may be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on which resources and how they work together with each other) can be declaratively described. In some examples, once the topology is defined, workflows can be generated that create and / or manage the different components described in the configuration files.

[0273] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., potentially on-demand pools of configurable and / or shared computing resources), also known as a core network. In some examples, there may also be one or more security group rules and one or more virtual machines (VMs) provisioned to define how the network's security is set up. Other infrastructure elements, such as load balancers, databases, etc., may also be provisioned. The infrastructure may evolve incrementally as more and more infrastructure elements are desired and / or added.

[0274] In some examples, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques may enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across a variety of different geographic locations, sometimes spanning the entire world). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning may be done manually, utilizing a provisioning tool to provision resources and / or a deployment tool to deploy the code once the infrastructure is provisioned.

[0275] 28 is a block diagram 2800 illustrating an example pattern of an IaaS architecture according to at least one embodiment. A service operator 2802 may be communicatively coupled to a secure host tenancy 2804, which may include a virtual cloud network (VCN) 2806 and a secure host subnet 2808. In some examples, the service operator 2802 may employ one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, cellular phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display), running software such as Microsoft Windows Mobile® and / or other operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc. Client computing devices may be general-purpose personal computers, including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems, and may be, but are not limited to, various GNU / Linux operating systems, such as Google Chrome OS. Alternatively, or in addition, the client computing devices may be thin client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and other devices capable of communicating over a network that may have access to the VCN 2806 and / or the Internet. and / or any other electronic device such as a personal messaging device.

[0276] VCN 2806 may include a local peering gateway (LPG) 2810, which may be communicatively coupled to a secure shell (SSH) VCN 2812 via an LPG 2810 included in SSH VCN 2812. SSH VCN 2812 may include an SSH subnet 2814, which may be communicatively coupled to a control plane VCN 2816 via an LPG 2810 included in control plane VCN 2816. SSH VCN 2812 may also be communicatively coupled to a data plane VCN 2818 via LPG 2810. The control plane VCN 2816 and the data plane VCN 2818 may be included in a service tenancy 2819, which may be owned and / or operated by the IaaS provider.

[0277] Control plane VCN 2816 may include a control plane demilitarized zone (DMZ) tier 2820 that serves as a perimeter network (e.g., the portion of the enterprise network between the enterprise intranet and external networks). DMZ-based servers may have limited responsibilities and help keep security breaches contained. Additionally, DMZ tier 2820 may include one or more load balancer (LB) subnets 2822, a control plane app tier 2824 that may include an app subnet 2826, and a control plane data tier 2828 that may include a database (DB) subnet 2830 (e.g., a front-end DB subnet and / or a back-end DB subnet). LB subnet 2822 included in control plane DMZ layer 2820 may be communicatively coupled to app subnet 2826 included in control plane app layer 2824 and to Internet gateway 2834, which may be included in control plane VCN 2816, and app subnet 2826 may be communicatively coupled to DB subnet 2830, service gateway 2836, and network address translation (NAT) gateway 2838 included in control plane data layer 2828. Control plane VCN 2816 may include service gateway 2836 and NAT gateway 2838.

[0278] Control plane VCN 2816 may include a data plane mirror app layer 2840, which may include an app subnet 2826. The app subnet 2826 included in data plane mirror app layer 2840 may include a virtual network interface controller (VNIC) 2842, which may run a compute instance 2844. The compute instance 2844 may communicatively couple the app subnet 2826 of data plane mirror app layer 2840 to the app subnet 2826, which may be included in the data plane app layer 2846.

[0279] Data plane VCN 2818 may include a data plane app layer 2846, a data plane DMZ layer 2848, and a data plane data layer 2850. Data plane DMZ layer 2848 may include LB subnet 2822, which may be communicatively coupled to app subnet 2826 of data plane app layer 2846 and Internet gateway 2834 of data plane VCN 2818. App subnet 2826 may be communicatively coupled to service gateway 2836 of data plane VCN 2818 and NAT gateway 2838 of data plane VCN 2818. Data plane data layer 2850 may also include DB subnet 2830, which may be communicatively coupled to app subnet 2826 of data plane app layer 2846.

[0280] The internet gateways 2834 of the control plane VCN 2816 and the data plane VCN 2818 may be communicatively coupled to a metadata management service 2852, which may be communicatively coupled to the public internet 2854. 854 may be communicatively coupled to NAT gateways 2838 of the control plane VCN 2816 and the data plane VCN 2818. Service gateways 2836 of the control plane VCN 2816 and the data plane VCN 2818 may be communicatively coupled to cloud services 2856.

[0281] In some examples, the service gateway 2836 of the control plane VCN 2816 or the data plan VCN 2818 may make application programming interface (API) calls to the cloud services 2856 without traversing the public Internet 2854. The API calls from the service gateway 2836 to the cloud services 2856 may be one-way: the service gateway 2836 may make the API call to the cloud services 2856, and the cloud services 2856 may send the requested data to the service gateway 2836. However, the cloud services 2856 may not initiate the API calls to the service gateway 2836.

[0282] In some examples, secure host tenancy 2804 can connect directly to service tenancy 2819, which may otherwise be isolated. Secure host subnet 2808 may communicate with SSH subnet 2814 through LPG 2810, which may allow bidirectional communication through otherwise isolated systems. Connecting secure host subnet 2808 to SSH subnet 2814 may give secure host subnet 2808 access to other entities within service tenancy 2819.

[0283] The control plane VCN 2816 may enable users of the service tenancy 2819 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 2816 may be deployed or otherwise used in the data plane VCN 2818. In some examples, the control plane VCN 2816 may be isolated from the data plane VCN 2818, and the data plane mirror app layer 2840 of the control plane VCN 2816 may communicate with the data plane app layer 2846 of the data plane VCN 2818 via a VNIC 2842, which may be included in the data plane mirror app layer 2840 and the data plane app layer 2846.

[0284] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, via the public internet 2854, which may communicate the request to metadata management service 2852. Metadata management service 2852 may communicate the request to control plane VCN 2816 via internet gateway 2834. The request may be received by LB subnet 2822 included in control plane DMZ tier 2820. LB subnet 2822 may determine that the request is valid, and in response to this determination, LB subnet 2822 may send the request to app subnet 2826 included in control plane app tier 2824. If the request is validated and requires a call to the public internet 2854, the call to the public internet 2854 may be sent to NAT gateway 2838, which may make the call to the public internet 2854. Memory that may be desired to be stored with the request may be stored in DB subnet 2830.

[0285] In some examples, the data plane mirror app layer 2840 may facilitate direct communication between the control plane VCN 2816 and the data plane VCN 2818. For example, it may be desired that a configuration change, update, or other suitable modification be applied to resources included in the data plane VCN 2818. Via the VNIC 2842, the control plane VCN 2816 may communicate directly with resources included in the data plane VCN 2818, thereby performing the change, update, or other suitable modification to the configuration.

[0286] In some embodiments, the control plane VCN 2816 and the data plane VCN 2818 may be included in the service tenancy 2819. In this case, a user or customer of the system may not own or operate either the control plane VCN 2816 or the data plane VCN 2818. Instead, an IaaS provider may own or operate the control plane VCN 2816 and the data plane VCN 2818, both of which may be included in the service tenancy 2819. This embodiment may enable network isolation that may prevent a user or customer from interacting with the resources of other users or other customers. This embodiment may also allow a user or customer of the system to store databases privately without having to rely on the public internet 2854 for storage, which may not have the desired level of security.

[0287] In another embodiment, LB subnet 2822 included in control plane VCN 2816 may be configured to receive signals from service gateway 2836. In this embodiment, control plane VCN 2816 and data plane VCN 2818 may be configured to be called by customers of the IaaS provider without calling the public internet 2854. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored on service tenancy 2819, which may be controlled by the IaaS provider and isolated from the public internet 2854.

[0288] Figure 29 is a block diagram 2900 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 2902 (e.g., service operator 2802 of Figure 28) may be communicatively coupled to a secure host tenancy 2904 (e.g., secure host tenancy 2804 of Figure 28), which may include a virtual cloud network (VCN) 2906 (e.g., VCN 2806 of Figure 28) and a secure host subnet 2908 (e.g., secure host subnet 2808 of Figure 28). VCN 2906 may include a local peering gateway (LPG) 2910 (e.g., LPG 2810 of Figure 28), which may be communicatively coupled to a secure shell (SSH) VCN 2912 (e.g., SSH VCN 2812 of Figure 28) via an LPG 2810 included in SSH VCN 2912. SSH VCN 2912 may include SSH subnet 2914 (e.g., SSH subnet 2814 in FIG. 28 ), and SSH VCN 2912 may be communicatively coupled to control plane VCN 2916 (e.g., control plane VCN 2816 in FIG. 28 ) via LPG 2910 included in control plane VCN 2916. Control plane VCN 2916 may be included in service tenancy 2919 (e.g., service tenancy 2819 in FIG. 28 ), and data plane VCN 2918 (e.g., data plane VCN 2818 in FIG. 28 ) may be included in customer tenancy 2921, which may be owned or operated by a user or customer of the system.

[0289] The control plane VCN 2916 may include a control plane DMZ tier 2920 (e.g., control plane DMZ tier 2820 of FIG. 28 ) that may include a LB subnet 2922 (e.g., LB subnet 2822 of FIG. 28 ), a control plane app tier 2924 (e.g., control plane app tier 2824 of FIG. 28 ) that may include an app subnet 2926 (e.g., app subnet 2826 of FIG. 28 ), and a control plane data tier 2928 (e.g., control plane data tier 2828 of FIG. 28 ) that may include a database (DB) subnet 2930 (e.g., similar to DB subnet 2830 of FIG. 28 ). The LB subnet 2922 included in the control plane DMZ layer 2920 may be communicatively coupled to an app subnet 2926 included in the control plane app layer 2924 and to an Internet gateway 2934 (e.g., Internet gateway 2834 in FIG. 28 ) that may be included in the control plane VCN 2916, and the app subnet 2926 may be communicatively coupled to an internet gateway 2934 included in the control plane data layer 2928. The control plane VCN 2916 may be communicatively coupled to a DB subnet 2930 containing the control plane VCN 2916, a service gateway 2936 (e.g., the service gateway of FIG. 28), and a network address translation (NAT) gateway 2938 (e.g., the NAT gateway 2838 of FIG. 28).

[0290] Control plane VCN 2916 may include a data plane mirror app layer 2940 (e.g., data plane mirror app layer 2840 of FIG. 28 ), which may include an app subnet 2926. App subnet 2926 included in data plane mirror app layer 2940 may include a virtual network interface controller (VNIC) 2942 (e.g., VNIC 2842) that may run compute instance 2944 (e.g., similar to compute instance 2844 of FIG. 28 ). Compute instance 2944 may facilitate communication between app subnet 2926 of data plane mirror app layer 2940 and app subnet 2926 that may be included in data plane app layer 2946 (e.g., data plane app layer 2846 of FIG. 28 ), via VNIC 2942 included in data plane mirror app layer 2940 and VNIC 2942 included in data plane app layer 2946.

[0291] An internet gateway 2934 included in the control plane VCN 2916 may be communicatively coupled to a metadata management service 2952 (e.g., metadata management service 2852 of FIG. 28), which may be communicatively coupled to the public internet 2954 (e.g., public internet 2854 of FIG. 28). The public internet 2954 may be communicatively coupled to a NAT gateway 2938 included in the control plane VCN 2916. A service gateway 2936 included in the control plane VCN 2916 may be communicatively coupled to cloud services 2956 (e.g., cloud services 2856 of FIG. 28).

[0292] In some examples, data plane VCN 2918 may be included in customer tenancy 2921. In this case, the IaaS provider may provide a control plane VCN 2916 for each customer, and the IaaS provider may set up a unique compute instance 2944, included in service tenancy 2919, for each customer. Each compute instance 2944 may enable communication between the control plane VCN 2916 included in service tenancy 2919 and the data plane VCN 2918 included in customer tenancy 2921. The compute instance 2944 may enable resources provisioned in the control plane VCN 2916 included in service tenancy 2919 to be deployed or otherwise used in the data plane VCN 2918 included in customer tenancy 2921.

[0293] In another example, a customer of the IaaS provider may have a database residing in customer tenancy 2921. In this example, control plane VCN 2916 may include data plane mirror app tier 2940, which may include app subnet 2926. Data plane mirror application tier 2940 may reside in data plane VCN 2918, but data plane mirror application tier 2940 may not reside in data plane VCN 2918. That is, data plane mirror application tier 2940 may have access to customer tenancy 2921, but data plane mirror application tier 2940 may not reside in data plane VCN 2918 or be owned or operated by the IaaS provider's customer. Data plane mirror application tier 2940 may be configured to make calls to data plane VCN 2918, but may not be configured to make calls to any entities included in control plane VCN 2916. The customer may have access to control plane VCN 2916. A customer may desire to deploy or otherwise use resources within data plane VCN 2918 provisioned within 6, and data plane mirror application layer 2940 may facilitate the desired deployment or other use of the customer's resources.

[0294] In some embodiments, the IaaS provider's customer may apply filters to the data plane VCN 2918. In this embodiment, the customer may determine what the data plane VCN 2918 can access, and the customer may restrict access from the data plane VCN 2918 to the public internet 2954. The IaaS provider may not be able to filter or otherwise control access of the data plane VCN 2918 to any external networks or databases. Applying filters and controls by the customer on the data plane VCN 2918 included in customer tenancy 2921 can help isolate the data plane VCN 2918 from other customers and the public internet 2954.

[0295] In some embodiments, cloud services 2956 may be invoked by service gateway 2936 to access services that may not reside on the public internet 2954, on the control plane VCN 2916, or on the data plane VCN 2918. The connection between cloud services 2956 and the control plane VCN 2916 or the data plane VCN 2918 may not be live or continuous. Cloud services 2956 may reside on different networks owned or operated by the IaaS provider. Cloud services 2956 may be configured to receive calls from service gateway 2936 and may not be configured to receive calls from the public internet 2954. Some cloud services 2956 may be isolated from other cloud services 2956, and control plane VCN 2916 may be isolated from cloud services 2956 that may not be in the same region as control plane VCN 2916. For example, control plane VCN 2916 may be located in “Region 1,” and cloud service “Deployment 28” may be located in Region 1 and “Region 2.” If a call to a deployment 28 is made by a service gateway 2936 included in a control plane VCN 2916 located in Region 1, the call may be transmitted to the deployment 28 in Region 1. In this example, the control plane VCN 2916, or the deployment 28 in Region 1, may not be communicatively coupled to or otherwise in communication with the deployment 28 in Region 2.

[0296] Figure 30 is a block diagram 3000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 3002 (e.g., service operator 2802 of Figure 28) may be communicatively coupled to a secure host tenancy 3004 (e.g., secure host tenancy 2804 of Figure 28), which may include a virtual cloud network (VCN) 3006 (e.g., VCN 2806 of Figure 28) and a secure host subnet 3008 (e.g., secure host subnet 2808 of Figure 28). VCN 3006 may include an LPG 3010 (e.g., LPG 2810 of Figure 28), which may be communicatively coupled to an SSH VCN 3012 (e.g., SSH VCN 2812 of Figure 28) via the LPG 3010 included in the SSH VCN 3012. SSH VCN 3012 may include SSH subnet 3014 (e.g., SSH subnet 2814 in FIG. 28 ), which may be communicatively coupled to control plane VCN 3016 via LPG 3010 included in control plane VCN 3016 (e.g., control plane VCN 2816 in FIG. 28 ), and may be communicatively coupled to data plane VCN 3018 via LPG 3010 included in data plane VCN 3018 (e.g., data plane 2818 in FIG. 28 ). Control plane VCN 3016 and data plane VCN 3018 may be included in service tenancy 3019 (e.g., service tenancy 2819 in FIG. 28 ).

[0297] The control plane VCN 3016 may include a control plane DMZ tier 3020 (e.g., control plane DMZ tier 2820 of FIG. 28 ) that may include a load balancer (LB) subnet 3022 (e.g., LB subnet 2822 of FIG. 28 ), a control plane app tier 3024 (e.g., control plane app tier 2824 of FIG. 28 ) that may include an app subnet 3026 (e.g., similar to app subnet 2826 of FIG. 28 ), and a control plane data tier 3028 (e.g., control plane data tier 2828 of FIG. 28 ) that may include a DB subnet 3030. LB subnet 3022 included in control plane DMZ tier 3020 may be communicatively coupled to app subnet 3026 included in control plane app tier 3024 and to an Internet gateway 3034 (e.g., Internet gateway 2834 in FIG. 28 ) that may be included in control plane VCN 3016, and app subnet 3026 may be communicatively coupled to DB subnet 3030 included in control plane data tier 3028, as well as to service gateway 3036 (e.g., service gateway in FIG. 28 ) and network address translation (NAT) gateway 3038 (e.g., NAT gateway 2838 in FIG. 28 ). Control plane VCN 3016 may include service gateway 3036 and NAT gateway 3038.

[0298] Data plane VCN 3018 may include a data plane app layer 3046 (e.g., data plane app layer 2846 in FIG. 28 ), a data plane DMZ layer 3048 (e.g., data plane DMZ layer 2848 in FIG. 28 ), and a data plane data layer 3050 (e.g., data plane data layer 2850 in FIG. 28 ). Data plane DMZ layer 3048 may include LB subnet 3022, which may be communicatively coupled to trusted app subnet 3060 and untrusted app subnet 3062 of data plane app layer 3046 and to Internet gateway 3034 included in data plane VCN 3018. Trusted app subnet 3060 may be communicatively coupled to service gateway 3036 included in data plane VCN 3018, NAT gateway 3038 included in data plane VCN 3018, and DB subnet 3030 included in data plane data layer 3050. Untrusted app subnet 3062 may be communicatively coupled to a service gateway 3036 included in data plane VCN 3018 and a DB subnet 3030 included in data plane data layer 3050. Data plane data layer 3050 may include DB subnet 3030, which may be communicatively coupled to a service gateway 3036 included in data plane VCN 3018.

[0299] The untrusted app subnet 3062 may include one or more primary VNICs 3064(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 3066(1)-(N). Each tenant VM 3066(1)-(N) may be communicatively coupled to a respective app subnet 3067(1)-(N), which may be included in a respective container egress VCN 3068(1)-(N), which may be included in a respective customer tenancy 3070(1)-(N). Each secondary VNIC 3072(1)-(N) may facilitate communication between the untrusted app subnet 3062 included in the data plane VCN 3018 and the app subnet included in the container egress VCN 3068(1)-(N). Each container egress VCN 3068(1)-(N) may include a NAT gateway 3038, which may be communicatively coupled to the public internet 3054 (e.g., public internet 2854 in FIG. 28 ).

[0300] The internet gateway 3034 included in the control plane VCN 3016 and included in the data plane VCN 3018 may be communicatively coupled to a metadata management service 3052 (e.g., metadata management system 2852 of FIG. 28 ), which may be communicatively coupled to the public internet 3054. The public internet 3054 is connected to the NAT gateway included in the control plane VCN 3016 and included in the data plane VCN 3018. The service gateway 3036 included in the control plane VCN 3016 and included in the data plane VCN 3018 may be communicatively coupled to the cloud service 3056.

[0301] In some embodiments, data plane VCN 3018 may be integrated with customer tenancy 3070. This integration may be useful or desirable to an IaaS provider's customer in some cases, such as when they may want support when executing code. A customer may provide code to run that may be disruptive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code provided to the IaaS provider by the customer.

[0302] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request that a function be attached to data plane layer app 3046. The code to perform the function may run in VMs 3066(1)-(N) and may not be configured to run anywhere else on data plane VCN 3018. Each VM 3066(1)-(N) may be connected to one customer tenancy 3070. Each container 3071(1)-(N) contained in VM 3066(1)-(N) may be configured to run code. In this case, there may be double isolation (e.g., containers 3071(1)-(N) may execute code, and containers 3071(1)-(N) may be included in at least VMs 3066(1)-(N) included in untrusted app subnet 3062), which may help prevent incorrect or otherwise unwanted code from damaging the IaaS provider's network or damaging a different customer's network. Containers 3071(1)-(N) may be communicatively coupled to customer tenancy 3070 and may be configured to send or receive data to or from customer tenancy 3070. Containers 3071(1)-(N) may not be configured to send or receive data to or from any other entity in data plane VCN 3018. Once the code execution is complete, the IaaS provider may kill or otherwise discard containers 3071(1)-(N).

[0303] In some embodiments, trusted app subnet 3060 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 3060 may be communicatively coupled to DB subnet 3030 and may be configured to perform CRUD operations within DB subnet 3030. Untrusted app subnet 3062 may be communicatively coupled to DB subnet 3030, but in this embodiment, the untrusted app subnet may be configured to perform read operations within DB subnet 3030. Containers 3071(1)-(N) that may be included in each customer's VMs 3066(1)-(N) and that may execute code from that customer may not be communicatively coupled to DB subnet 3030.

[0304] In other embodiments, the control plane VCN 3016 and the data plane VCN 3018 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 3016 and the data plane VCN 3018. However, communication may occur indirectly through at least one method. An LPG 3010 may be established by the IaaS provider that may facilitate communication between the control plane VCN 3016 and the data plane VCN 3018. In another example, the control plane VCN 3016 or the data plane VCN 3018 may make a call to a cloud service 3056 through a service gateway 3036. For example, a call from the control plane VCN 3016 to the cloud service 3056 may be routed to a service gateway 3036 that may communicate with the data plane VCN 3018. This may include a request for service.

[0305] Figure 31 is a block diagram 3100 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 3102 (e.g., service operator 2802 of Figure 28) may be communicatively coupled to a secure host tenancy 3104 (e.g., secure host tenancy 2804 of Figure 28), which may include a virtual cloud network (VCN) 3106 (e.g., VCN 2806 of Figure 28) and a secure host subnet 3108 (e.g., secure host subnet 2808 of Figure 28). VCN 3106 may include an LPG 3110 (e.g., LPG 2810 of Figure 28), which may be communicatively coupled to an SSH VCN 3112 (e.g., SSH VCN 2812 of Figure 28) via the LPG 3110 included in SSH VCN 3112. SSH VCN 3112 may include SSH subnet 3114 (e.g., SSH subnet 2814 in FIG. 28 ), which may be communicatively coupled to control plane VCN 3116 via LPG 3110 included in control plane VCN 3116 (e.g., control plane VCN 2816 in FIG. 28 ) and to data plane VCN 3118 via LPG 3110 included in data plane VCN 3118 (e.g., data plane 2818 in FIG. 28 ). Control plane VCN 3116 and data plane VCN 3118 may be included in service tenancy 3119 (e.g., service tenancy 2819 in FIG. 28 ).

[0306] The control plane VCN 3116 may include a control plane DMZ layer 3120 (e.g., control plane DMZ layer 2820 of FIG. 28 ) that may include a LB subnet 3122 (e.g., LB subnet 2822 of FIG. 28 ), a control plane app layer 3124 (e.g., control plane app layer 2824 of FIG. 28 ) that may include an app subnet 3126 (e.g., app subnet 2826 of FIG. 28 ), and a control plane data layer 3128 (e.g., control plane data layer 2828 of FIG. 28 ) that may include a DB subnet 3130 (e.g., DB subnet 3030 of FIG. 30 ). LB subnet 3122 included in control plane DMZ layer 3120 may be communicatively coupled to app subnet 3126 included in control plane app layer 3124 and to Internet gateway 3134 (e.g., Internet gateway 2834 in FIG. 28 ) that may be included in control plane VCN 3116, and app subnet 3126 may be communicatively coupled to DB subnet 3130 included in control plane data layer 3128 and to service gateway 3136 (e.g., service gateway in FIG. 28 ) and network address translation (NAT) gateway 3138 (e.g., NAT gateway 2838 in FIG. 28 ). Control plane VCN 3116 may include service gateway 3136 and NAT gateway 3138.

[0307] Data plane VCN 3118 may include a data plane app layer 3146 (e.g., data plane app layer 2846 in FIG. 28 ), a data plane DMZ layer 3148 (e.g., data plane DMZ layer 2848 in FIG. 28 ), and a data plane data layer 3150 (e.g., data plane data layer 2850 in FIG. 28 ). Data plane DMZ layer 3148 may include LB subnet 3122, which may be communicatively coupled to trusted app subnet 3160 (e.g., trusted app subnet 3060 in FIG. 30 ) and untrusted app subnet 3162 (e.g., untrusted app subnet 3062 in FIG. 30 ) of data plane app layer 3146 and to an Internet gateway 3134 included in data plane VCN 3118. The trusted app subnet 3160 may be communicatively coupled to the service gateway 3136 included in the data plane VCN 3118, the NAT gateway 3138 included in the data plane VCN 3118, and the DB subnet 3130 included in the data plane data layer 3150. The untrusted app subnet 3162 may be communicatively coupled to the service gateway 3136 included in the data plane VCN 3118, the NAT gateway 3138 included in the data plane data layer 3150, and the DB subnet 3130 included in the data plane data layer 3150. 0. Data plane data layer 3150 may include DB subnet 3130, which may be communicatively coupled to service gateway 3136 included in data plane VCN 3118.

[0308] The untrusted app subnet 3162 may include primary VNICs 3164(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 3166(1)-(N) residing within the untrusted app subnet 3162. Each tenant VM 3166(1)-(N) may execute code in a respective container 3167(1)-(N), which may be communicatively coupled to an app subnet 3126, which may be included in a data plane app tier 3146, which may be included in a container egress VCN 3168. Each secondary VNIC 3172(1)-(N) may facilitate communication between the untrusted app subnet 3162, which is included in the data plane VCN 3118, and the app subnet included in the container egress VCN 3168. The container egress VCN may include a NAT gateway 3138, which may be communicatively coupled to the public internet 3154 (e.g., public internet 2854 in FIG. 28 ).

[0309] Internet gateway 3134 included in control plane VCN 3116 and included in data plane VCN 3118 may be communicatively coupled to metadata management service 3152 (e.g., metadata management system 2852 of FIG. 28 ), which may be communicatively coupled to public internet 3154. Public internet 3154 may be communicatively coupled to NAT gateway 3138 included in control plane VCN 3116 and included in data plane VCN 3118. Service gateway 3136 included in control plane VCN 3116 and included in data plane VCN 3118 may be communicatively coupled to cloud services 3156.

[0310] In some examples, the pattern illustrated by the architecture of block diagram 3100 in FIG. 31 may be considered an exception to the pattern illustrated by the architecture of block diagram 3000 in FIG. 30, which may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 3167(1)-(N) included in VM 3166(1)-(N) for each customer may be accessed by the customer in real time. The containers 3167(1)-(N) may be configured to make calls to each secondary VNIC 3172(1)-(N) included in app subnet 3126 of data plane app tier 3146, which may be included in container egress VCN 3168. The secondary VNICs 3172(1)-(N) may send the calls to NAT gateway 3138, which may send the calls to the public Internet 3154. In this example, containers 3167(1)-(N) that may be accessed in real time by a customer may be isolated from control plane VCN 3116 and may be isolated from other entities included in data plane VCN 3118. Containers 3167(1)-(N) may also be isolated from resources from other customers.

[0311] In another example, a customer may invoke cloud service 3156 using container 3167(1)-(N). In this example, the customer may execute code within container 3167(1)-(N) that requests a service from cloud service 3156. Container 3167(1)-(N) may send the request to secondary VNICs 3172(1)-(N), which may send the request to a NAT gateway, which may send the request to public internet 3154. Public internet 3154 may send the request to LB subnet 3122, which is included in control plane VCN 3116, via internet gateway 3134. In response to determining that the request is valid, the LB subnet may forward the request to the app subnet. The request may be sent to the app subnet 3126, which may then send the request to the cloud service 3156 via the service gateway 3136.

[0312] It should be appreciated that the illustrated IaaS architectures 2800, 2900, 3000, 3100 may have components other than those shown. Additionally, the illustrated embodiments are only a few examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS systems may have more or fewer components than those shown, may combine two or more components, or may have a different configuration or arrangement of components.

[0313] In one embodiment, the IaaS system described herein may include a suite of application, middleware, and database service offerings that are self-service, subscription-based, elastically scalable, reliable, highly available, and securely delivered to customers. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the present assignee.

[0314] 32 illustrates an exemplary computer system 3200 upon which various embodiments of the present disclosure may be implemented. System 3200 may be used to implement any of the computer systems described above. As shown in the figure, computer system 3200 includes a processing unit 3204 that communicates with several peripheral subsystems via a bus subsystem 3202. These peripheral subsystems may include a processing acceleration unit 3206, an I / O subsystem 3208, a storage subsystem 3218, and a communication subsystem 3224. Storage subsystem 3218 includes a tangible computer-readable storage medium 3222 and a system memory 3210.

[0315] Bus subsystem 3202 provides a mechanism for allowing the various components and subsystems of computer system 3200 to communicate with each other as intended. While bus subsystem 3202 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 3202 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0316] Processing unit 3204 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of computer system 3200. One or more processors may be included in processing unit 3204. These processors may include single-core processors or multi-core processors. In particular embodiments, processing unit 3204 may be implemented as one or more independent processing units 3232 and / or 3234, with each processing unit including a single-core processor or a multi-core processor. In other embodiments, processing unit 3204 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0317] In various embodiments, processing unit 3204 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any given time, only a portion or portions of program code may be executed. may all reside in the processor 3204 and / or the storage subsystem 3218. Through suitable programming, the processor 3204 may provide the various functionality described above. The computer system 3200 may further include a processing acceleration unit 3206, which may include a digital signal processor (DSP), a special purpose processor, or the like.

[0318] The I / O subsystem 3208 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include, for example, a motion-sensing and / or gesture-recognition device such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and spoken commands. User interface input devices may detect eye movements from the user (e.g., "blinking" while taking a picture and / or making a menu selection) and translate eye gestures into an input device (e.g., a Google The user interface input devices may also include eye gesture recognition devices such as a Google Glass® blink detector that converts eye movements as input to the Google Glass®. Additionally, the user interface input devices may include a voice recognition sensing device that allows the user to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0319] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, user interface input devices may include medical imaging input devices, such as computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound machines, etc. User interface input devices may also include audio input devices, such as MIDI keyboards, digital musical instruments, etc.

[0320] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD), or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all conceivable types of devices and mechanisms for outputting information from computer system 3200 to a user or another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / visual information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0321] Computer system 3200 may include a storage subsystem 3218 that includes software elements currently shown as located in system memory 3210. System memory 3210 may be loadable and programmable on processing unit 3204. It may store executable program instructions as well as data generated during the execution of these programs.

[0322] Depending on the configuration and type of computer system 3200, system memory 3210 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or presently being operated on and executed by the processing unit 3204. In some implementations, system memory 3210 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing basic routines that help to transfer information between elements within computer system 3200, such as during start-up, may typically be stored in ROM. By way of example and not limitation, system memory 3210 also illustrates application programs 3212, program data 3214, and operating system 3216, which may include client applications, a web browser, a middle-tier application, a relational database management system (RDBMS), etc. By way of example, operating system 3216 may be any of various versions of Microsoft Windows, Apple Macintosh, and / or Linux. trademark) operating system, various commercially available UNIX or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

[0323] The storage subsystem 3218 may also provide a tangible, computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above may be stored in the storage subsystem 3218. These software modules or instructions may be executed by the processing unit 3204. The storage subsystem 3218 may also provide a repository for storing data used in accordance with the present disclosure.

[0324] Storage subsystem 3200 may also include computer-readable storage medium reader 3220, which may be further connected to computer-readable storage medium 3222. Along with, and optionally in combination with, system memory 3210, computer-readable storage medium 3222 may collectively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0325] The computer readable storage medium 3222 containing the code or portions of code may also include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and non-volatile, removable and non-removable media implemented in any method or technology for information storage and / or transmission, including tangible media such as RAM, ROM, Electronically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage, or other tangible computer readable medium. This may include tangible computer-readable storage media, such as a data signal, data transmission, or any other medium that can be used to transmit desired information and that can be accessed by computing system 3200.

[0326] By way of example, the computer readable storage medium 3222 may be a hard disk drive that reads from and writes to a non-removable, non-volatile magnetic medium, a magnetic disk drive that reads from and writes to a removable, non-volatile magnetic disk, a CD ROM, a DVD, and a Blu-Ray (registered trademark) The computer system 3200 may also include an optical disk drive or other optical medium that reads from and writes to removable, nonvolatile optical disks, such as USB (Universal Serial Bus) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer-readable storage medium 3222 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on nonvolatile memory such as solid-state ROM, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data to the computer system 3200.

[0327] The communications subsystem 3224 provides an interface to other computer systems and networks. The communications subsystem 3224 serves as an interface for sending and receiving data between other systems and the computer system 3200. For example, the communications subsystem 3224 may enable the computer system 3200 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 3224 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular telephone technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 family standard, or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 3224 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0328] In some embodiments, the communications subsystem 3224 may also receive incoming communications in the form of structured and / or unstructured data feeds 3226, event streams 3228, event updates 3230, etc., on behalf of one or more users who may be using the computer system 3200.

[0329] For example, the communication subsystem 3224 may provide a Twitter feed, Facebook feed, Registered Trademark) updates, web feeds such as Rich Site Summary (RSS) feeds, and and / or may be configured to receive data feeds 3226 in real time from users of social networks and / or other communication services, such as real-time updates from one or more third-party sources.

[0330] Additionally, the communications subsystem 3224 may also be configured to receive data in the form of a continuous data stream, which may be essentially continuous or continuous with no explicit termination. It may include an event stream 3228 of real-time events and / or event updates 3230, which may be infinite. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock ticker boards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0331] The communications subsystem 3224 may also be configured to output structured and / or unstructured data feeds 3226, event streams 3228, event updates 3230, etc. to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 3200.

[0332] The computer system 3200 can be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0333] Due to the ever-changing nature of computers and networks, the description of computer system 3200 shown in the figure is intended merely as a specific example. Many other configurations are possible, having more or fewer components than the system depicted in the figure. For example, customized hardware might also be used, and / or particular elements might be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, might be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other aspects and / or methods for implementing the various embodiments.

[0334] Although specific embodiments of the present disclosure have been described, various modifications, variations, alternative configurations, and equivalents are encompassed within the scope of the present disclosure. The embodiments of the present disclosure are not limited to operation in a particular data processing environment, but can freely operate in multiple data processing environments. Additionally, while the embodiments of the present disclosure are described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments may be used individually or together.

[0335] Furthermore, while embodiments of the present disclosure have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments of the present disclosure may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. The various processes described herein may be implemented on the same processor or any combination of different processors. Thus, when a component or module is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry to perform the operation, programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication; different pairs of processes may use different techniques, and the same pair of processes may use different techniques at different times.

[0336] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent that additions, subtractions, deletions, and other modifications and changes may be made without departing from the spirit and scope of the present invention. Accordingly, while particular disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the claims.

[0337] The use of the words "a," "an," and "the" and similar referents in the context of describing disclosed embodiments (particularly in the context of the claims) should be construed to encompass both the singular and the plural unless otherwise indicated herein or clearly contradicted by context. The words "comprising," "having," "including," and "containing" are used in open-ended language (i.e., "including but not limited to"), unless otherwise noted. The term "connected" should be interpreted as including, but not limited to, within, attached to, or joined together, even if there is something intervening. The recitation of ranges of values herein, unless otherwise indicated herein, is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, and each separate value is incorporated herein as if it were individually set forth herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., "etc.") provided herein is intended merely to better describe embodiments of the present disclosure and does not limit the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0338] Disjunctive language such as the phrase "at least one of X, Y, or Z" is intended to be understood within the context in which it is generally used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, encompass that an embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0339] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to adopt such variations as appropriate, and the present disclosure may be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure unless otherwise indicated herein.

[0340] All references cited herein, including publications, patent applications, and patents, are hereby incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0341] While the foregoing specification describes aspects of the disclosure with reference to specific embodiments thereof, those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above disclosure may be used individually or together. Moreover, embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Thus, Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. 1. A method comprising: The method includes receiving a request to reserve a block volume from a computer system, the request being received from a session manager service, the method further comprising: the computer system reserving the block volume; the computer system identifying a data center identifier for the block volume; the computer system returning the data center identifier for the block volume to the session manager service; the computer system attaching the block volume; receiving, by the computer system, an instruction from the session manager service to release the block volume; the computer system creating a backup of the block volume including the data stored in the block volume; the computer system releasing the block volume.

2. The request includes a user identifier, and reserving the block volume includes: determining whether a registered block volume is assigned to a user corresponding to the user identifier; reserving the registered block volume in response to the registered block volume being assigned to the user; 2. The method of claim 1, further comprising: reserving an empty volume from a pool of empty volumes in response to a registered block volume not being assigned to a user corresponding to the user identifier, the empty volume being pre-formatted for docking with a secure cloud shell.

3. The method further comprises: receiving a request to restore the block volume from the session manager service; creating a recovery volume using the backup of the block volume, the recovery volume including data stored in the block volume, the method further comprising:

10. The method of claim 1, further comprising returning a data center identifier for the recovery volume to the session manager service.

4. The backup of the block volume further includes an identifier of the backup, and creating the restoration volume includes: and reserving an empty block volume from a pool of empty volumes, the empty block volume being pre-formatted to dock with a secure cloud shell; and creating the restore volume further comprising: retrieving the backup of the block volume using the identifier of the backup; provisioning the empty block volume at least in part by loading the backup of the block volume onto the empty block volume; and identifying the data center identifier of the empty block volume as the data center identifier of the recovery volume.

5. The method of claim 1 , further comprising retaining the block volume for a retention period.

6. The method of claim 1 , wherein creating the backup of the block volume comprises creating a disk image of the block volume.

7. Creating the backup of the block volume includes: converting the data in the block volume into object data; and storing the object data in an object storage system.

8. 1. A computer system comprising: one or more processors; and a memory in communication with the one or more processors, the memory configured to store computer-executable instructions, the execution of which causes the one or more processors to perform steps including: The method includes receiving a request to reserve a block volume from a computer system, the request being received from a session manager service, the method further comprising: the computer system reserving the block volume; the computer system identifying a data center identifier for the block volume; the computer system returning the data center identifier for the block volume to the session manager service; the computer system attaching the block volume; receiving, by the computer system, an instruction from the session manager service to release the block volume; the computer system creating a backup of the block volume including the data stored in the block volume; and releasing the block volume.

9. The request includes a user identifier, and reserving the block volume includes: determining whether a registered block volume is assigned to a user corresponding to the user identifier; reserving the registered block volume in response to the registered block volume being assigned to the user; and reserving an empty volume from a pool of empty volumes in response to a registered block volume not being assigned to a user corresponding to the user identifier, wherein the empty volume is pre-formatted to dock with a secure cloud shell.

10. Executing the computer-executable instructions further causes the one or more processors to perform the steps of: receiving a request to restore the block volume from the session manager service; and creating a recovery volume using the backup of the block volume, the recovery volume including data stored in the block volume, the step further comprising:

10. The computer system of claim 8, further comprising returning a data center identifier for the recovery volume to the session manager service.

11. The backup of the block volume further includes an identifier of the backup, and creating the restoration volume includes: and reserving an empty block volume from a pool of empty volumes, the empty block volume being pre-formatted to dock with a secure cloud shell; and creating the restore volume further comprising: retrieving the backup of the block volume using the identifier of the backup; provisioning the empty block volume at least in part by loading the backup of the block volume onto the empty block volume; and identifying the data center identifier of the empty block volume as the data center identifier of the recovery volume.

12. 10. The computer system of claim 8, wherein executing the computer-executable instructions further causes the one or more processors to perform steps including retaining the block volume for a retention period.

13. The computer system of claim 8 , wherein creating the backup of the block volume comprises creating a disk image of the block volume.

14. Creating the backup of the block volume includes: converting the data in the block volume into object data; and storing the object data in an object storage system.

15. A computer-readable storage medium storing computer-executable instructions that, when executed, cause one or more processors of a computer system to perform steps, said steps including: The method includes receiving a request to reserve a block volume from a computer system, the request being received from a session manager service, the method further comprising: the computer system reserving the block volume; the computer system identifying a data center identifier for the block volume; the computer system returning the data center identifier for the block volume to the session manager service; the computer system attaching the block volume; receiving, by the computer system, an instruction from the session manager service to release the block volume; the computer system creating a backup of the block volume including the data stored in the block volume; and the computer system releasing the block volume.

16. The request includes a user identifier, and reserving the block volume includes: determining whether a registered block volume is assigned to a user corresponding to the user identifier; reserving the registered block volume in response to the registered block volume being assigned to the user; and reserving an empty volume from a pool of empty volumes in response to a registered block volume not being assigned to a user corresponding to the user identifier, wherein the empty volume is pre-formatted to dock with a secure cloud shell.

17. Executing the computer-executable instructions further causes the one or more processors to perform the steps of: receiving a request to restore the block volume from the session manager service; and creating a recovery volume using the backup of the block volume, the recovery volume including data stored in the block volume, the step further comprising:

16. The computer-readable storage medium of claim 15, further comprising returning a data center identifier for the recovery volume to the session manager service.

18. The backup of the block volume further includes an identifier of the backup, and creating the restoration volume includes: and reserving an empty block volume from a pool of empty volumes, the empty block volume being pre-formatted to dock with a secure cloud shell; and creating the restore volume further comprising: retrieving the backup of the block volume using the identifier of the backup; provisioning the empty block volume at least in part by loading the backup of the block volume onto the empty block volume; and identifying the data center identifier of the empty block volume as the data center identifier of the recovery volume.

19. 16. The computer-readable storage medium of claim 15, wherein executing the computer-executable instructions further causes the one or more processors to perform steps including retaining the block volume for a retention period.

20. Creating the backup of the block volume includes: converting the data in the block volume into object data; and storing the object data in an object storage system.

Images