Secure transfer of workloads across security domains

JP2024543866A5Active Publication Date: 2025-04-03ORACLE INT CORP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024529774
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2021-11-30
Filing Date
2022-04-05
Publication Date
2025-04-03
Estimated Expiration
2042-04-05

AI Technical Summary

Technical Problem

Legacy methods for transferring workloads between sensitive areas within a cloud service provider's network are completely manual, requiring physical connections and disconnections of computer systems, which is inefficient and lacks security.

Method used

A method and system for securely transferring workloads between different security realms of a cloud service provider using signature verification and encryption, enabling direct transfer over a private network connection without physical intervention.

Benefits of technology

Facilitates efficient and secure transfer of workloads between sensitive areas by verifying signatures and encrypting data, ensuring authorized transfers and maintaining data integrity and security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A framework for transferring workloads between security domains of an infrastructure service, e.g., a technique for transferring workloads between security domains over a private network based on signatures associated with the security domains.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] Related Articles This application claims priority to U.S. patent application Ser. No. 17 / 538,853, entitled "SECURE TRANSFER OF WORKLOADS ACROSS SECURITY REGIONS," filed Nov. 30, 2021, the disclosure of which is incorporated by reference in its entirety herein. [Background technology]

[0002] background Cloud service providers (CSPs) use different systems and infrastructure services to provide a variety of services to users or customers as desired. CSPs provide infrastructure services that customers can use to build their own networks and deploy customer resources. In some cases, customers can utilize a CSP to define one or more secure domains for their own networks.

[0003] The legacy approach for transferring a workload between security domains within a CSP is entirely manual. In particular, a user is required to physically connect a computer system to a first security domain from which the workload is to be transferred. The user copies the workload from the first security domain to the computer system and then disconnects the workload from the first security domain. The user then physically connects the computer system to a second security domain to which the workload is to be transferred. The user then uploads the workload to the second security domain. Summary of the Invention

[0004] overview The present disclosure generally relates to a framework for transferring workloads and / or other data between sensitive domains. Various embodiments are described herein, such as methods, systems, non-transitory computer-readable storage media storing programs, codes, or instructions executable by one or more processors, and the like. These illustrative embodiments are described not to limit or define the present disclosure, but to provide examples to aid in its understanding. Additional embodiments are discussed in the Detailed Description section, and further descriptions are provided herein. [Means for solving the problem]

[0005] One aspect of the present disclosure is directed to a method for providing a workload from a first security domain of a cloud service provider (CSP) to a second security domain of the cloud service provider. The method may include a device receiving a workload from the first security domain and the device verifying one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with the second security domain. The method may further include the device encrypting the workload based at least in part on the one or more signatures of the workload being verified, and the device transmitting the encrypted workload to the second security domain.

[0006] One aspect of the disclosure is directed to one or more computer-readable media having instructions stored thereon that, when executed by a network, cause a device of the network to receive a workload from a first security domain of a cloud service provider (CSP) and for the device to verify one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with a second security domain. The instructions, when executed by the network, may further cause the network to encrypt the workload based at least in part on the one or more signatures of the workload being verified and to transmit the encrypted workload to the second security domain of the cloud service provider.

[0007] One aspect of the disclosure is directed to one or more computer-readable media having stored thereon instructions that, when executed by one or more processors, cause a network-connected device to: receive a workload from a first security domain of a cloud service provider (CSP); and verify one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with a second security domain. The instructions, when executed by the one or more processors, may further cause the device to encrypt the workload based at least in part on the one or more signatures of the workload being verified; and transmit the encrypted workload to the second security domain of the cloud service provider.

[0008] One aspect of the disclosure is directed to a private network including a private network connection connected between a first security domain of a cloud service provider (CSP) and a second security domain of the cloud service provider, and a device coupled to the private network connection and located in the first security domain. The device may receive a workload from the first security domain and verify one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with the second security domain. The device may further encrypt the workload based at least in part on the one or more signatures of the workload being verified and transmit the encrypted workload to the second security domain.

[0009] One aspect of the present disclosure is directed to a private network system including a private network connection connected between a first security domain of a cloud service provider (CSP) and a second security domain of the cloud service provider, and a device coupled to the private network connection and located in the first security domain. The device may receive a workload from the first security domain and verify one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with the second security domain. The device may further encrypt the workload based at least in part on the one or more signatures of the workload being verified and transmit the encrypted workload to the second security domain.

[0010] The foregoing, together with other features and embodiments, will become more apparent with reference to the following specification, claims, and accompanying drawings.

[0011] The features, embodiments, and advantages of the present disclosure will be better understood when the following detailed description is read in conjunction with the accompanying drawings. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 illustrates an example system deployment, according to some embodiments. [Diagram 2] FIG. 2 illustrates another example system arrangement, according to some embodiments. [Diagram 3] FIG. 1 illustrates an example procedure for providing a workload from a first security domain of a cloud service provider (CSP) to a second security domain of the CSP, according to some embodiments. [Figure 4] FIG. 1 illustrates another example procedure for providing workload from a first security domain of a CSP to a second security domain of a CSP, according to some embodiments. [Diagram 5] FIG. 1 illustrates another example procedure for providing workload from a first security domain of a CSP to a second security domain of a CSP, according to some embodiments. [Figure 6] 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 7] 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 8] 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 9] 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 10] FIG. 1 is a block diagram illustrating an example computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Detailed Description In the following description, for purposes of explanation, specific details are set forth to provide a thorough understanding of certain embodiments. It will be apparent, however, that various embodiments may be implemented without these specific details. The figures and descriptions are not intended to be limiting. The term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0014] This disclosure describes techniques for transferring workloads and / or other data (referred to throughout as simply "workload") between sensitive domains of an infrastructure (cloud infrastructure services, such as the cloud infrastructure of FIG. 6, the cloud infrastructure of FIG. 7, the cloud infrastructure of FIG. 8, and / or the cloud infrastructure of FIG. 9) provided by a cloud service provider (CSP). More specifically, to transfer a workload between sensitive domains (which may be referred to as security domains), a device in the sensitive domain may verify that the workload to be transferred between the sensitive domains has a signature corresponding to an appropriate authorizer that provides authorization for the transfer of the workload between the sensitive domains. Based on the device verifying that the workload has the appropriate signature, the device may facilitate the transfer of the workload between the sensitive domains.

[0015] A CSP may provide various services to customers as desired using different systems and infrastructure services (referred to herein as cloud infrastructure services). In one embodiment, a CSP may provide services under an Infrastructure-as-a-Service (IaaS) model, where the CSP provides infrastructure services that customers may use to build their own networks and deploy customer resources. The infrastructure provided by a CSP may include interconnected high-performance computing resources, including various host machines (also referred to as hosts), memory resources, and network resources that form a physical network referred to as a substrate network or underlying network. The infrastructure provided by a CSP may be distributed across one or more data centers that may be geographically distributed across one or more regions.

[0016] The CSP's physical network, which may include various host machines, memory resources, and / or network resources, may provide an underlying foundation for creating one or more virtual or overlay networks on top of the physical network. These virtual or overlay networks (also referred to as software-based or software-defined networks) may be implemented using software virtualization techniques to create a layer of network abstraction that may run on top of the physical network. Overlay networks may take many forms. Overlay networks may use Layer-3 IP addressing, with endpoints specified by their virtual IP addresses. Such methods of overlay networking are often referred to as virtual Layer 3 networking.

[0017] When a customer subscribes or registers for an IaaS service offered by a CSP, a tenancy is created for that customer; the tenancy is a secure and isolated compartment within the CSP's infrastructure service where the customer can create, organize, and manage their cloud resources. For example, the customer may use the resources offered by the CSP to build one or more customizable and private virtual networks, called virtual cloud networks (VCNs), within the customer's tenancy. One or more customer resources, such as compute instances (e.g., virtual machines, bare metal instances, etc.), may be deployed on these customer VCNs.

[0018] In some cases, a customer may establish a customer VCN with one or more confidential areas. The confidential areas may provide a high level of security for workloads and / or other data that may be classified as confidential or top secret. Each of the confidential areas may have at least one corresponding device that restricts the transfer of workloads and / or other data using the confidential area. To provide for the transfer of workloads and / or other data using the confidential area in accordance with embodiments disclosed herein, a device corresponding to the confidential area may verify that the workload and / or other data to be transferred has at least one signature corresponding to an authorizer associated with the originating confidential area and at least one signature corresponding to an authorizer associated with the destination confidential area before allowing the transfer of the workload and / or other data.

[0019] FIG. 1 illustrates an example system arrangement 100 according to some embodiments. In particular, the system arrangement 100 illustrates portions of infrastructure services and customer equipment that may implement one or more of the techniques for transferring workloads and / or other data between security domains (which may also be referred to as sensitive domains) described throughout this disclosure. In some embodiments, the infrastructure services may include one or more features of the cloud infrastructure of FIG. 6, the cloud infrastructure of FIG. 7, the cloud infrastructure of FIG. 8, and / or the cloud infrastructure of FIG. 9. The infrastructure services may comprise computing systems. In some embodiments, the infrastructure services may comprise cloud computing systems. The infrastructure services may include infrastructure hardware and / or software that may provide services for clients. In some embodiments, the customer equipment may include one or more customer elements (such as customer computer systems) that may be implemented within a customer VCN.

[0020] System arrangement 100 may include one or more security domains. For example, system arrangement 100, in the illustrated embodiment, includes a first security domain 102 and a second security domain 104. For brevity and clarity, the following description refers to first security domain 102 and second security domain 104, but it should be understood that other security domains in other embodiments of system arrangement 100 may include one or more of the features of first security domain 102 and / or second security domain 104.

[0021] Each of the first security realm 102 and the second security realm 104 may correspond to a different geographic area. For example, the first security realm 102 may correspond to a first geographic area and the second security realm 104 may correspond to a second geographic area, the second geographic area being different from the first geographic area. In some embodiments, the geographic area may be defined by a continent, a geographic region, a country, a state, a building (which may be represented by an address), a portion of a building (such as a room), a computing system (such as a server corresponding to the area), or a portion of a computing system (such as a storage location corresponding to the area). Furthermore, the first security realm 102 may be located in a first realm and the second security realm 104 may be located in a second realm, which is different from the first realm, in some embodiments. Each realm may include one or more areas.

[0022] Each of the first security domain 102 and the second security domain 104 may provide a higher level of security than a non-security domain. For example, the security domain may not be connected to a public network, such as the Internet. In some embodiments, the security domains may be air-gapped, and each of the security domains may be physically isolated from the public network. In contrast, the security domains may be connected to a private network, which may prevent public access to the private network, thereby preventing hacking or other unauthorized activity from public entities. Additionally, the workloads and / or data stored within the secure are encrypted according to security standards, such as the Commercial National Security Algorithm (CNSA) standard.

[0023] The first security realm 102 may include a customer resource tenancy 106. The customer resource tenancy 106 may include a secure and isolated partition of infrastructure services. A customer may be able to create, organize, and manage cloud resources within the customer resource tenancy 106. For example, the customer resource tenancy 106 may store workloads as they are transferred from a customer subnet into a realm. Thus, the customer resource tenancy 106 may comprise a secure and isolated partition of infrastructure services in which workloads are stored as they are provided by the customer.

[0024] The customer resource tenancy 106 may include a customer virtual cloud network 108. The customer virtual cloud network 108 may comprise a virtual private network that may be established in one or more data centers. The customer virtual cloud network 108 may have firewall rules and / or communication gateways that may protect resources in the customer resource tenancy 106 and facilitate transfer of resources.

[0025] The first security realm 102 may further include a dynamic routing gateway 110. The dynamic routing gateway 110 may be coupled to the customer virtual cloud network 108 and may facilitate the transfer of workloads and / or resources with the customer resource tenancy 106. For example, the dynamic routing gateway 110 may comprise a virtual router that may be utilized to connect the customer virtual cloud network 108 to one or more other networks or network elements.

[0026] The second security domain 104 may include a customer replica tenancy 112. The customer replica tenancy 112 may include a secure and isolated partition of infrastructure services. The secure and isolated partition corresponding to the customer replica tenancy 112 may be separate from the secure and isolated partition corresponding to the customer resource tenancy 106. A customer may be able to create, organize, and manage cloud resources within the customer replica tenancy 112. For example, the customer replica tenancy 112 may store workloads for load balancing, disaster recovery, and high availability needs. Thus, the customer replica tenancy 112 may include a secure and isolated partition of infrastructure services, where workloads are stored for load balancing, disaster recovery, and high availability needs.

[0027] The customer replication tenancy 112 may include a customer virtual cloud network 114. The customer virtual cloud network 114 may comprise a virtual private network that may be set up in one or more data centers. The customer virtual cloud network 114 may have firewall rules and / or communication gateways that may protect resources in the customer replication tenancy 112 and facilitate the transfer of resources.

[0028] The second security realm 104 may further include a dynamic routing gateway 116. The dynamic routing gateway 116 may be coupled to the customer virtual cloud network 114 and may facilitate the transfer of workloads and / or resources with the customer replication tenancy 112. For example, the dynamic routing gateway 116 may comprise a virtual router that may be utilized to connect the customer virtual cloud network 114 to one or more other networks or network elements.

[0029] The system arrangement 100 may further include customer equipment 118. The customer equipment 118 may comprise computer equipment maintained and / or operated by a customer. The customer equipment 118 may include customer networks. In the illustrated embodiment, the customer networks are shown as a first customer network 120 and a second customer network 122. The customer networks may comprise private networks. For example, the customer networks may utilize private addresses of IP addresses and Internet Protocol version 4 (IPv4) and / or Internet Protocol version 6 (IPv6) specifications may be supported. The customer networks may be separate from the public network.

[0030] The first customer network 120 may correspond to the first security domain 102. The first customer network 120 may include a first device 126. The first device 126 may be located in the first security domain 102 and may manage the transmission of workload and / or other data using the first security domain 102. In particular, the first device 126 may limit the transmission of workload and / or other data using the first security domain 102 to authorized transmissions. In some embodiments, the first device 126 may comprise a first encryption device. The first encryption device may comprise computer hardware capable of verifying authorization of the transfer of the workload and / or other data using the first security domain 102. For example, the first encryption device may verify that the workload and / or other data has one or more signatures (or other authentication information) indicating that the workload and / or other data is authorized for transfer. The first encryption device may also encrypt or decrypt the workload and / or other data being transferred using the first security domain 102. In some embodiments, a first encryption device may be associated with a customer and may enable transfer of workload and / or other data only with other encryption devices associated with the customer.

[0031] The second customer network 122 may correspond to the second security domain 104. The second customer network 122 may include a second device 128. The second device 128 may be located in the second security domain 104 and may manage the transmission of workload and / or other data using the second security domain 104. In particular, the second device 128 may limit the transmission of workload and / or other data using the second security domain 104 to authorized transmissions. In some embodiments, the second device 128 may comprise a second encryption device. The second encryption device may comprise computer hardware capable of verifying authorization of the transfer of the workload and / or other data using the second security domain 104. For example, the second encryption device may verify that the workload and / or other data has one or more signatures (or other authentication information) indicating that the workload and / or other data is authorized for transfer. The second encryption device may also encrypt or decrypt the workload and / or other data being transferred using the second security domain 104. In some embodiments, the second encryption device may be associated with a customer and may enable transfer of workload and / or other data only with other encryption devices associated with the customer. In the illustrated embodiment, the second device 128 may be coupled to the first device 126, thereby enabling transfer of workload and / or other data between the first security domain 102 and the second security domain 104.

[0032] The customer equipment 118 may further include a customer on-premise subnet 124. The customer on-premise subnet 124 may comprise a subnet with elements located at the customer's premises. The customer on-premise subnet 124 may include a customer device 130, a customer on-premise network 132, and / or a third device 134. The customer device 130 may comprise a computing device having a user interface with which a customer may interact to perform operations with the customer on-premise subnet 124. The customer device 130 may be coupled to a customer on-premise network 132. The customer on-premise network 132 may be formed by one or more devices of the customer. The customer on-premise network 132 may comprise a private network. The customer device 130 may be further coupled to a customer resource tenancy 106 and / or a customer replication tenancy 112. The customer device 130 may communicate with the customer resource tenancy 106 and / or the customer replication tenancy 112 and may request the customer resource tenancy 106 and / or the customer replication tenancy 112 to perform one or more operations.

[0033] The customer on-premise subnet 124 may further include a third device 134. The third device 134 may be coupled to the customer on-premise network 132 and may manage the transmission of workload and / or other data with the customer on-premise network 132. In particular, the third device 134 may limit the transmission of workload and / or other data with the customer on-premise network 132 to authorized transmissions. In some embodiments, the third device 134 may comprise a third encryptor. The third encryptor may comprise computer hardware capable of verifying authorization of the transfer of the workload and / or other data with the customer on-premise network 132. For example, the third encryptor may verify that the workload and / or other data has one or more signatures (or other authentication information) indicating that the workload and / or other data is authorized for transfer. The third encryptor may also encrypt or decrypt the workload and / or other data being transferred with the customer on-premise network 132. In some embodiments, the third encryptor may be associated with a customer and may enable the transfer of the workload and / or other data only with other encryptors associated with the customer. In the illustrated embodiment, the third device 134 may be coupled to the first device 126, which may enable transfer of workload and / or other data between the customer on-premise network 132 and the first security domain. In other embodiments, the third device 134 may be coupled to the second device 128, or to the first device 126 and the second device 128.

[0034] A customer may utilize a customer device 130 to store one or more workloads and / or other data in the first security domain 102. For example, the one or more workloads and / or other data may be provided to the first security domain 102 via a third device 134 and the first device 126. The third device 134 may encrypt the one or more workloads and / or other data from the customer device 130 and provide the workloads and / or other data to the first device 126. The first device 126 may decrypt the workloads and / or other data and provide the workloads and / or other data to the dynamic routing gateway 110 for storage in the customer resource tenancy 106.

[0035] A customer may wish to transfer one or more of a workload and / or other data from a first security domain 102 to a second security domain 104, or vice versa. However, the first security domain 102 and the second security domain 104 may not have trust with each other for the transfer of the workload and / or other data. However, the customer may implement the techniques described herein to provide trust between the first security domain 102 and the second security domain 104 for the transfer of the workload and / or other data. For brevity, the following description is directed to the transfer of a workload from the first security domain 102 to the second security domain 104. It should be understood that the techniques described may be applied to the transfer of one or more workloads and / or other data, as well as the transfer from the second security domain 104 to the first security domain 102.

[0036] To provide trust between the first security realm 102 and the second security realm 104, a first authorizer associated with the first security realm 102 and a second authorizer associated with the second security realm 104 may provide authorization for the transfer of the workload. The first device 126 and the second device 128 may be configured to verify that the first authorizer and the second authorizer have provided authorization for the transfer of the workload before the workload is transferred. For example, a customer may utilize the customer device 130 to configure the first device 126 and the second device 128 to verify that the workload, the customer replicated tenancy 112, and / or an object store within the customer replicated tenancy 112 are signed with at least one signature corresponding to the first authorizer and at least one signature corresponding to the second authorizer. The signature corresponding to the first authorizer may be associated with the first security realm 102, and the signature corresponding to the second authorizer may be associated with the second security realm 104. In the illustrated embodiment, the customer device 130 may transmit a request to the first device 126 and the second device 128 via the customer on-premise network 132 and the third device 134 to be configured to verify the signature of the workload. In some embodiments, the request may include an indication of the signature for verification, an indication of a source realm (which in the illustrated case is the first security realm 102), an indication of a destination realm (which in the illustrated case is the second security realm), an indication of a first authorizer associated with the first security realm 102, an indication of a second authorizer associated with the second security realm 104, an indication of a user authorized to access the workload, or some combination thereof. In some embodiments, the request may include a policy statement indicating the signature for verification, the source realm for which the signature provides authorization, the destination realm for which the signature provides authorization, or some combination thereof.In some embodiments, the signatures may be provided by the first and second authorizers, or by other individuals associated with the first and second security realms 102 and 104. The customer or customer device 130 may obtain the signatures from the first and second authorizers, and / or individuals via telephone, email, electronic, or other communication.

[0037] A customer may request a transfer of a workload from the first security domain 102 to the second security domain 104 via a customer device 130. Based on the request, the customer device 130 may determine whether authorization has been received from the first authorizer and the second authorizer for the transfer of the workload. If the customer device 130 determines that authorization for the transfer of the workload has been received from the first authorizer and the second authorizer, the customer device 130 may sign the workload, the customer replica tenancy 112, and / or an object store within the customer replica tenancy 112. If the customer device 130 determines that authorization has not been received for the transfer of the workload, the customer device 130 and / or the customer may communicate (e.g., via telephone communication, email, electronic communication, or another communication) with the first authorizer and the second authorizer to determine whether the first authorizer and the second authorizer grant authorization for the transfer of the workload. The customer device 130 and / or the customer may decide to grant authorization based on the responses from the first and second authorizers. In some cases, the responses granting authorization from the first and second authorizers may include signatures corresponding to the first and second authorizers. If the first and second authorizers grant authorization, the customer device 130 may sign, or the customer may have the customer device 130 sign, the workload, the customer replica tenancy, and / or the object store.

[0038] Based on the request to transfer the workload, the first device 126 and the second device 128 may verify that the workload, the customer replication tenancy 112, and / or the object store have a signature corresponding to the first authorizer and the second authorizer when transferring the workload. For example, the customer resource tenancy 106 may provide the workload to the dynamic routing gateway 110, which in turn provides the workload to the first device 126. Upon receiving the workload, the first device 126 may verify that the workload is signed with a signature corresponding to the first authorizer and the second authorizer. If the first device 126 determines that the workload does not have a signature, the first device 126 may prevent the workload from being transferred. If the first device 126 determines that the workload has a signature, the first device 126 may encrypt the workload. The first device 126 may transmit the encrypted workload to the second device 128 over a connection 136. The connection 136 may be a private network connection provided by the customer's private network. Upon receiving the encrypted workload, the second device 128 may verify that the encrypted workload has a signature corresponding to the first authorizer and the second authorizer. In some embodiments, the second device 128 may further verify that the customer replicated tenancy 112 and / or the object store are signed with a signature corresponding to the first authorizer and the second authorizer. In some of these embodiments, the second device 128 may compare the signature of the workload to the signature of the customer replicated tenancy 112 and / or the object store to determine whether the signatures match. If the second device 128 determines that the signature is properly verified (either by the workload having a signature and / or the signature of the workload matching a signature in the customer replication tenancy and / or object store), the second device 128 may decrypt the encrypted workload.The second device 128 may provide the decrypted workload to the dynamic routing gateway 116, which provides the workload to the customer replication tenancy 112 for storage.

[0039] The techniques described above may allow a workload to be transferred from a first security domain 102 to a second security domain 104 without having to manually connect and disconnect computers to transfer the workload. Thus, the workload may be transferred directly from the first security domain 102 to the second security domain 104. Furthermore, encrypting the workload as it is transferred and utilizing a private network for the transfer may result in a secure transfer of the workload. The techniques described herein may result in an efficient and secure transfer of the workload.

[0040] Although the details of the elements in system arrangement 100 are not explicitly discussed, it should be understood that one or more of the elements in system arrangement 100 may comprise computer components that facilitate the operations performed by the elements. For example, one or more of customer virtual cloud network 108, dynamic routing gateway 110, first device 126, second device 128, third device 134, customer on-premise network 132, dynamic routing gateway 116, and customer virtual cloud network 114 may include one or more processors capable of executing instructions to cause the elements to perform functions.

[0041] FIG. 2 illustrates another example system arrangement 200 according to some embodiments. In particular, the system arrangement 200 illustrates portions of infrastructure services and customer equipment that may implement one or more of the techniques for transferring workloads and / or other data between security domains (which may also be referred to as sensitive domains) described throughout this disclosure. In some embodiments, the infrastructure services may include one or more features of the cloud infrastructure of FIG. 6, the cloud infrastructure of FIG. 7, the cloud infrastructure of FIG. 8, and / or the cloud infrastructure of FIG. 9. The infrastructure services may comprise computing systems. In some embodiments, the infrastructure services may comprise cloud computing systems. The infrastructure services may include infrastructure hardware and / or software that may provide services for clients. In some embodiments, the customer equipment may include one or more customer elements (such as customer computer systems) that may be implemented within a customer VCN.

[0042] The system arrangement 200 may include a first realm 202 and a second realm 204. The first realm 202 and the second realm 204 may each be a tightly restricted application environment within an infrastructure service that prevents access to application data while allowing authorized management activities. The first realm 202 and the second realm 204 may be independent of each other, such that operations and / or data within the first realm 202 are not dependent on operations and / or data within the second realm 204 and vice versa. The first realm 202 may be isolated from a public network, such as the Internet. The first realm 202 may be part of an air-gapped network, such that the first realm 202 is physically isolated from the public network. Additionally, the second realm 204 may be part of an air-gapped network, such that the second realm 204 is physically isolated from the public network. The first realm 202 and the second realm 204 may be part of the same air-gapped network or may be part of separate air-gapped networks.

[0043] The first realm 202 may include a first security realm 206. The first security realm 206 may include one or more of the features of the first security realm 102 (FIG. 1). The first security realm 206 may store one or more workloads, such as workload 208. Each workload may include a set of data to be operated on. Each workload may have an identifier, which may be utilized to identify the workload. The first security realm 206 may be associated with a customer, and the workloads stored within the first security realm 206 may be associated with the customer.

[0044] The second realm 204 may include a second security domain 210. The second security domain 210 may include one or more of the features of the second security domain 104 (FIG. 1). The second security domain 210 may be associated with a customer. In some cases, the customer may wish to transfer one or more workloads from the first security domain 206 to the second security domain 210. For example, the customer may wish to transfer a workload from the first security domain 206 to an object store, e.g., object store 212, in the second security domain 210. However, due to the security of the first realm 202 and the second realm 204 (e.g., each of the first realm 202 and the second realm 204 being part of an air-gapped network), the first realm 202 and the second realm 204 may not allow for direct transfer of a workload via legacy techniques.

[0045] The system arrangement 200 may include a first device 214, a private network connection 216, and a second device 218 that provide connectivity between a first realm 202 and a second realm 204. In particular, the first device 214, the private network connection 216, and the second device 218 may form a private network connection between the first realm 202 and the second realm 204. The private network connection may facilitate the transfer of workload between the first realm 202 and the second realm 204.

[0046] The first device 214 may include one or more of the features of the first device 126 (FIG. 1), such as being an encryption device in some embodiments. The first device 214 may be located in the first realm 202 and / or the first security domain 206. The first device 214 may limit transmissions with the first realm 202 and / or the first security domain 206 to authorized transmissions. For example, the first device 214 may verify that a transmission between the first realm 202 and / or the first security domain 206 and another device has authorization before allowing the transmission. For transmissions that are authorized, the first device 214 may encrypt and / or decrypt the transfer.

[0047] The second device 218 may include one or more of the features of the second device 128 (FIG. 1), such as being an encryption device in some embodiments. The second device 218 may be located in the second realm 204 and / or the second security realm 210. The second device 218 may limit transmissions with the second realm 204 and / or the second security realm 210 to authorized transmissions. For example, the second device 218 may verify that a transmission between the second realm 204 and / or the second security realm 210 and another device has authorization before allowing the transmission. For transmissions that are authorized, the second device 218 may encrypt and / or decrypt the transfer.

[0048] The system arrangement 200 may include a customer device 220. The customer device 220 may include one or more features of the customer device 130 (FIG. 1). The customer device 220 may be coupled to the first device 214 and / or the second device 218. The customer device 220 may configure the first device 214 and / or the second device 218 as to which transmissions should be permitted. For example, the customer device 220 may provide a policy statement to the first device 214 and / or the second device 218 that specifies which transmissions are authorized to be transferred. The policy statement may indicate one or more signatures indicating authorization for the transfer of the workload. In some embodiments, the policy statement may further indicate the realms and / or regions to which the workload is authorized to be transferred. In some embodiments, an indication of the realms and / or regions may be associated with a corresponding signature, e.g., the signature indicates that the workload is authorized for transmission between the indicated realms and / or regions.

[0049] The customer device 220 may further be coupled to the first realm 202 and / or the second realm 204. In some embodiments, a device (such as the third device 134) may be coupled at the customer device 220 between the customer device and the first realm 202 and / or the second realm 204. The customer device 220 may provide a request to the first realm 202 and / or the second realm 204 to transfer a workload between the first realm 202 and the second realm 204. For example, the customer device 220 may request a one-time transfer of a workload between the first realm 202 and the second realm 204 and / or set up a recurring transfer for a certain default workload. In the illustrated embodiment, the customer device 220 may request that a workload 208 be transferred from the first realm 202 to the second realm 204, such as for storage in the object store 212.

[0050] Customer device 220 may further sign or cause to be signed the workload and / or object store. For example, customer device 220 may, in the illustrated embodiment, sign or cause to be signed the workload 208 and / or object store 212, and the signature may indicate that the workload 208 is authorized to be transferred. Customer device 220 may sign the workload 208 and / or object store 212 based on indications from first authorizer 222 and second authorizer 224 indicating that the transfer of the workload 208 is authorized. First authorizer 222 may be associated with first realm 202, and second authorizer 224 may be associated with second realm 204. In particular, the first authorizer 222 may be an individual and / or device that can provide authorization for transfers with the first realm 202, and the second authorizer 224 may be an individual and / or device that can provide authorization for transfers with the second realm 204. For example, the customer device 220, or a customer using the customer device 220, may determine whether authorization for the transfer of the workload 208 was previously received from the first authorizer 222 and the second authorizer 224. If authorization was previously received, the customer device 220 may sign or cause to be signed the workload 208 and / or the object store 212.

[0051] If authorization has not been previously received, the customer device 220 may request authorization from the first authorizer 222 and the second authorizer 224, or may indicate to the customer that authorization needs to be requested from the first authorizer 222 and the second authorizer 224. The request for authorization given to the first authorizer 222 and the second authorizer 224 may include an indication of the workload 208, an indication of the source realm from which the workload 208 is to be transferred, an indication of the destination realm to which the workload 208 is to be transferred, or some combination thereof. In some cases, the request may further indicate a security level of the workload 208 (such as confidential or top secret). The first authorizer 222 and the second authorizer 224 may respond to the request with whether the transfer of the workload is authorized. If the customer device 220 determines that both the first authorizer 222 and the second authorizer 224 have indicated that the transfer is authorized, the customer device 220 may sign or cause to be signed the workload 208 and / or the object store 212.

[0052] The signature applied to the workload 208 may provide information that the workload 208 is authorized to be transferred to. For example, the signature may indicate a source realm from which the workload 208 is authorized to be transferred and a destination realm to which the workload 208 is authorized to be transferred. In the illustrated case, the signature may indicate that the workload 208 is authorized to be transferred from the first realm 202 to the second realm 204. In some embodiments, the signature may also indicate who authorized the signature to be applied to the workload 208 and / or the object store 212, and / or users in the second realm 204 that will be authorized to access when transferred to the second security realm 210. For example, the signature may indicate that the first authorizer 222 and the second authorizer 224 authorized the workload 208 to be transferred.

[0053] Based on a request from the customer device 220 to transfer the workload 208, the first security domain 206 may provide the workload 208 to the first device 214 for transfer to the second security domain 210. The first device 214 may verify that the workload 208 has an appropriate signature indicating that the workload 208 is authorized to be transferred to the second security domain 210. In particular, the first device 214 may utilize a policy statement that configures the first device 214 to determine whether the workload 208 has an appropriate signature indicating that the workload is authorized for transfer from the first security domain 206 to the second security domain 210. For example, the policy statement may cause the first device 214 to verify that the signature indicates that the first authorizer 222 and the second authorizer 224 have indicated that the workload 208 is authorized for transfer. In some embodiments, the policy statement may further cause the first device 214 to verify, based on a signature of the workload 208, that the workload 208 is authorized to be transferred from the first realm 202, that the workload 208 is authorized to be transferred to the second realm 204, or a combination thereof. If the first device 214 determines that the workload 208 does not have a proper signature for authorization, the first device 214 may prevent the workload 208 from being transmitted to the second realm 204. If the first device 214 determines that the workload 208 has a proper signature for authorization, the first device 214 may encrypt the workload and transmit the encrypted workload 208 to the second device 218 over the private network connection 216.

[0054] Based on the second device 218 receiving the encrypted workload 208, the second device 218 may verify that the encrypted workload 208 and / or the object store 212 have an appropriate signature for authorization of the transfer of the workload 208. For example, the second device 218 may utilize a policy statement that configures the second device 218 to determine whether the encrypted workload 208 and / or the object store 212 have an appropriate signature indicating that the workload is authorized for transfer from the first security domain 206 to the second security domain 210. For example, the policy statement may cause the second device 218 to verify that the signature of the encrypted workload 208 and / or the object store 212 indicates that the first authorizer 222 and the second authorizer 224 have authorized the transfer of the workload 208. In some embodiments, the policy statement may further cause the first device 214 to verify, based on the signature of the encrypted workload 208 and / or the object store 212, that the workload 208 is authorized to be transferred from the first realm 202, that the workload 208 is authorized to be transferred to the second realm 204, or a combination thereof. Additionally, the policy statement may cause the second device 218 to compare the signature of the encrypted workload 208 with the signature match of the object store 212 to verify that the workload 208 is authorized for transfer from the first security realm 206 to the second security realm 210. If the second device 218 determines that the encrypted workload 208 does not have the proper signature for authorization, the second device 218 may prevent the encrypted workload 208 from being provided to the second realm 204. If the second device 218 determines that the encrypted workload 208 has the appropriate signature for authorization, the second device 218 may decrypt the workload and provide the decrypted workload to a second security domain for storage in the object store 212.

[0055] Although details of the elements in system arrangement 200 are not explicitly discussed, it should be understood that one or more of the elements in system arrangement 200 may comprise computer components that facilitate operations performed by the elements. For example, one or more of the network (such as an air-gapped network), first device 214, second device 218, customer device 220, first authorizer 222, and second authorizer 224 described in connection with system arrangement 200 may include one or more processors capable of executing instructions to cause the elements to perform functions.

[0056] FIG. 3 illustrates another exemplary procedure 300 for providing a workload from a first security domain of a CSP to a second security domain of a CSP, according to some embodiments. The process (e.g., procedure 300) is illustrated as a logic flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement a process. Procedure 300 may be performed by a customer equipment (such as customer equipment 118 (FIG. 1)) or any portion thereof. For example, the procedure 300 may be performed by one or more devices (such as the first device 126 (FIG. 1), the second device 128 (FIG. 2), the first device 214 (FIG. 2), and / or the second device 218 (FIG. 2)).

[0057] At 302, a customer equipment may receive a workload (e.g., workload 208 (FIG. 2)) from a first security realm (e.g., first security realm 102 (FIG. 1) and / or first security realm 206 (FIG. 2)). In particular, a device of the customer equipment (e.g., first device 126 and / or first device 214) may receive a workload from the first security realm. The device may be part of a private network. Furthermore, the device may be located in the first security realm. For example, the device may be connected in a first security realm connection that may be used for the transfer of the workload with the first security realm. The first security realm may be located in a first realm (e.g., first realm 202 (FIG. 2)). The first security realm may further be part of a first air-gapped network.

[0058] At 304, the customer equipment may verify the one or more signatures. In particular, the device may verify the one or more signatures of the workload. For example, the workload may be signed with one or more signatures. The one or more signatures may include at least one signature associated with a first security domain and at least one signature associated with a second security domain. The device may verify that the one or more signatures authorize the transfer of the workload from the first security domain to the second security domain.

[0059] At 306, the customer equipment may encrypt the workload. In particular, the device may encrypt the workload based at least in part on one or more signatures of the workload being verified.

[0060] At 308, the customer equipment may transmit the encrypted workload. In particular, the device may transmit the encrypted workload to a second security domain. In some embodiments, transmitting the encrypted workload may include transmitting the encrypted workload to the second security domain over a private network connection. The second security domain may be part of a second air-gapped network in some embodiments. In these embodiments, the device may transmit the encrypted workload from the first air-gapped network to the second air-gapped network. Furthermore, the second security domain may be located in a second realm (such as second realm 204 (FIG. 2)) in some embodiments. Transmitting the encrypted workload may include transmitting the encrypted workload over a private network to a second device (such as second device 128 and / or second device 218). The second device may be located in the second security domain. The second device may be part of a private network, which may be the same private network that includes the device.

[0061] At 310, the customer equipment may receive the encrypted workload. In particular, a second device of the customer equipment may receive the encrypted workload transmitted by the device. In some embodiments, 310 may be omitted.

[0062] At 312, the customer equipment may verify the one or more signatures. In particular, the second device may verify the one or more signatures of the workload. The second device may verify that the one or more signatures authorize the transfer of the workload from the first security domain to the second security domain. In some embodiments, 312 may be omitted.

[0063] At 314, the customer equipment may decrypt the encrypted workload. In particular, the second device may decrypt the encrypted workload based at least in part on the one or more signatures being verified by the second device. In some embodiments, 314 may be omitted.

[0064] At 316, the customer equipment may provide the workload to the second security domain. In particular, the second device may provide the workload to the second security domain. The second device may provide the workload to the second security domain for storage within the second security domain. In some embodiments, 316 may be omitted.

[0065] FIG. 4 illustrates another exemplary procedure 400 for providing a workload from a first security domain of a CSP to a second security domain of a CSP, according to some embodiments. The process (e.g., procedure 400) is illustrated as a logic flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement the process. Procedure 400 may be performed by a network (such as customer equipment 118 (FIG. 1)) or any portion thereof. For example, the procedure 400 may be performed by one or more devices, such as the first device 126 (FIG. 1), the second device 128 (FIG. 2), the first device 214 (FIG. 2), and / or the second device 218 (FIG. 2).

[0066] At 402, the network may configure a device (such as first device 126 and / or first device 214) for validation. In particular, the network may configure the device with one or more signatures for validation of one or more signatures of a workload. For example, the device may be configured to validate that a workload transferred to or from a first security domain (such as first security domain 102 (FIG. 1) and / or first security domain 206 (FIG. 2)) is authorized for transfer based on the one or more signatures. In some embodiments, the device may be located in the first security domain. The device may be part of a private network in some embodiments. Additionally, the device may include a cryptographic device in some embodiments. In some embodiments, 402 may be omitted.

[0067] At 404, the network may configure a second device (such as second device 128 and / or second device 218) for validation. In particular, the network may configure the second device with one or more signatures for validation of one or more signatures of the workload. For example, the second device may be configured to validate that a workload transferred to or from a second security domain (such as second security domain 104 (FIG. 1) and / or second security domain 210 (FIG. 2)) is authorized for transfer based on the one or more signatures. In some embodiments, the second device may be located in the second security domain. The second device may be part of a private network in some embodiments, which may be the same private network that includes the device. Additionally, the second device may comprise a second encryption device in some embodiments. In some embodiments, 404 may be omitted.

[0068] At 406, the network may receive a workload from a first security realm. In particular, the network may receive a workload from a first security realm of a CSP via a device of the network. In some embodiments, the first security realm may be part of a first air-gapped network. Further, the first security realm may be located within a first realm (such as first realm 202 (FIG. 2)) in some embodiments.

[0069] At 408, the network may verify one or more signatures. In particular, the network may verify one or more signatures of the workload via the device. The one or more signatures may include at least one signature associated with a first security domain and at least one signature associated with a second security domain.

[0070] At 410, the network may encrypt the workload. In particular, the network may encrypt the workload based at least in part on one or more signatures of the workload being verified via the device.

[0071] At 412, the network may transmit the encrypted workload. In particular, the network may transmit the encrypted workload via the device to a second security domain of the CSP. The second security domain may be part of a second air-gapped network. In some embodiments, transmitting the encrypted workload may include transmitting the encrypted workload over a private network connection.

[0072] The network may receive the encrypted workload at 414. In particular, the network may receive the encrypted workload from the device via the second device. In some embodiments, 414 may be omitted.

[0073] At 416, the network may verify the one or more signatures. In particular, the network may verify the one or more signatures of the workload via the second device. The network may verify, via the second device, that the one or more signatures authorize the transfer of the workload from the first security domain to the second security domain. In some embodiments, 416 may be omitted.

[0074] At 418, the network may decrypt the encrypted workload. In particular, the network may decrypt the encrypted workload via the second device based at least in part on the one or more signatures being verified by the second device. In some embodiments, 418 may be omitted.

[0075] At 420, the network may provide the workload to a second security domain. In particular, the network may provide the workload to the second security domain via a second device. The network may provide the workload to the second security domain for storage within the second security domain. In some embodiments, 420 may be omitted.

[0076] FIG. 5 illustrates another exemplary procedure 500 for providing a workload from a first security domain of a CSP to a second security domain of a CSP, according to some embodiments. The process (e.g., procedure 500) is illustrated as a logic flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement the process. Procedure 500 may be performed by a private network (such as customer equipment 118 (FIG. 1)) or any portion thereof. For example, the procedure 500 may be performed by one or more devices (such as the first device 126 (FIG. 1), the second device 128 (FIG. 2), the first device 214 (FIG. 2), and / or the second device 218 (FIG. 2)).

[0077] At 502, the network may receive a workload from a first security realm (such as first security realm 102 (FIG. 1) and / or first security realm 206 (FIG. 2)). The network may include a private network connection connected between the first security realm of the CSP and the second security realm of the CSP. The network may further include a device coupled to the private network connection and located in the first security realm. The device may receive the workload from the first security realm. The first security realm may be part of a first air-gapped network. Additionally, the first security realm may be located within a first realm (such as first realm 202 (FIG. 2)).

[0078] At 504, the network may verify the one or more signatures. In particular, a device of the network may verify the one or more signatures of the workload. The one or more signatures may include at least one signature associated with a first security domain and at least one signature associated with a second security domain. The device may verify that the one or more signatures authorize the transfer of the workload from the first security domain to the second security domain.

[0079] At 506, the network may encrypt the workload. In particular, devices of the network may encrypt the workload based at least in part on one or more signatures of the workload being verified.

[0080] At 508, the network may transmit the encrypted workload. In particular, a device of the network may transmit the encrypted workload to a second security domain. The second security domain may be part of a second air-gapped network. Furthermore, the second security domain may be located within a second realm (such as second realm 204 (FIG. 2)).

[0081] At 510, the network may receive the encrypted workload. The network, in some embodiments, may include a second device, which may be coupled to a private network connection and located in a second security domain. The second device may receive the encrypted workload from the device. In some embodiments, 510 may be omitted.

[0082] At 512, the network may verify the one or more signatures. In particular, the second device may verify the one or more signatures of the encrypted workload. The second device may verify that the one or more signatures authorize the transfer of the workload from the first security domain to the second security domain. In some embodiments, 512 may be omitted.

[0083] At 514, the network may decrypt the encrypted workload. In particular, the second device may decrypt the encrypted workload based on verification of one or more of the signatures by the second device. In some embodiments, 514 may be omitted.

[0084] At 516, the network may provide the workload to the second security domain. In particular, the second device may provide the workload to the second security domain. The second device may provide the workload to the second security domain for storage within the second security domain. In some embodiments, 516 may be omitted.

[0085] As noted above, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS may be configured to provide virtualized computing resources over a public network (e.g., the Internet). 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), or the like). In some cases, an IaaS provider may also provide various services to accompany those infrastructure components (e.g., billing, monitoring, logging, load balancing, and clustering, etc.). Thus, because these services may be policy-driven, an IaaS user may be able to implement policies to drive load balancing to maintain application availability and performance.

[0086] In some cases, an IaaS customer 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 the application stack. For example, a user may log into an IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software within the VMs. The customer may then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application problems, monitoring performance, managing disaster recovery, and the like.

[0087] In most cases, the cloud computing model requires the participation of a cloud provider, which may be, but need not be, a third-party service that specializes in providing IaaS (e.g., supplying, renting, selling). An entity may also choose to deploy a private cloud, becoming its own provider of infrastructure services.

[0088] In some examples, IaaS deployment is the process of placing a new application, or a new version of an application, onto a prepared application server or the like. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider below the hypervisor layer (e.g., server, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling (OS), middleware, and / or application deployment (e.g., onto self-service virtual machines (e.g., that can be spun up on demand) or the like.

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

[0090] In some cases, there are two different challenges in IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before running anything. 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 can be solved by allowing the configuration of the infrastructure to be specified declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be specified by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which, how they each work together) can be described declaratively. In some cases, once the topology is specified, workflows can be generated that create and / or manage the different components described in the configuration files.

[0091] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., possibly on-demand pools of configurable and / or shared computing resources), also known as a core network. In some examples, there may be one or more inbound / outbound traffic group rules that are provisioned to define how the network's inbound and / or outbound traffic is configured, as well as one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, or the like, may also be provisioned. The infrastructure may evolve over time as more and more infrastructure elements are desired and / or added.

[0092] In some cases, continuous deployment techniques may be used to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques may enable infrastructure management within these environments. In some instances, 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 various different geographic locations, sometimes across the globe). However, in some instances, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning may be done manually, provisioning tools may be utilized to provision resources, and / or deployment tools may be utilized to deploy the code after the infrastructure has been provisioned.

[0093] 6 is a block diagram 600 illustrating an example IaaS architecture pattern, according to at least one embodiment. A service operator 602 may be communicatively coupled to a secure host tenancy 604, which may include a virtual cloud network (VCN) 606, and a secure host subnet 608. In some examples, the service operator 602 may be using one or more client computing devices, which may be portable handheld devices (e.g., iPhones, mobile phones, iPads, computing tablets, personal digital assistants (PDAs)), or wearable devices (e.g., Google Glass head-mounted displays) that run software such as Microsoft Windows Mobile and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and the like, and are Internet, email, short message service (SMS), Blackberry, or other communication protocol-enabled. Alternatively, the client computing devices may be general purpose personal computers, including, by way of example, personal computers and / or laptop computers, running various versions of the Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may also be workstation computers running any of the various commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems, such as, for example, Google Chrome OS.Alternatively, or in addition, the client computing devices may be any other electronic device, such as a thin client computer, a Microsoft Xbox gaming console with or without an Internet-enabled gaming system (e.g., a Kinect® gesture input device), and / or a personal messaging device capable of communicating over a network that has access to the VCN 606 and / or the Internet.

[0094] VCN 606 may include a local peering gateway (LPG) 610, which may be communicatively coupled to a secure shell (SSH) VCN 612 via an LPG 610 included in SSH VCN 612. SSH VCN 612 may include an SSH subnet 614, which may be communicatively coupled to a control plane VCN 616 via an LPG 610 included in control plane VCN 616. SSH VCN 612 may also be communicatively coupled to a data plane VCN 618 via the LPG 610. The control plane VCN 616 and the data plane VCN 618 may be included in a service tenancy 619, which may be owned and / or operated by the IaaS provider.

[0095] The control plane VCN 616 may include a control plane demilitarized zone (DMZ) tier 620 that acts as a perimeter network (e.g., a portion of an enterprise network between an enterprise intranet and an external network). DMZ-based servers may have limited responsibility and help keep intrusions at bay. Additionally, the DMZ tier 620 may include one or more load balancer (LB) subnets 622, a control plane app tier 624 that may include an app subnet 626, a control plane data tier 628 that may include a database (DB) subnet 630 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 622 included in the control plane DMZ tier 620 may be communicatively coupled to the app subnet 626 included in the control plane app tier 624 and an Internet gateway 634 that may be included in the control plane VCN 616, and the app subnet 626 may be communicatively coupled to the DB subnet 630 included in the control plane data tier 628, and a service gateway 636, and a network address translation (NAT) gateway 638. The control plane VCN 616 may include a service gateway 636 and a NAT gateway 638.

[0096] The control plane VCN 616 may include a data plane mirrored app tier 640, which may include an app subnet 626. The app subnet 626 included in the data plane mirrored app tier 640 may include a virtual network interface controller (VNIC) 642 on which a compute instance 644 can run. The compute instance 644 may communicatively couple the app subnet 626 of the data plane mirrored app tier 640 to the app subnet 626, which may be included in the data plane app tier 646.

[0097] The data plane VCN 618 may include a data plane app tier 646, a data plane DMZ tier 648, and a data plane data tier 650. The data plane DMZ tier 648 may include a LB subnet 622, which may be communicatively coupled to an app subnet 626 of the data plane app tier 646 and an Internet gateway 634 of the data plane VCN 618. The app subnet 626 may be communicatively coupled to a service gateway 636 of the data plane VCN 618 and a NAT gateway 638 of the data plane VCN 618. The data plane data tier 650 may also include a DB subnet 630, which may be communicatively coupled to the app subnet 626 of the data plane app tier 646.

[0098] The Internet gateway 634 of the control plane VCN 616 and the Internet gateway 634 of the data plane VCN 618 may be communicatively coupled to a metadata management service 652, which may be communicatively coupled to the public Internet 654. The public Internet 654 may be communicatively coupled to a NAT gateway 638 of the control plane VCN 616 and the NAT gateway 638 of the data plane VCN 618. The service gateway 636 of the control plane VCN 616 and the service gateway 636 of the data plane VCN 618 may be communicatively coupled to cloud services 656.

[0099] In some examples, a service gateway 636 in a control plane VCN 616 or a service gateway 636 in a data plane VCN 618 can make application programming interface (API) calls to cloud services 656 without going through the public Internet 654. API calls from the service gateway 636 to the cloud services 656 can be one-way: the service gateway 636 can make an API call to the cloud services 656, and the cloud services 656 can send the requested data to the service gateway 636. However, the cloud services 656 may not initiate the API call to the service gateway 636.

[0100] In some examples, secure host tenancy 604 may be directly connected to service tenancy 619, which may be otherwise isolated. Secure host subnet 608 may communicate with SSH subnet 614 through LPG 610, which may allow two-way communication through an otherwise isolated system. Connecting secure host subnet 608 to SSH subnet 614 may give secure host subnet 608 access to other entities in service tenancy 619.

[0101] The control plane VCN 616 may enable users of a service tenancy 619 to configure or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 616 may be deployed or otherwise used in the data plane VCN 618. In some examples, the control plane VCN 616 may be isolated from the data plane VCN 618, and the data plane mirror app tier 640 of the control plane VCN 616 may communicate with the data plane app tier 646 of the data plane VCN 618 via a VNIC 642 that may be included in the data plane mirror app tier 640 and the data plane app tier 646.

[0102] In some examples, a user, or customer, of the system may request, for example, a create, read, update, or delete (CRUD) operation over the public Internet 654, which may communicate the request to a metadata management service 652. The metadata management service 652 may communicate the request to the control plane VCN 616 through an Internet gateway 634. The request may be received by a LB subnet 622 included in the control plane DMZ tier 620. The LB subnet 622 may determine that the request is valid, and in response to this determination, the LB subnet 622 may transmit the request to an app subnet 626 included in the control plane app tier 624. If the request is authenticated and requires a call to the public Internet 654, the call to the public Internet 654 may be transmitted to a NAT gateway 638 that can make the call to the public Internet 654. Memory that may be desired to be stored by the request may be stored in the DB subnet 630.

[0103] In some examples, the data plane mirror app tier 640 may facilitate direct communication between the control plane VCN 616 and the data plane VCN 618. For example, it may be desirable for changes, updates, or other suitable modifications to a configuration to be applied to resources included in the data plane VCN 618. Through the VNIC 642, the control plane VCN 616 can communicate directly with the resources included in the data plane VCN 618, thereby performing changes, updates, or other suitable modifications to the configuration thereon.

[0104] In some embodiments, the control plane VCN 616 and the data plane VCN 618 may be included in the service tenancy 619. In this case, a user or customer of the system may not own or operate either the control plane VCN 616 or the data plane VCN 618. Alternatively, an IaaS provider may own or operate the control plane VCN 616 and the data plane VCN 618, both of which may be included in the service tenancy 619. This embodiment may allow for network isolation that may prevent users or customers from interacting with the resources of other users or other customers. This embodiment may also allow users or customers of the system to store databases privately without having to rely on the public Internet 654 for storage, which may not have the desired level of threat protection.

[0105] In another embodiment, the LB subnet 622 included in the control plane VCN 616 may be configured to receive signals from the service gateway 636. In this embodiment, the control plane VCN 616 and the data plane VCN 618 may be configured to be called by the IaaS provider's customers without calling the public Internet 654. The IaaS provider's customers may desire this embodiment because databases used by the customers may be stored in the service tenancy 619, which may be controlled by the IaaS provider and isolated from the public Internet 654.

[0106] 7 is a block diagram 700 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 702 (e.g., service operator 602 of FIG. 6) may be communicatively coupled to a secure host tenancy 704 (e.g., secure host tenancy 604 of FIG. 6), which may include a virtual cloud network (VCN) 706 (e.g., VCN 606 of FIG. 6) and a secure host subnet 708 (e.g., secure host subnet 608 of FIG. 6). The VCN 706 may include a local peering gateway (LPG) 710 (e.g., LPG 610 of FIG. 6), which may be communicatively coupled to a secure shell (SSH) VCN 712 (e.g., SSH VCN 612 of FIG. 6) via the LPG 610 included in the SSH VCN 712. SSH VCN 712 may include an SSH subnet 714 (e.g., SSH subnet 614 in FIG. 6), which may be communicatively coupled to a control plane VCN 716 (e.g., control plane VCN 616 in FIG. 6) via an LPG 710 included in the control plane VCN 716. The control plane VCN 716 may be included in a service tenancy 719 (e.g., service tenancy 619 in FIG. 6), and the data plane VCN 718 (e.g., data plane VCN 618 in FIG. 6) may be included in a customer tenancy 721, which may be owned or operated by a user or customer of the system.

[0107] The control plane VCN 716 may include a control plane DMZ tier 720 (e.g., the control plane DMZ tier 620 of FIG. 6 ) that may include a LB subnet 722 (e.g., the LB subnet 622 of FIG. 6 ), a control plane app tier 724 (e.g., the control plane app tier 624 of FIG. 6 ) that may include an app subnet 726 (e.g., the app subnet 626 of FIG. 6 ), and a control plane data tier 728 (e.g., the control plane data tier 628 of FIG. 6 ) that may include a database (DB) subnet 730 (e.g., similar to the DB subnet 630 of FIG. 6 ). The LB subnet 722 included in the control plane DMZ tier 720 may be communicatively coupled to an app subnet 726 included in the control plane app tier 724 and an Internet gateway 734 (e.g., Internet gateway 634 in FIG. 6 ) that may be included in the control plane VCN 716, and the app subnet 726 may be communicatively coupled to a DB subnet 730 included in the control plane data tier 728, and a service gateway 736 (e.g., service gateway in FIG. 6 ), and a network address translation (NAT) gateway 738 (e.g., NAT gateway 638 in FIG. 6 ). The control plane VCN 716 may include the service gateway 736 and the NAT gateway 738.

[0108] The control plane VCN 716 may include a data plane mirror app tier 740 (e.g., data plane mirror app tier 640 of FIG. 6 ), which may include an app subnet 726. The app subnet 726 included in the data plane mirror app tier 740 may include a virtual network interface controller (VNIC) 742 (e.g., VNIC 642) on which a compute instance 744 (e.g., similar to compute instance 644 of FIG. 6 ) may run. The compute instance 744 may facilitate communication between the app subnet 726 of the data plane mirror app tier 740 and the app subnet 726 included in the data plane app tier 746 (e.g., data plane app tier 646 of FIG. 6 ) via the VNIC 742 included in the data plane mirror app tier 740 and the VNIC 742 included in the data plane app tier 746.

[0109] The Internet gateway 734 included in the control plane VCN 716 may be communicatively coupled to a metadata management service 752 (e.g., metadata management service 652 of FIG. 6), which may be communicatively coupled to a public Internet 754 (e.g., public Internet 654 of FIG. 6). The public Internet 754 may be communicatively coupled to a NAT gateway 738 included in the control plane VCN 716. The service gateway 736 included in the control plane VCN 716 may be communicatively coupled to cloud services 756 (e.g., cloud services 656 of FIG. 6).

[0110] In some examples, the data plane VCN 718 may be included in the customer tenancy 721. In this case, the IaaS provider may provide a control plane VCN 716 for each customer, and the IaaS provider may configure a unique compute instance 744, included in the service tenancy 719, for each customer. Each compute instance 744 may enable communication between the control plane VCN 716, included in the service tenancy 719, and the data plane VCN 718, included in the customer tenancy 721. The compute instance 744 may enable resources provisioned in the control plane VCN 716, included in the service tenancy 719, to be deployed or otherwise used in the data plane VCN 718, included in the customer tenancy 721.

[0111] In another example, an IaaS provider customer may have a database that resides in customer tenancy 721. In this example, control plane VCN 716 may include a data plane mirror app tier 740 that may include app subnet 726. The data plane mirror app tier 740 may reside in data plane VCN 718, but the data plane mirror app tier 740 may not reside in data plane VCN 718. That is, the data plane mirror app tier 740 may have access to customer tenancy 721, but the data plane mirror app tier 740 may not reside in data plane VCN 718 or may be owned or operated by the IaaS provider customer. The data plane mirror app tier 740 may be configured to make calls to the data plane VCN 718, but may not be configured to make calls to any entities included in the control plane VCN 716. A customer may desire to deploy or otherwise use resources within the data plane VCN 718 provisioned within the control plane VCN 716, and the data plane mirror app tier 740 may facilitate the desired deployment or other use of the customer's resources.

[0112] In some embodiments, the IaaS provider's customer may apply filters to the data plane VCN 718. In this embodiment, the customer may determine what the data plane VCN 718 can access, and the customer may limit access from the data plane VCN 718 to the public Internet 754. The IaaS provider may not be able to apply filters or otherwise control the data plane VCN 718's access to any external networks or databases. Applying customer filters and controls to the data plane VCN 718 contained in the customer tenancy 721 may help isolate the data plane VCN 718 from other customers and from the public Internet 754.

[0113] In some embodiments, cloud services 756 may be called by service gateway 736 to access services that may not be on the public Internet 754, on the control plane VCN 716, or on the data plane VCN 718. The connection between cloud services 756 and the control plane VCN 716 or data plane VCN 718 may not be live or continuous. Cloud services 756 may be on different networks owned or operated by an IaaS provider. Cloud services 756 may be configured to receive calls from service gateway 736 and may be configured not to receive calls from the public Internet 754. Some cloud services 756 may be isolated from other cloud services 756, and control plane VCN 716 may be isolated from cloud services 756 that may not be in the same region as control plane VCN 716. For example, control plane VCN 716 may be located in "Region 1" and cloud service "Deployment 6" may be located in Region 1 and Region 2. If a call to Deployment 6 is made by a service gateway 736 included in a control plane VCN 716 located in Region 1, the call may be routed to Deployment 6 in Region 1. In this example, control plane VCN 716, or Deployment 6 in Region 1, may not be communicatively coupled to or otherwise in communication with Deployment 6 in Region 2.

[0114] 8 is a block diagram 800 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 802 (e.g., service operator 602 of FIG. 6) may be communicatively coupled to a secure host tenancy 804 (e.g., secure host tenancy 604 of FIG. 6), which may include a virtual cloud network (VCN) 806 (e.g., VCN 606 of FIG. 6) and a secure host subnet 808 (e.g., secure host subnet 608 of FIG. 6). VCN 806 may include an LPG 810 (e.g., LPG 610 of FIG. 6), which may be communicatively coupled to an SSH VCN 812 (e.g., SSH VCN 612 of FIG. 6) via an LPG 810 included in SSH VCN 812. SSH VCN 812 may include an SSH subnet 814 (e.g., SSH subnet 614 in FIG. 6), which may be communicatively coupled to a control plane VCN 816 (e.g., control plane VCN 616 in FIG. 6) via an LPG 810 included in the control plane VCN 816, and to a data plane VCN 818 (e.g., data plane 618 in FIG. 6) via an LPG 810 included in the data plane VCN 818. The control plane VCN 816 and the data plane VCN 818 may be included in a service tenancy 819 (e.g., service tenancy 619 in FIG. 6).

[0115] The control plane VCN 816 may include a control plane DMZ tier 820 (e.g., the control plane DMZ tier 620 of FIG. 6 ) that may include a load balancer LB subnet 822 (e.g., the LB subnet 622 of FIG. 6 ), a control plane app tier 824 (e.g., the control plane app tier 624 of FIG. 6 ) that may include an app subnet 826 (e.g., similar to the app subnet 626 of FIG. 6 ), and a control plane data tier 828 (e.g., the control plane data tier 628 of FIG. 6 ) that may include a DB subnet 830. The LB subnet 822 included in the control plane DMZ tier 820 may be communicatively coupled to an app subnet 826 included in the control plane app tier 824 and to an Internet gateway 834 (e.g., Internet gateway 634 in FIG. 6 ) that may be included in the control plane VCN 816, which may be communicatively coupled to a DB subnet 830 included in the control plane data tier 828, as well as to a service gateway 836 (e.g., service gateway in FIG. 6 ) and a network address translation (NAT) gateway 838 (e.g., NAT gateway 638 in FIG. 6 ). The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0116] The data plane VCN 818 may include a data plane app tier 846 (e.g., data plane app tier 646 of FIG. 6), a data plane DMZ tier 848 (e.g., data plane DMZ tier 648 of FIG. 6), and a data plane data tier 850 (e.g., data plane data tier 650 of FIG. 6). The data plane DMZ tier 848 may include a LB subnetwork 822, which may be communicatively coupled to a trusted app subnetwork 860 and an untrusted app subnetwork 862 of the data plane app tier 846, as well as an Internet gateway 834 included in the data plane VCN 818. The trusted app subnetwork 860 may be communicatively coupled to a service gateway 836 included in the data plane VCN 818, a NAT gateway 838 included in the data plane VCN 818, and a DB subnetwork 830 included in the data plane data tier 850. The untrusted app subnetwork 862 may be communicatively coupled to a service gateway 836 included in the data plane VCN 818 and a DB subnetwork 830 included in the data plane data tier 850. The data plane data hierarchy 850 may include a DB subnet 830 that may be communicatively coupled to a service gateway 836 included in the data plane VCN 818.

[0117] The untrusted app subnet 862 may include one or more primary VNICs 864(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 866(1)-(N). Each tenant VM 866(1)-(N) may be communicatively coupled to a respective app subnet 867(1)-(N) that may be included in a respective container egress VCN 868(1)-(N) that may be included in a respective customer tenancy 870(1)-(N). Each secondary VNIC 872(1)-(N) may facilitate communication between the untrusted app subnet 862 included in the data plane VCN 818 and the app subnet included in the container egress VCN 868(1)-(N). Each container egress VCN 868(1)-(N) may include a NAT gateway 838 that may be communicatively coupled to the public Internet 854 (e.g., public Internet 654 of FIG. 6).

[0118] The Internet gateway 834 included in the control plane VCN 816 and the Internet gateway 834 included in the data plane VCN 818 may be communicatively coupled to a metadata management service 852 (e.g., metadata management system 652 of FIG. 6 ), which may be communicatively coupled to the public Internet 854. The public Internet 854 may be communicatively coupled to a NAT gateway 838 included in the control plane VCN 816 and the NAT gateway 838 included in the data plane VCN 818. The service gateway 836 included in the control plane VCN 816 and the service gateway 836 included in the data plane VCN 818 may be communicatively coupled to cloud services 856.

[0119] In some embodiments, data plane VCN 818 may be integrated with customer tenancies 870. This integration may be useful or desirable for an IaaS provider's customers in some cases, such as when they may want support when executing code. The customer may provide code to be executed 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 execute code provided to the IaaS provider by the customer.

[0120] In some examples, a customer of an IaaS provider may grant a temporary network to the IaaS provider and request a function to be attached to the data plane app tier 846. The code to perform this function may run within VMs 866(1)-(N), which may not be configured to run elsewhere on the data plane VCN 818. Each VM 866(1)-(N) may be connected to one customer tenancy 870. Each container 871(1)-(N) contained in a VM 866(1)-(N) may be configured to run code. In this case, double isolation may exist (e.g., container 871(1)-(N) may run code, and container 871(1)-(N) may be contained in at least VMs 866(1)-(N) that are included in the untrusted app subnet 862), which may help prevent incorrect or otherwise undesired code from damaging the IaaS provider's network or from damaging a different customer's network. Containers 871(1)-(N) may be communicatively coupled to customer tenancy 870 and configured to transmit or receive data from customer tenancy 870. Containers 871(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 818. Upon completing code execution, the IaaS provider may destroy or otherwise dispose of containers 871(1)-(N).

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

[0122] In other embodiments, the control plane VCN 816 and the data plane VCN 818 may not be directly communicatively coupled. In this embodiment, there may not be direct communication between the control plane VCN 816 and the data plane VCN 818. However, communication may occur indirectly through at least one method. The LPG 810 may be established by an IaaS provider that may facilitate communication between the control plane VCN 816 and the data plane VCN 818. In another example, the control plane VCN 816 or the data plane VCN 818 may make a call to a cloud service 856 through a service gateway 836. For example, a call from the control plane VCN 816 to the cloud service 856 may include a request for a service that may communicate with the data plane VCN 818.

[0123] 9 is a block diagram 900 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 902 (e.g., service operator 602 of FIG. 6) may be communicatively coupled to a secure host tenancy 904 (e.g., secure host tenancy 604 of FIG. 6), which may include a virtual cloud network (VCN) 906 (e.g., VCN 606 of FIG. 6) and a secure host subnet 908 (e.g., secure host subnet 608 of FIG. 6). VCN 906 may include an LPG 910 (e.g., LPG 610 of FIG. 6), which may be communicatively coupled to an SSH VCN 912 (e.g., SSH VCN 612 of FIG. 6) via an LPG 910 included in SSH VCN 912. SSH VCN 912 may include an SSH subnet 914 (e.g., SSH subnet 614 in FIG. 6), which may be communicatively coupled to a control plane VCN 916 (e.g., control plane VCN 616 in FIG. 6) via an LPG 910 included in the control plane VCN 916, and to a data plane VCN 918 (e.g., data plane 618 in FIG. 6) via an LPG 910 included in the data plane VCN 918. The control plane VCN 916 and the data plane VCN 918 may be included in a service tenancy 919 (e.g., service tenancy 619 in FIG. 6).

[0124] The control plane VCN 916 may include a control plane DMZ tier 920 (e.g., the control plane DMZ tier 620 of FIG. 6 ) that may include a LB subnet 922 (e.g., the LB subnet 622 of FIG. 6 ), a control plane app tier 924 (e.g., the control plane app tier 624 of FIG. 6 ) that may include an app subnet 926 (e.g., the app subnet 626 of FIG. 6 ), and a control plane data tier 928 (e.g., the control plane data tier 628 of FIG. 6 ) that may include a DB subnet 930 (e.g., the DB subnet 830 of FIG. 8 ). The LB subnet 922 included in the control plane DMZ tier 920 may be communicatively coupled to an app subnet 926 included in the control plane app tier 924 and to an Internet gateway 934 (e.g., Internet gateway 634 of FIG. 6 ) that may be included in the control plane VCN 916, which may be communicatively coupled to a DB subnet 930 included in the control plane data tier 928, as well as to a service gateway 936 (e.g., service gateway 636 of FIG. 6 ) and a network address translation (NAT) gateway 938 (e.g., NAT gateway 638 of FIG. 6 ). The control plane VCN 916 may include the service gateway 936 and the NAT gateway 938.

[0125] The data plane VCN 918 may include a data plane app tier 946 (e.g., data plane app tier 646 of FIG. 6), a data plane DMZ tier 948 (e.g., data plane DMZ tier 648 of FIG. 6), and a data plane data tier 950 (e.g., data plane data tier 650 of FIG. 6). The data plane DMZ tier 948 may include a trusted app subnet 960 (e.g., trusted app subnet 860 of FIG. 8) and an untrusted app subnet 962 (e.g., untrusted app subnet 862 of FIG. 8) of the data plane app tier 946, as well as a LB subnet 922, which may be communicatively coupled to an Internet gateway 934 included in the data plane VCN 918. The trusted app subnet 960 may be communicatively coupled to a service gateway 936 included in the data plane VCN 918, a NAT gateway 938 included in the data plane VCN 918, and a DB subnet 930 included in the data plane data tier 950. The untrusted app subnet 962 may be communicatively coupled to a service gateway 936 included in the data plane VCN 918 and a DB subnet 930 included in the data plane data tier 950. The data plane data tier 950 may include the DB subnet 930, which may be communicatively coupled to a service gateway 936 included in the data plane VCN 918.

[0126] The untrusted app subnet 962 may include primary VNICs 964(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 966(1)-(N) residing within the untrusted app subnet 962. Each tenant VM 966(1)-(N) may execute code within a respective container 967(1)-(N) and may be communicatively coupled to an app subnet 926 that may be included in a data plane app tier 946 that may be included in a container egress VCN 968. Each secondary VNIC 972(1)-(N) may facilitate communication between the untrusted app subnet 962 included in the data plane VCN 918 and the app subnet included in the container egress VCN 968. The container egress VCN may include a NAT gateway 938 that may be communicatively coupled to the public Internet 954 (e.g., public Internet 654 of FIG. 6).

[0127] The internet gateway 934 included in the control plane VCN 916 and the internet gateway 934 included in the data plane VCN 918 may be communicatively coupled to a metadata management service 952 (e.g., metadata management system 652 of FIG. 6 ), which may be communicatively coupled to the public Internet 954. The public Internet 954 may be communicatively coupled to a NAT gateway 938 included in the control plane VCN 916 and the NAT gateway 938 included in the data plane VCN 918. The service gateway 936 included in the control plane VCN 916 and the service gateway 936 included in the data plane VCN 918 may be communicatively coupled to cloud services 956.

[0128] In some examples, the pattern illustrated by the architecture of block diagram 900 of FIG. 9 may be considered an exception to the pattern illustrated by the architecture of block diagram 800 of FIG. 8 and may be desirable for a customer of an IaaS provider when the IaaS provider cannot communicate directly with the customer (e.g., an isolated region). Each container 967(1)-(N) included in a VM 966(1)-(N) for each customer may be accessed in real time by the customer. The containers 967(1)-(N) may be configured to make calls to a respective secondary VNIC 972(1)-(N) included in an app subnet 926 of a data plane app tier 946 that may be included in a container egress VCN 968. The secondary VNIC 972(1)-(N) may carry calls to a NAT gateway 938 that may carry calls to the public Internet 954. In this example, containers 967(1)-(N) that may be accessed in real time by customers may be isolated from control plane VCN 916 and may be isolated from other entities included in data plane VCN 918. Containers 967(1)-(N) may also be isolated from resources from other customers.

[0129] In another example, a customer may invoke cloud service 956 using container 967(1)-(N). In this example, the customer may execute code within container 967(1)-(N) that requests a service from cloud service 956. Container 967(1)-(N) may transmit the request to secondary VNIC 972(1)-(N), which may transmit the request to a NAT gateway, which may transmit the request to public Internet 954. Public Internet 954 may transmit the request to LB subnet 922, which is included in control plane VCN 916, via Internet gateway 934. In response to determining that the request is valid, the LB subnet may transmit the request to app subnet 926, which may transmit the request to cloud service 956 via service gateway 936.

[0130] It should be understood that the IaaS architectures 600, 700, 800, 900 depicted in the figures may have components other than those depicted. Additionally, the embodiments depicted in the figures are only some 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 depicted in the figures, may combine two or more components, or may have a different configuration or arrangement of components.

[0131] In one embodiment, the IaaS system disclosed herein may include a suite of application, middleware, and database services delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI) provided by the Trustee.

[0132] 10 illustrates an exemplary computer system 1000 in which various embodiments may be implemented. System 1000 may be used to implement any of the computer systems described above. As shown in the figure, computer system 1000 includes a processing unit 1004 that communicates with several peripheral subsystems via a bus subsystem 1002. These peripheral subsystems may include a processing accelerator 1006, an I / O subsystem 1008, a storage subsystem 1018, and a communication subsystem 1024. The storage subsystem 1018 includes a tangible computer-readable storage medium 1022 and a system memory 1010.

[0133] Bus subsystem 1002 provides a mechanism for allowing the various components and subsystems of computer system 1000 to communicate with one another as intended. Although bus subsystem 1002 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1002 may be any of several types of bus structures, such as 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 to the IEEE P1386.1 standard.

[0134] The processing unit 1004, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1000. One or more processors may be included in the processing unit 1004. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 1004 may be implemented as one or more independent processing units 1032 and / or 1034, each processing unit including a single or multi-core processor. In other embodiments, the processing unit 1004 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0135] In various embodiments, the processing unit 1004 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed may reside within the processor 1004 and / or the storage subsystem 1018. Through suitable programming, the processor 1004 may provide various functionality as described above. The computer system 1000 may additionally include a processing accelerator 1006, which may include a digital signal processor (DSP), a special purpose processor, and / or the like.

[0136] The I / O subsystem 1008 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors that allow users to control and interact with input devices such as Microsoft Xbox® 360 game controllers through a natural user interface using gestures and spoken commands. User interface input devices may also include eye gesture recognition devices such as the Google Glass® blink detector that detects eye activity from a user (e.g., "blinking" while taking a picture and / or making a menu selection) and translates the eye gesture as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) through voice commands.

[0137] User interface input devices may also include, without limitation, three-dimensional (3D) mice, joysticks or pointing sticks, game pads 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. Additionally, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound examination devices, and the like. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0138] User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. 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, and the like. In general, the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1000 to a user or to another computer. For example, user interface output devices may include various display devices that visually convey textual, graphical, and / or audio / visual information, such as, without limitation, monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0139] Computer system 1000 may include a storage subsystem 1018 that comprises software elements currently shown residing in system memory 1010. System memory 1010 may store program instructions that are readable and executable on processing unit 1004, as well as data generated during the execution of these programs.

[0140] Depending on the configuration and type of computer system 1000, the system memory 1010 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 currently being operated and executed by the processing unit 1004. In some implementations, the system memory 1010 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 the basic routines that help to transfer information between elements within the computer system 1000, such as during start-up, may typically be stored in ROM. By way of example and not limitation, the system memory 1010 also illustrates application programs 1012, program data 1014, and an operating system 1016, which may include client applications, a web browser, a mid-tier application, a relational database management system (RDBMS), and the like. By way of example, operating system 1016 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, without limitation, various GNU / Linux operating systems, Google Chrome® OS, and the like), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems.

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

[0142] Storage subsystem 1000 may also include a computer-readable storage medium reader 1020 that may be further connected to a computer-readable storage medium 1022. Together with, and optionally in combination with, the system memory 1010, the computer-readable storage medium 1022 may comprehensively represent remote, local, fixed, and / or removable storage devices, as well as storage media for containing, storing, transmitting, and retrieving computer-readable information on a temporary and / or more permanent basis.

[0143] The computer readable storage medium 1022 containing the code or portions of code may also include any suitable medium known or used in the art, including storage media or communication media, including but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information. This may include tangible computer readable storage media, such as RAM, ROM, Electrically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media. This may also include non-tangible computer readable media, such as data signals, data transmissions, or any other medium that may be used to transmit the desired information and that may be accessed by the computing system 1000.

[0144] By way of example, the computer readable storage medium 1022 may include hard disk drives that read from or write to non-removable non-volatile magnetic media, magnetic disk drives that read from or write to removable non-volatile magnetic disks, and optical disk drives that read from or write to removable non-volatile optical disks, such as CD ROMs, DVDs, and Blu-Ray® disks, or other optical media. The computer readable storage medium 1022 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer readable storage medium 1022 may also include solid state drives (SSDs) based on non-volatile memory, such as flash memory-based SSDs, enterprise flash drives, solid state ROMs, and the like, 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 non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 1000.

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

[0146] In some embodiments, the communications subsystem 1024 may also receive incoming communications in the form of structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, and the like on behalf of one or more users who may be using the computer system 1000.

[0147] By way of example, the communications subsystem 1024 may be configured to receive data feeds 1026 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter feeds, Facebook updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party information sources.

[0148] Additionally, the communications subsystem 1024 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1028 of real-time events and / or event updates 1030, which may be continuous or essentially infinite without an apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

[0149] The communications subsystem 1024 may also be configured to output structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, and the like to one or more databases, which may be in communication with one or more streaming data source computers coupled to the computer system 1000.

[0150] The computer system 1000 may 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.

[0151] Due to the ever-changing nature of computers and networks, the description of the computer system 1000 depicted in the figures is intended only as a specific example. Many other configurations are possible having more or fewer components than the system depicted in the figures. For example, customized hardware may also be used, and certain elements may be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, may be used. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other ways and / or methods to implement the various embodiments.

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

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

[0154] The specification and drawings are therefore to be treated in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and alterations may be made thereto without departing from the broad spirit and scope as set forth in the claims. Thus, although certain disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0155] Use of the terms "a," "an," and "the" and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims below) should be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to"), unless otherwise indicated. The term "connected" is to be construed as being partially or wholly contained within, attached to, or joined to one another, even if there is intervening material. Recitations of ranges of values ​​herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were individually recited herein. All methods described herein may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples or exemplary language applied herein (e.g., "etc.") is intended only to better elucidate the embodiments and does not impose limitations on 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.

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

[0157] The term "network" as used herein may refer to a computer network. For example, a network as referenced herein may refer to two or more computer elements (such as servers, computers, storage devices, computing devices, networking devices, or other computing devices) and network connections connecting the computer elements. A single network may comprise a structure of two or more computer elements and network connections that may be operated by an entity, associated with an entity, and / or associated with a customer of an entity. The network connections may include hardwired or wireless connections between the computer elements of the network.

[0158] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the present disclosure. Variations of these preferred embodiments may become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to use such variations where appropriate, and the present disclosure may be practiced apart from those specifically described herein. Accordingly, the present 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.

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

[0160] term Item 1 includes a method for providing a workload from a first security domain of a cloud service provider (CSP) to a second security domain of the cloud service provider, the method including a device receiving a workload from the first security domain and the device verifying one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with the second security domain, the method further including the device encrypting the workload based at least in part on the one or more signatures of the workload being verified, and the device transmitting the encrypted workload to the second security domain.

[0161] Clause 2 includes the method of clause 1, where transmitting the encrypted workload includes transmitting the encrypted workload over a private network connection.

[0162] Item 3 includes the method of items 1 or 2, wherein the first security domain is located within a first realm and the second security domain is located within a second realm.

[0163] Clause 4 includes the method of clause 1 or clause 2, where the device is a first device, and the method further includes a second device receiving an encrypted workload transmitted by the first device, the second device verifying one or more signatures, the second device decrypting the encrypted workload based at least in part on the one or more signatures being verified by the second device, and the second device providing the workload to a second security domain.

[0164] Item 5 includes the method of item 4, wherein the first device is located in a first security domain and the second device is located in a second security domain.

[0165] Item 6 includes the method of item 4, wherein the first device and the second device are part of a private network.

[0166] Clause 7 includes the method of clause 6, wherein transmitting the encrypted workload to the second security domain includes the first device transmitting the encrypted workload to the second device over a private network.

[0167] Clause 8 includes the method of clause 1 or clause 2, wherein the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network, and transmitting the encrypted workload includes the device transmitting the encrypted workload from the first air-gapped network to the second air-gapped network.

[0168] Clause 9 includes one or more computer-readable media having instructions stored thereon that, when executed by a network, cause the network to receive, via a device of the network, a workload from a first security domain of a cloud service provider (CSP) and verify, via the device, one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with a second security domain, the instructions further causing the network to encrypt, via the device, the workload based at least in part on the one or more signatures of the workload being verified, and transmit, via the device, the encrypted workload to the second security domain of the cloud service provider.

[0169] Clause 10 includes the one or more computer-readable media of clause 9, the instructions that, when executed by the network, further cause the network to configure a device with the one or more signatures for verification of the one or more signatures.

[0170] Clause 11 includes the one or more computer-readable media of clause 10, wherein the device is a first device, the first device located in a first security domain, and the instructions, when executed by the network, further cause the network to configure a second device with the one or more signatures for verification of the one or more signatures, the second device located in a second security domain.

[0171] Clause 12 includes the one or more computer-readable media of clause 11, the instructions, when executed by the network, further cause the network to receive, via the second device, an encrypted workload from the first device, verify, via the second device, one or more signatures of the workload, decrypt, via the second device, the encrypted workload based at least in part on the verification of the one or more signatures by the second device, and provide, via the second device, the workload to a second security domain.

[0172] Item 13 includes the one or more computer-readable media of item 11, wherein the first device and the second device are part of a private network.

[0173] Item 14 includes the one or more computer-readable media of item 11, wherein the first device comprises a first encryption device and the second device comprises a second encryption device.

[0174] Item 15 includes one or more computer-readable media of any of items 9 to 14, wherein the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network.

[0175] Clause 16 includes one or more computer-readable media of any of clauses 9-14, wherein transmitting the encrypted workload to the second security domain includes transmitting the encrypted workload over a private network connection.

[0176] Clause 17 includes a private network, the private network comprising: a private network connection connected between a first security domain of a cloud service provider (CSP) and a second security domain of the cloud service provider; and a device coupled to the private network connection and located in the first security domain, the device for receiving a workload from the first security domain and verifying one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with a second security domain, the private network for encrypting the workload based at least in part on the one or more signatures of the workload being verified, and transmitting the encrypted workload to the second security domain.

[0177] Clause 18 includes the private network of clause 17, wherein the device is a first device, and the private network further comprises a second device coupled to the private network connection and located in a second security domain, the second device for receiving an encrypted workload from the first device, verifying one or more signatures of the encrypted workload, decrypting the encrypted workload based on verification of the one or more signatures by the second device, and providing the workload to the second security domain.

[0178] Item 19 includes the private network of item 17 or item 18, wherein the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network.

[0179] Item 20 includes the private network of item 17 or item 18, where the first security domain is located within the first realm and the second security domain is located within the second realm.

[0180] Clause 21 includes one or more computer-readable media having instructions stored thereon that, when executed by one or more processors, cause a network connected device to receive a workload from a first security domain of a cloud service provider (CSP) and verify one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with a second security domain, the instructions further causing the network connected device to encrypt the workload based at least in part on the one or more signatures of the workload being verified, and transmit the encrypted workload to the second security domain of the cloud service provider.

[0181] Clause 22 may include one or more computer-readable media of clause 21, where the instructions, when executed by the one or more processors, further cause the one or more processors to configure a device with the one or more signatures for verification of the one or more signatures.

[0182] Clause 23 may include one or more computer-readable media of clause 22, wherein the device is a first device, the first device located in a first security domain, and the instructions, when executed by the one or more processors, further configure a second device with the one or more signatures for verification of the one or more signatures, the second device located in a second security domain.

[0183] Clause 24 includes the one or more computer-readable media of clause 23, wherein the instructions, when executed by the one or more processors, further configure the second device to receive an encrypted workload from the first device, verify one or more signatures of the workload, decrypt the encrypted workload based at least in part on the one or more signatures being verified by the second device, and provide the workload to a second security domain.

[0184] Item 25 may include one or more computer-readable media of item 23, wherein the first device and the second device are part of a private network.

[0185] Clause 26 may include one or more computer-readable media of clause 23, wherein the first device comprises a first encryption device and the second device comprises a second encryption device.

[0186] Item 27 may include one or more computer-readable media of any of items 21-25, wherein the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network.

[0187] Clause 28 may include one or more computer-readable media of any of clauses 21-25, wherein transmitting the encrypted workload to the second security domain includes transmitting the encrypted workload over a private network connection.

[0188] Clause 29 includes a private network system, the private network comprising: a private network connection connected between a first security domain of a cloud service provider (CSP) and a second security domain of the cloud service provider; and a device coupled to the private network connection and located in the first security domain, the device for receiving a workload from the first security domain and verifying one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with the second security domain, the private network further for encrypting the workload based at least in part on the one or more signatures of the workload being verified and transmitting the encrypted workload to the second security domain.

[0189] Clause 30 may include the private network system of clause 29, where the device is a first device, and the private network system further comprises a second device coupled to the private network connection and located in a second security domain, the second device for receiving an encrypted workload from the first device, verifying one or more signatures of the encrypted workload, decrypting the encrypted workload based on verification of the one or more signatures by the second device, and providing the workload to the second security domain.

[0190] Item 31 may include the private network system of item 29 or item 30, where the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network.

[0191] Item 32 may include the private network system of item 29 or item 30, where the first security domain is located within the first realm and the second security domain is located within the second realm.

[0192] Clause 33 includes a computer program product having instructions that, when executed by a network, cause the network to receive, via a device of the network, a workload from a first security domain of a cloud service provider (CSP); verify, via the device, one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with a second security domain; encrypt, via the device, the workload based at least in part on the one or more signatures of the workload being verified; and transmit, via the device, the encrypted workload to the second security domain of the cloud service provider.

[0193] Clause 34 includes the computer program product of clause 33, the program, when executed by the network, further causing the network to configure a device with the one or more signatures for verification of the one or more signatures.

[0194] Clause 35 includes the computer program product of clause 34, wherein the device is a first device, the first device located in a first security domain, and the program, when executed by the network, further causes the network to configure a second device with the one or more signatures for verification of the one or more signatures, the second device located in a second security domain.

[0195] Clause 36 includes the computer program product of clause 35, wherein the program, when executed by the network, further causes the network to receive, via the second device, an encrypted workload from the first device, verify, via the second device, one or more signatures of the workload, decrypt, via the second device, the encrypted workload based at least in part on the verification of the one or more signatures by the second device, and provide, via the second device, the workload to a second security domain.

[0196] Clause 37 includes the computer program product of clause 35, wherein the first device and the second device are part of a private network.

[0197] Clause 38 includes the computer program product of clause 35, wherein the first device comprises a first encryption device and the second device comprises a second encryption device.

[0198] Item 39 includes one or more computer-readable media of any of items 33 to 38, wherein the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network.

[0199] Clause 40 includes one or more computer-readable media of any of clauses 33-38, wherein transmitting the encrypted workload to the second security domain includes transmitting the encrypted workload over a private network connection.

[0200] In the foregoing specification, aspects of the disclosure are described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the disclosure described above may be used individually or in combination. Moreover, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broad spirit and scope of the present specification. The present specification and drawings are therefore to be treated as illustrative rather than restrictive.

Claims

1. 1. A method for providing a workload from a first security domain of a cloud service provider (CSP) to a second security domain of the cloud service provider, comprising: receiving, by a device, the workload from the first security domain; and verifying one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with the second security domain; The method comprises: the device encrypting the workload based at least in part on the one or more signatures of the workload being verified; The method further comprising the device transmitting the encrypted workload to the second security domain.

2. The method of claim 1 , wherein transmitting the encrypted workload comprises transmitting the encrypted workload over a private network connection.

3. The method of claim 1 , wherein the first security realm is located within a first realm and the second security realm is located within a second realm.

4. The device is a first device, and the method includes: a second device receiving the encrypted workload transmitted by the first device; the second device verifying the one or more signatures; and decrypting, by the second device, the encrypted workload based at least in part on the one or more signatures being verified by the second device; The method of claim 1 , further comprising the second device providing the workload to the second security domain.

5. The method of claim 4 , wherein the first device is located in the first security domain and the second device is located in the second security domain.

6. The method of claim 4 , wherein the first device and the second device are part of a private network.

7. 7. The method of claim 6, wherein transmitting the encrypted workload to the second security domain comprises the first device transmitting the encrypted workload to the second device over the private network.

8. 2. The method of claim 1 , wherein the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network, and transmitting the encrypted workload includes the device transmitting the encrypted workload from the first air-gapped network to the second air-gapped network.

9. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out a method according to any of claims 1 to 8.

10. A network system, comprising: a private network connected between a first security domain of a cloud service provider (CSP) and a second security domain of the cloud service provider; a device coupled to the private network and located in the first security domain, the device comprising: receiving a workload from the first security domain; and verifying one or more signatures of the workload, the one or more signatures including at least one signature associated with the first security domain and at least one signature associated with the second security domain; encrypting the workload based at least in part on the one or more signatures of the workload being verified; and transmitting the encrypted workload to the second security domain.

11. The device is a first device, and the network system further comprises a second device coupled to the private network and located in the second security domain, the second device comprising: receiving the encrypted workload from the first device; verifying the one or more signatures of the encrypted workload; decrypting the encrypted workload based on verification of the one or more signatures by the second device; and providing the workload to the second security domain.

12. 12. The network system of claim 10 or 11, wherein the first security domain is part of a first air-gapped network and the second security domain is part of a second air-gapped network.

13. 12. The network system according to claim 10, wherein the first security realm is located within a first realm, and the second security realm is located within a second realm.