Inter-cloud service gateway

Abstract

This specification discusses a framework that facilitates access to services provided in a target cloud environment for resources deployed in a source cloud environment. The source cloud environment is different from and independent of the target cloud environment. Compute instances running in the source cloud environment generate requests to use services provided in the target cloud environment. The requests are sent from the source cloud environment to the target cloud environment via an inter-cloud service gateway. The services are executed in the target cloud environment based on the access roles associated with the compute instances.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of the filing date of U.S. Patent Application No. 17 / 742,472, filed on May 12, 2022, the content of which is hereby incorporated by reference in its entirety for all purposes.

[0002] Field The present disclosure relates to an inter - cloud service gateway that provides a framework for facilitating access to services provided in a first cloud environment (e.g., a first public cloud) for resources deployed in a second cloud environment (e.g., a second public cloud). Access to the services is provided without exchanging or sharing identity principals (e.g., certificates or credentials) associated with the resources between the two cloud environments.

Background Art

[0003] Background Users or customers of public clouds desire to access the best services from various cloud service providers. In the cloud environment, the current paradigm of such service design encourages building on top of the local services provided by the cloud environment. Cross-cloud or inter-cloud service access is not readily available. Therefore, users design their own custom solutions to access services provided in a second, independent cloud environment different from the first cloud environment from the first cloud environment. Typical solutions designed to be able to access services provided by another cloud service provider are time-consuming, error-prone, and costly. Furthermore, one of the main drawbacks of typical access solutions is credential management. Specifically, to access services provided in the first cloud environment from resources deployed in the second cloud environment, it is necessary to set up a network connection between the two cloud environments. In such a framework, to access the services of the first cloud environment, the user has to distribute their credentials across the cloud infrastructure. Such a solution is inherently insecure and inconvenient.

[0004] Embodiments described herein address these and other problems related to the migration of applications between different cloud environments. SUMMARY OF THE INVENTION MEANS FOR SOLVING THE PROBLEM

[0005] Overview This disclosure generally relates to an inter-cloud service gateway that provides a framework for facilitating access to services provided in a first cloud environment (e.g., a first public cloud) for resources deployed in a second cloud environment (e.g., a second public cloud). Access to the services is provided without exchanging or sharing identity principals (e.g., certificates or credentials) associated with the resources between the two cloud environments. This document describes various embodiments, including methods, systems, programs, code, or instructions executable by one or more processors, and non-transitory computer-readable storage media storing the same. These exemplary embodiments are not intended to limit or define the disclosure, but are mentioned to provide examples to aid in the understanding of the disclosure. Additional embodiments are considered in the detailed description section, where further explanation is provided.

[0006] One aspect of the disclosure provides a method that includes a compute instance running in a source cloud environment generating a request to use a service provided in a target cloud environment, where the source cloud environment is different from the target cloud environment, and the method further includes sending the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway, and executing the service in the target cloud environment based on an access role associated with the compute instance.

[0007] Another aspect of the present disclosure, when executed by a processor, causes a computer system to generate a request to use a service provided in a target cloud environment by at least a compute instance running in a source cloud environment, where the source cloud environment is different from the target cloud environment, send the request from the source cloud environment to the target cloud environment via an intercloud service gateway, and execute the service in the target cloud environment based on an access role associated with the compute instance, and provides a computer-readable medium storing specific computer-executable instructions for causing the above.

[0008] One aspect of the present disclosure is a system comprising a processor and a memory including instructions that, when executed by the processor, cause the system to generate a request to use a service provided in a target cloud environment by at least a compute instance running in a source cloud environment, where the source cloud environment is different from the target cloud environment, send the request from the source cloud environment to the target cloud environment via an intercloud service gateway, and execute the service in the target cloud environment based on an access role associated with the compute instance.

[0009] The above, together with other features and embodiments, will become more apparent by reference to the following specification, claims, and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 3C

Figure 4A

Figure 4B

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Best Mode for Carrying Out the Invention

[0011] Detailed Description In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are shown in order for the embodiments to be fully understood. However, it will also be apparent to those skilled in the art that these embodiments can be implemented without specific details. Furthermore, well-known features may be simplified in order not to obscure the described embodiments.

[0012] In cloud computing, a cloud is a collection of servers that cloud customers access via a communication network, such as the Internet. A cloud service provider (CSP) that provides various services to customers manages the cloud infrastructure. In contrast, a typical multi-cloud environment involves the use of several cloud infrastructures, each of which is managed by a unique CSP. There are many uses for multi-cloud deployments. In a multi-cloud deployment, multiple infrastructure-as-a-service (IaaS) vendors can be utilized as services, or different vendors can be used for IaaS services, platform-as-a-service (PaaS) services, and software-as-a-service (SaaS) services. Multi-cloud can be used simply for redundancy and system backup purposes, or a multi-cloud deployment can incorporate different cloud vendors for different services.

[0013] To date, most multi-cloud solutions have mainly focused on simplifying network access. Users or customers with accounts in different CSPs can access resources in different clouds based on identity federation, i.e., user identity federation. Specifically, identity federation is a system that establishes trust between two parties for the purpose of authenticating users and transmitting the information necessary to permit user access to resources. However, such frameworks do not necessarily extend to establishing trust between resources (i.e., non-user actors such as compute instances, VMs, functions, etc.).

[0014] Furthermore, customers preferably keep their traffic from compute workloads (i.e., VMs, containers, functions) to cloud services private as much as possible and preferably avoid distributing their long-term credentials to these compute workloads. Customers can achieve this type of communication, but only within the environment provided by each cloud, i.e., within a single cloud environment. Currently, there is no mechanism to achieve a similar communication mode in an inter-cloud environment. Embodiments of the present disclosure provide an inter-cloud service gateway (ICSGW) for the purpose of providing a framework that can be used to configure a customer's compute workload or compute instance in one cloud environment (e.g., a cloud environment managed by a first CSP) to access services in a different cloud environment (i.e., a cloud environment managed by a second CSP) in a more secure manner.

[0015] Figure 1 shows an exemplary high-level architecture of an inter-cloud service gateway (ICSGW) according to various embodiments. The high-level architecture 100 shown in Figure 1 includes an inter-cloud service gateway 105, which is a multi-tenant service seamlessly placed between a source cloud environment 101 and a target cloud environment 107. Specifically, the ICSGW 105 has a footprint in both the source cloud environment 101 and the target cloud environment 107.

[0016] The source cloud environment 101 includes one or more customer virtual cloud networks (e.g., customer VCN 103) that host one or more compute instances 102 (e.g., virtual machines (VMs), containers, functions). Such compute instances 102 can utilize the services 109 provided by the target cloud environment 107 via the ICSGW 105. It is understood that the services 109 provided by the target cloud environment 107 can be utilized not only by customers who have a tenancy in the target cloud environment 107 (i.e., customer accounts in the target cloud environment 107) but also by customers who do not have a customer tenancy in the target cloud environment 107.

[0017] According to some embodiments, when a compute workload (e.g., compute instance 102 in source cloud environment 101) accesses target service 109 in a target cloud environment using an identity principal (i.e., a resource principal corresponding to the identity of the resource) that is locally available in source cloud environment 101, the ICSGW105 service executes a set of actions. In one embodiment, the set of actions includes at least: (i) intercepting requests / responses between the compute workload and the target service; (ii) verifying the identity principal associated with the compute instance; (iii) converting the identity principal into an access role for the compute instance in the target cloud environment; and (iv) forwarding the request to the ultimate destination (e.g., the desired service) in the target cloud environment. In other words, compute instance 102 in the source cloud environment generates a request to access service 109 in the target cloud environment. The request is further communicated from the source cloud environment 101 to the target cloud environment 107 via a secure communication channel. The service is executed in the target cloud environment 107 based on the access role (i.e., one or more permissions) associated with the compute instance in the source cloud environment 101. Further, details regarding the architecture of ICSGW105 and the process of initiating a service (in the target cloud environment) used by a compute instance in the source cloud environment will be described in detail later with reference to FIGS. 3A - 3C.

[0018] Figure 2 shows a high-level flow diagram illustrating the process executed by an inter-cloud service gateway (ICSGW) according to various embodiments. Specifically, Figure 2 illustrates a process in which a compute instance (e.g., virtual machine, container, function) running in a source cloud environment provisions to access a service provided in a target cloud environment via the ICSGW. The processes shown in Figure 2 can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each respective system, hardware, or combination thereof. The software can be stored in a non-transitory storage medium (e.g., in a memory device). The methods presented in Figure 2 and described below are intended to be exemplary and non-limiting. Although Figure 2 shows various processing steps occurring in a particular sequence or order, this is not intended to be limiting. In some alternative embodiments, the steps may be executed in any different order, or some steps may be executed in parallel.

[0019] The process begins at step 201, where a compute instance running in a source cloud environment (e.g., a compute instance running in a customer VCN in the source cloud environment) generates a request to use a service provided in a target cloud environment. It is noted that the target cloud environment is different from and independent of the source cloud environment.

[0020] In step 203, the request generated by the compute instance is communicated from the source cloud environment to the target cloud environment via the inter-cloud service gateway. Specifically, as will be described later with reference to FIG. 3A, the request is communicatively coupled via a reliable communication channel (e.g., a FastConnect communication channel) from a source inter-cloud service gateway (deployed in the source cloud environment) to a target inter-cloud service gateway (deployed in the target cloud environment) that is communicatively coupled. When the request is sent to the target cloud environment, in step 205, a service is executed in the target cloud environment based on the access role associated with the compute instance.

[0021] Referring now to FIG. 3A, a detailed architecture of an inter-cloud service gateway (ICSGW) according to various embodiments is illustrated. The ICSGW provides a service framework that facilitates access to services provided in a first public cloud (i.e., referred to herein as the target cloud environment) for resources deployed in a second public cloud (i.e., referred to herein as the source cloud environment) without sharing identity principals across those two cloud environments.

[0022] The architecture 300 of the ICSGW includes a source cloud environment 301 and a target cloud environment 331. The source cloud environment 301 includes an ICSGW service tenancy 303, a source cloud service 313, and one or more customer virtual cloud networks (VCNs) (e.g., customer 1 VCN 315, customer 2 VCN 317). The ICSGW service tenancy 303 includes a control plane component (i.e., the ICSGW control plane 305) and a data plane component (i.e., the ICSGW data plane 307). In the ICSGW data plane 307, a source ICSGW 309 is hosted. The source cloud service 313 includes a plurality of services, including an identity and management service 313A and a private access service 313B. Each of the customer VCNs includes compute instances running therein (e.g., customer 1 VCN 315 includes a compute instance 315A, and customer 2 VCN 317 includes another compute instance 317A).

[0023] The target cloud environment 331 includes an ICSGW service account (or service tenancy) 337 and a target cloud service 333. The ICSGW service account 337 includes a data plane component (i.e., the ICSGW data plane 343) that hosts the target ICSGW 345. The target cloud service can include services such as identity management 333A, secure token service 333B, and other services 333C (e.g., queue service, storage service). The source cloud environment 301 is communicatively coupled to the target cloud environment 331 via a reliable, high-bandwidth, and low-latency communication link 350 (e.g., a FastConnect communication link). Specifically, in one embodiment, the reliable communication link 350 connects a source ICSGW 309 (disposed in the data plane 307 of the source cloud environment 301) to a target ICSGW 345 (disposed in the data plane 343 of the target cloud environment 331) via a pair of routers (e.g., a dynamic routing gateway (DRG) compatible with high-speed connection). For example, as shown in FIG. 3A, the ICSGW service tenancy 303 in the source cloud environment 301 includes a first DRG 351 compatible with high-speed connection that is communicatively coupled to a second DRG 353 compatible with high-speed connection included in the ICSGW service tenancy 337 of the target cloud environment 331.

[0024] Source ICSGW309 provides a framework that, in cooperation with target ICSGW345, facilitates access by compute instances (e.g., compute instances 315A and 317A) running in source cloud environment 301 to services (e.g., other service 333C) provided in target cloud environment 331. It is understood that the services provided in target cloud environment 331 are available not only to customers of source cloud environment 301 who have a tenancy (or account) (e.g., tenancy 335 of customer B) in target cloud environment 331, but also to customers of source cloud environment 301 who do not have a tenancy in the target cloud environment. It is noted that for customers who do not have a tenancy in target cloud environment 331, ICSGW control plane 305 of source cloud environment 301 is configured to instantiate a resource group (e.g., customer A resource group) for the customer in ICSGW service account 337 of the target cloud environment. The resource group includes resources such as queues, storage buckets, access roles, etc. It is understood that the above-described embodiment of FIG. 3A does not limit the scope of the present disclosure in any way. Rather, changes to the architecture of the inter-cloud service gateway (ICSGW) are fully encompassed within the scope of the present disclosure. For example, according to some embodiments, ICSGW data plane 307 (in source cloud environment 301) may include a pool of source ICSGWs, and ICSGW data plane 343 (in target cloud environment 331) may include a pool of target ICSGWs. In such a configuration, in order to send requests from source cloud environment 301 to target cloud environment 331, one source ICSGW from the pool of source ICSGWs and one target ICSGW from the pool of target ICSGWs can be dynamically selected based on several conditions (e.g., the current traffic load in the system).

[0025] The following provides a detailed description of how a resource (e.g., compute instance 315A) running in a source cloud environment accesses services in a target cloud environment 331. During operation, the process of facilitating access to services in the target cloud environment 331 and resources in the source cloud environment 301 includes two phases of operation, namely, a setup phase and an execution phase. In the setup phase, a dynamic group is created in the source cloud environment. The dynamic group provides a grouping of compute instances as principal actors in a similar way to grouping users into user groups. In the setup phase, a policy is created that permits compute instances within the dynamic group to issue API calls to obtain services from the target cloud environment. Membership within the dynamic group can be determined by a set of criteria referred to as matching rules. Cloud infrastructure resources (e.g., compute instances) that meet the matching rules are included as members of the dynamic group.

[0026] Furthermore, in the setup phase, each dynamic group is assigned a role (referred to herein as an access role) corresponding to a set of permissions that the members of that dynamic group can expect in the target cloud environment. Further, in the setup phase, the customer can provide information regarding whether the customer has a tenancy (i.e., an account) in the target cloud environment. Such information can include the identifier of the target cloud environment, the region of the target cloud environment, the account ID of the customer's tenancy in the target cloud environment, and the like. If the customer does not have a tenancy in the target cloud environment, it is understood that the ICSGW control plane 305 (included in the source cloud environment 301) can establish a resource group (e.g., customer A resource group 341) for the customer in the setup phase. It should be noted that the resource group is created in the ICSGW service account 337 of the target cloud environment 331.

[0027] According to some embodiments, in the setup phase, the ICSGW control plane 305 of the source cloud environment 301 can use the private access service 313B to provide a private connection between the customer VCNs (e.g., customer 1 VCN 315, customer 2 VCN 317) in the customer tenancy of the source cloud environment and the ICSGW data plane 307. Further, the ICSGW control plane 305 can program a domain name system (DNS) resolver to re-route customer traffic destined for services in the target cloud environment to the ICSGW data plane 307 in the customer VCN using the VCN / DNS infrastructure service.

[0028] In the execution phase, a compute instance (e.g., compute instance 315A) running in the customer VCN sends a request to use a service provided in the target cloud environment 331. Such a request is intercepted by the source ICSGW 309. In one embodiment, the request includes an identity principal (e.g., a certificate or credentials) associated with the compute instance. The source ICSGW extracts the identity principal from the request and performs a verification of the permissions associated with the compute instance. For example, the source ICSGW 309 communicates with the identity management service 313A of the source cloud environment 301 to verify whether a particular compute instance is permitted to issue a request to use a service provided by the target cloud environment.

[0029] Upon successful verification, the source ICSGW 309 obtains the pre-configured access role for the compute instance (i.e., in the setup phase). The source ICSGW 309 then modifies the request received from the compute instance and forwards this modified request to the target ICSGW 345 included in the target cloud environment. Note that the modified request is communicated from the source cloud environment 301 to the target cloud environment via a trusted communication channel (e.g., communication channel 350) established in the setup phase. In one embodiment, the source ICSGW 309 modifies the request by removing (i.e., deleting) the identity principal from the request and incorporating the access role into the request to form the modified request. In this way, it is ensured that the identity principal associated with the resources of the source cloud environment 301 is not sent to the target cloud environment 331.

[0030] When the target ICSGW345 receives the modified request sent by the source ICSGW309, it extracts the access role (associated with the compute instance) included in the modified request. In one embodiment, the target ICSGW345 communicates with a management service (e.g., the identity management service 333A or the secure token service 333B included in the target cloud environment 331) to obtain credentials (e.g., tokens) associated with the access role of the compute instance. The target ICSGW345 signs the modified request with the obtained credentials and forwards the signed request to a service (e.g., service 333C) that the compute instance desires to use. In one embodiment, the desired service can communicate with a management service (e.g., the identity management service 333A) of the target cloud environment 331 to determine whether the credentials used to sign the request have sufficient permissions to execute the requested action. When successfully verified, the service is executed in the customer's tenant included in the target cloud environment 331. That is, the request is executed in the customer B tenant 335 (if the customer has a tenant in the target cloud environment), or the request is executed in the customer A resource group 341 (if the customer does not have a unique tenant in the target cloud environment).

[0031] Figure 3B shows a flowchart depicting a process executed by a source inter-cloud service gateway (ICSGW) according to some embodiments. The processes shown in Figure 3B can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of respective systems, hardware, or combinations thereof. The software can be stored in a non-transitory storage medium (e.g., a memory device). The methods presented in Figure 3B and described below are intended to be exemplary and non-limiting. Figure 3B shows various processing steps occurring in a particular sequence or order, which is not intended to be limiting. In some alternative embodiments, steps may be executed in a different order or some steps may be executed in parallel.

[0032] The process begins at step 361, where the source ICSGW receives a request from a compute instance running in a source cloud environment. The request corresponds to a compute instance that requests the use of a service provided by a target cloud environment. In one embodiment, the request includes an identity principal (e.g., a certificate or credentials) associated with the compute instance. At step 363, the source ICSGW extracts the identity principal from the request and performs a verification of the permissions associated with the compute instance. For example, the source ICSGW verifies whether a particular compute instance is permitted to issue requests for services provided by the target cloud environment.

[0033] In step 365, the source ICSGW executes a query to determine whether the verification of the permission associated with the identity principal associated with the compute instance is successful. If the response to the query is affirmative (i.e., the compute instance is permitted to request services provided by the target cloud environment), the process proceeds to step 367. However, if the response to the query in step 365 is negative (i.e., the compute instance is not permitted to request services provided by the target cloud environment), the process proceeds to step 366. It is understood that the source ICSGW can verify the identity principal associated with the compute instance according to the management service of the source cloud environment (e.g., identity access management service).

[0034] In step 366 (i.e., when it is determined that the response to the query in step 365 is negative), the source ICSGW provides a response to the request sent by the compute instance. For example, the source ICSGW sends a response message to the compute instance indicating that it cannot provide the requested service of the target cloud environment to the compute instance because the identity principal of the compute instance was not successfully verified (i.e., the failure of service access). After sending the response message in step 366, the process in Figure 3A ends.

[0035] When it is determined that the response to the query in step 365 is affirmative, the process proceeds to step 376. In this step, the source ICSGW obtains the access role associated with the compute instance for the requested service from pre-configured information (e.g., information associated with the setup phase). The access role indicates the permissions associated with the compute instance in the target cloud environment (e.g., read-write permissions, read-only permissions).

[0036] Next, the process proceeds to step 369, where the source ICSGW modifies the request obtained from the compute instance to generate a modified request. In one embodiment, the source ICSGW removes the identity principal associated with the compute instance from the request and includes the access role (obtained in step 367) associated with the compute instance in the request to generate the modified request. Thereafter, the source ICSGW sends the modified request to the target ICSGW. Referring to FIG. 3A, it is understood that the modified request is sent from the source ICSGW to the target ICSGW via the reliable communication channel 350 established between the source cloud environment and the target cloud environment.

[0037] FIG. 3C shows a flowchart illustrating a process executed by a target inter-cloud service gateway (ICSGW) according to some embodiments. The process shown in FIG. 3C can be executed by software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system, hardware, or combinations thereof. The software can be stored in a non-transitory storage medium (e.g., a memory device). The method presented in FIG. 3C and described below is intended to be exemplary and non-limiting. Although FIG. 3C shows that various processing steps occur in a particular sequence or order, this is not intended to be limiting. In some alternative embodiments, the steps may be executed in some different order, or some steps may be executed in parallel.

[0038] The process starts at step 371, where the target ICSGW receives the modified request sent by the source ICSGW (i.e., the request sent by the source ICSGW in step 370 of Figure 3B). At step 373, the target ICSGW extracts the access role included in the modified request. The process then moves to step 375, where the target ICSGW communicates with the management service included in the target cloud environment (e.g., the secure token service 333B in Figure 3B). Specifically, the target ICSGW communicates with the management service to obtain the credentials (e.g., tokens) associated with the access role of the compute instance.

[0039] At step 377, the target ICSGW signs the modified request with the credentials obtained at step 375, and at step 379, the signed request is transferred to the service that the compute instance desires to use. The process then moves to step 381, where a query is executed to determine the validity of the credentials. For example, in one embodiment, the desired service communicates with the management service of the target cloud environment (e.g., the identity management service) to determine whether the credentials used to sign the request have sufficient permissions to execute the requested action. If the response to the query at step 381 is affirmative (i.e., the credentials have sufficient permissions to execute the action), the process moves to step 383. However, if the response to the query at step 381 is negative, the process moves to step 385.

[0040] In step 385, the service responds with a message indicating a failure of access to the requested action (e.g., read, write, update) that the service performs. In other words, the service notifies the target ICSGW that the requested action could not be performed due to insufficient permissions. In some embodiments, the target ICSGW can transfer the obtained response to a compute instance deployed in the source cloud environment via a reliable communication channel. However, in response to the successful verification of the credentials in step 381, the process continues in step 383 to execute the request by the desired service. Thereafter, the process shown in Figure 3B ends.

[0041] Referring now to FIGS. 4A and 4B, an exemplary process of a compute instance running in a source cloud environment utilizing a service provided in a target cloud environment according to some embodiments is illustrated. Referring to FIG. 4A, a source cloud environment 401 and a target cloud environment 451 are illustrated. The source cloud environment 401 includes a customer virtual cloud network (i.e., customer VCN 403) that hosts two applications (i.e., application 1 405A and application 2 405B). Further, the source cloud environment 401 includes a source ICSGW 407 that is communicatively coupled to a target ICSGW 459 included in the target cloud environment 451.

[0042] The target cloud environment 451 includes a target cloud service 461, a customer tenancy or account 463, and other target cloud services 453. The other target cloud services 453 can include additional services such as an identity management service 453A, a secure token service 453B, etc. For illustration purposes, the target cloud service 461 in the target cloud environment 451 that the compute instances (i.e., Application 1 405A and Application 2 405B in the source cloud environment 401) desire to utilize is illustrated as an S3 service and an SQS service. The S3 service (i.e., Simple Storage Service) is an object storage service that stores data as objects in buckets. An object is a file and any metadata that describes that file. A bucket is a container for objects. SQS (i.e., Simple Queue Service) is a managed message queuing service used to send, store, and retrieve multiple messages of various sizes asynchronously.

[0043] According to some embodiments, in the setup phase, a dynamic group is created in the source cloud environment. The dynamic group provides a grouping of compute instances as principal actors in a similar way to grouping users into user groups. In the setup phase, a policy can be created that permits compute instances within the dynamic group to issue API calls to obtain services. It is understood that the membership within the dynamic group can be determined by a set of criteria referred to as matching rules. Cloud infrastructure resources that meet the matching rules are included as members of the dynamic group. For example, as shown in FIG. 4A, Application 1 405A is included in a first dynamic group (DG1), and Application 2 405B is included in a second dynamic group (DG2).

[0044] Furthermore, in the setup phase, each dynamic group can be assigned a role (also referred to herein as an access role) corresponding to a set of permissions that the members of that dynamic group can expect in the target cloud environment. For example, as shown in FIG. 4A, Application 1 405A belonging to Dynamic Group 1 (DG1) is assigned a first role (denoted as IAM Role 1), and Application 2 405B belonging to Dynamic Group 2 (DG2) is assigned a second role (denoted as IAM Role 2). For simplicity, the permissions associated with the first role correspond to read and write permissions, and the permissions associated with the second role correspond to read-only permissions. The set of dynamic groups constructed in this way is illustrated in FIG. 4A by the dashed box 409. As shown in FIG. 4A, it is understood that the roles assigned to different dynamic groups are also instantiated in the customer account 463 in the target cloud environment during the setup phase. Specifically, in the setup phase, the customer specifies whether the customer has a customer tenancy in the target cloud environment. If the customer has a customer tenancy in the target cloud environment (e.g., customer account 463 in target cloud environment 451), then in the setup phase, information such as the target cloud environment, the customer tenancy in the target cloud environment, and the different roles assigned to the dynamic groups of the customer VCN is specified.

[0045] Furthermore, in some embodiments, compute instances in each dynamic group can be programmed to send requests for services provided in the target cloud environment to an endpoint associated with the dynamic group. The endpoint forwards such requests to the source ICSGW, which in turn forwards the requests to the target ICSGW via a secure communication channel. For example, as shown in FIG. 4A, application 1 405A included in DG1 forwards a request issued by the application (i.e., a request for a service provided in the target cloud environment) to ICSGW1 endpoint 406A, and application 2 405B included in DG2 forwards a request issued by the application to ICSGW2 endpoint 406B.

[0046] Hereinafter, with reference to FIG. 4A, the flow related to four different requests issued by compute instances included in customer VCN 403 (for services provided by the target cloud environment) will be described in detail. Specifically, flow 1 (having steps denoted as 1.1 to 1.5) corresponds to a scenario where application 1 405A issues a request to access an S3 bucket in the target cloud environment to upload a file. Flow 2 (having steps denoted as 2.1 to 2.5) corresponds to a scenario where application 1 405A issues a request to call the SQS service to send a message. Flow 3 (having steps denoted as 3.1 to 3.5) corresponds to a scenario where application 2 405B polls an SQS queue to determine the presence of a message, and flow 4 (having steps denoted as 4.1 to 4.5) corresponds to a scenario where application 2 405B issues a request to read a file.

[0047] Referring to Flow 1, in Step 1.1, Application 1 405A issues a request to upload a file. This request is transferred to Source ICSGW 407 via ICSGW1 Endpoint 406A. Source ICSGW 407 terminates the request and performs a verification check to determine whether the identity principal associated with Application 1 405A is permitted to make such a request. If successfully verified, Source ICSGW 407 modifies the request to include the access role (e.g., IAM Role 1) associated with Application 1 405A in the request. In Step 1.2, Source ICSGW 407 transfers the modified request to Target ICSGW 459. Note that the modified request is transferred via a secure communication channel (e.g., FastConnect) established between Source Cloud Environment 401 and Target Cloud Environment 451. In Step 1.3, Target ICSGW 459 extracts the corresponding access role from the modified request received from Source ICSGW 407. Target ICSGW 459 communicates with a management service (e.g., Secure Token Service 453B included in Target Cloud Service 453) to obtain the credentials associated with the access role. In Step 1.4, Target ICSGW 459 signs the modified request with the credentials obtained in (Step 1.3) and transfers the signed request to a service (e.g., Service 461 that Application 1 405A wishes to use). In Step 1.5, Target Service 461 can perform a verification to determine whether the credentials (obtained from Target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., upload the file). Further, since Application 1 405A is associated with an access role that has read and write permissions, in Step 1.5, the file is uploaded to the S3 bucket in the customer's tenancy 463.

[0048] Referring to Flow 2 here, in Step 2.1, Application 1 405A issues a request to call the SQS service in the target cloud environment (e.g., to an SQS queue) to send a message. This request is transferred to the source ICSGW 407 via the ICSGW1 endpoint 406A. The source ICSGW 407 terminates the request and performs a verification check to determine whether the identity principal associated with Application 1 405A is permitted to make such a request. When successfully verified, the source ICSGW 407 modifies the request to include the access role (e.g., IAM Role 1) associated with Application 1 405A in the request. In Step 2.2, the source ICSGW 407 transfers the modified request to the target ICSGW 459. In Step 2.3, the target ICSGW 459 extracts the corresponding access role from the modified request received from the source ICSGW 407. The target ICSGW 459 communicates with an administrative service (e.g., the Secure Token Service 453B included in the target cloud service 453) to obtain the credentials associated with the access role. In Step 2.4, the target ICSGW 459 signs the modified request with the credentials obtained in (Step 1.3) and transfers the signed request to a service (e.g., the SQS service 461 that Application 1 405A wishes to use). In Step 2.5, the target service 461 can perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., send a message to the SQS queue). Further, since Application 1 405A is associated with an access role that has read and write permissions, in Step 2.5, the message is added to the SQS queue in the customer's tenancy 463.

[0049] Refer to flow 3 corresponding to the scenario where application 2 405B polls the SQS queue to determine the presence of messages (i.e., reads messages from the SQS queue). In step 3.1, application 2 405B issues a request to fetch a message from the SQS queue. This request is transferred to the source ICSGW 407 via the ICSGW2 endpoint 406B. The source ICSGW 407 terminates the request and performs the verification as described above. When successfully verified, the source ICSGW 407 modifies the request to include the access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 3.2, the source ICSGW 407 transfers the modified request to the target ICSGW 459. In step 3.3, the target ICSGW 459 extracts the corresponding access role from the modified request received from the source ICSGW 407. The target ICSGW 459 communicates with the management service to obtain the credentials associated with the access role. In step 3.4, the target ICSGW 459 signs the modified request with the obtained credentials (from step 3.3) and transfers the signed request to the service (e.g., the SQS service 461 that application 2 405B wishes to use). In step 3.5, the target service 461 can perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., fetch a message from the SQS queue). Further, since application 2 405B is associated with an access role that has read permissions, in step 3.5, the message is fetched from the SQS queue in the customer's tenancy 463.

[0050] Refer to flow 4 corresponding to the scenario where application 2 405B makes a call to the S3 service to fetch an object from the S3 bucket. In step 4.1, application 2 405B issues a request to fetch an object from the S3 bucket. This request is transferred to the source ICSGW 407 via the ICSGW2 endpoint 406B. The source ICSGW 407 terminates the request and performs verification as described above. Once successfully verified, the source ICSGW 407 modifies the request to include the access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 4.2, the source ICSGW 407 transfers the modified request to the target ICSGW 459. In step 4.3, the target ICSGW 459 extracts the corresponding access role from the modified request received from the source ICSGW 407. The target ICSGW 459 communicates with the management service to obtain the credentials associated with the access role. In step 4.4, the target ICSGW 459 signs the modified request with the obtained credentials (from step 4.3) and transfers the signed request to the service (e.g., the S3 service 461 that application 2 405B wishes to use). In step 4.5, the target service 461 can perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., fetch an object from the S3 bucket). Further, since application 2 405B is associated with an access role having read permissions, in step 4.5, the object is fetched from the S3 bucket in the customer's tenancy 463.

[0051] Referring now to FIG. 4B, a flow regarding four different requests issued by compute instances included in customer VCN 403 (for services provided by the target cloud environment) is described in detail. Specifically, flow 5 (having steps denoted as 5.1 to 5.4) corresponds to a scenario where application 2 405B issues a request to upload a file to an S3 bucket. Flow 6 (having steps denoted as 6.1 to 6.4) corresponds to a scenario where application 2 405B issues a request to delete a message from an SQS queue. Flow 7 (having steps denoted as 7.1 to 7.5) corresponds to a scenario where application 1 405A issues a request to delete a message from an SQS queue, and flow 8 (having steps denoted as 8.1 to 8.5) corresponds to a scenario where application 1 405A issues a request to delete a file from an S3 bucket.

[0052] Refer to flow 5 corresponding to the scenario where application 2 405B issues a request to upload a file to the S3 bucket. In step 5.1, application 2 405B issues a request to upload a file to the S3 bucket. This request is transferred to the source ICSGW 407 via the ICSGW2 endpoint 406B. The source ICSGW 407 terminates the request and performs a verification check as described above. Once successfully verified, the source ICSGW 407 modifies the request to include the access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 5.2, the source ICSGW 407 transfers the modified request to the target ICSGW 459. In step 5.3, the target ICSGW 459 extracts the corresponding access role from the modified request received from the source ICSGW 407. The target ICSGW 459 communicates with the management service to obtain the credentials associated with the access role. In step 5.4, the target ICSGW 459 signs the modified request with the obtained credentials (from step 5.3) and transfers the signed request to the service (e.g., the S3 service 461 that application 2 405B wishes to use). The target service 461 performs a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., upload a file to the S3 bucket). Since application 2 405B is associated with an access role that has only read-only permissions, the S3 service in the target cloud environment rejects the request to upload a file to the S3 bucket (step 5.4). Therefore, this request is not executed by the service 461 in the customer's account 463.

[0053] Refer to flow 6 corresponding to the scenario where application 2 405B issues a request to delete a message from the SQS queue. In step 6.1, application 2 405B issues a request to delete a message from the SQS queue. This request is transferred to the source ICSGW 407 via the ICSGW2 endpoint 406B. The source ICSGW 407 terminates the request and performs a verification check as described above. When successfully verified, the source ICSGW 407 modifies the request to include the access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 6.2, the source ICSGW 407 transfers the modified request to the target ICSGW 459. In step 6.3, the target ICSGW 459 extracts the corresponding access role from the modified request received from the source ICSGW 407. The target ICSGW 459 communicates with the management service to obtain the credentials associated with the access role. In step 6.4, the target ICSGW 459 signs the modified request with the obtained credentials (from step 6.3) and transfers the signed request to the service (e.g., the SQS service 461 that application 2 405B wishes to use). The target service 461 performs a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., delete a message from the SQS queue). Since application 2 405B is associated with an access role that has only read-only permissions, the SQS service in the target cloud environment rejects the request to delete the message (step 6.4). Therefore, this request is not executed by the service 461 in the customer's account 463.

[0054] Referring to flow 7 here, in step 7.1, application 1 405A issues a request to delete a message from the SQS queue. This request is transferred to the source ICSGW 407 via the ICSGW1 endpoint 406A. The source ICSGW 407 terminates the request and performs a verification check to determine whether the identity principal associated with application 1 405A is permitted to make such a request. If successfully verified, the source ICSGW 407 modifies the request to include the access role (e.g., IAM role 1) associated with application 1 405A in the request. In step 7.2, the source ICSGW 407 transfers the modified request to the target ICSGW 459. In step 7.3, the target ICSGW 459 extracts the corresponding access role from the modified request received from the source ICSGW 407. The target ICSGW 459 communicates with the management service of the target cloud environment (e.g., the secure token service 453B included in the target cloud service 453) to obtain the credentials associated with the access role. In step 7.4, the target ICSGW 459 signs the modified request with the obtained credentials (from step 7.3) and transfers the signed request to the service (e.g., the SQS service 461 that application 1 405A wishes to use). In step 7.5, the target service 461 can perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., delete the message). Further, since application 1 405A is associated with an access role that has read and write permissions, in step 7.5, the message is deleted from the SQS queue in the customer's tenancy 463.

[0055] (Steps labeled 8.1 to 8.5) Flow 8 corresponds to the scenario where Application 1 405A issues a request to delete a file from the S3 bucket. In step 8.1, Application 1 405A issues a request to delete a file from the S3 bucket. This request is transferred to the source ICSGW 407 via the ICSGW1 endpoint 406A. The source ICSGW 407 terminates the request and performs a verification check to determine whether the identity principal associated with Application 1 405A is permitted to make such a request. If successfully verified, the source ICSGW 407 modifies the request to include the access role (e.g., IAM role 1) associated with Application 1 405A. In step 8.2, the source ICSGW 407 transfers the modified request to the target ICSGW 459. In step 8.3, the target ICSGW 459 extracts the corresponding access role from the modified request received from the source ICSGW 407. The target ICSGW 459 communicates with the management service of the target cloud environment (e.g., the secure token service 453B included in the target cloud service 453) to obtain the credentials associated with the access role. In step 8.4, the target ICSGW 459 signs the modified request with the credentials obtained in step 8.3 and transfers the signed request to the service (e.g., the S3 service 461 that Application 1 405A wishes to use). In step 8.5, the target service 461 performs a verification to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient permissions to perform the requested action (i.e., delete a file from the S3 bucket). Further, since Application 1 405A is associated with an access role that has read and write permissions, in step 8.5, the message is deleted from the S3 bucket in the customer's tenancy 463.

[0056] Note that the exemplary scenarios illustrated in FIGS. 4A and 4B correspond to the case where a customer has a tenancy in the target cloud environment, i.e., a customer account (e.g., customer B tenancy 335 in FIG. 3A). In this case, the ICSGW service account 337 is configured to manage the service (in the target cloud environment) instead of a compute instance running in the source cloud environment. It is understood that a similar set of scenarios can be implemented even when the customer does not have a tenancy in the target cloud environment. In such a case, the ICSGW control plane (305 in FIG. 3A) can be configured to set up a customer resource group (e.g., customer A resource group 341) within the ICSGW service account 337 of the target cloud environment.

[0057] Cloud Infrastructure Example FIG. 5 is a block diagram 500 showing an example pattern of an IaaS architecture according to at least one embodiment. A service operator 502 can be communicatively coupled to a secure host tenancy 504 that can include a virtual cloud network (VCN) 506 and a secure host subnet 508. In some examples, the service operator 502 may be using one or more client computing devices, and the one or more client computing devices may be software such as Microsoft Windows Mobile (registered trademark), and / or may be a portable handheld device (e.g., iPhone (registered trademark), mobile phone, iPad (registered trademark), computing tablet, personal digital assistant (PDA)), or a wearable device (Google Glass (registered trademark) head-mounted display) that runs various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and is compatible with the Internet, email, short message service (SMS), BlackBerry (registered trademark), or other communication protocols. Alternatively, the client computing device may be a general-purpose personal computer, including, by way of example, a personal computer and / or a laptop computer that runs various versions of the Microsoft Windows (registered trademark) operating system, the Apple Macintosh (registered trademark) operating system, and / or the Linux (registered trademark) operating system. The client computing device can be a workstation computer that runs any of various commercially available UNIX (registered trademark) or UNIX-like operating systems, including, without limitation, various GNU / Linux operating systems such as Google Chrome OS.Alternatively or in addition, the client computing device may be any other electronic device such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect (registered trademark) gesture input device), and / or a personal messaging device that can communicate via the VCN506 and / or a network that can access the Internet.

[0058] The VCN506 can include a Local Peering Gateway (LPG) 510, and the LPG510 can be communicatively coupled to a Secure Shell (SSH) VCN512 via the LPG510 included in the SSH VCN512. The SSH VCN512 can include an SSH subnet 514, and the SSH VCN512 can be communicatively coupled to a Control Plane VCN516 via the LPG510 included in the Control Plane VCN516. Also, the SSH VCN512 can be communicatively coupled to a Data Plane VCN518 via the LPG510. The Control Plane VCN516 and the Data Plane VCN518 can be included in a service tenancy 519 that can be owned and / or operated by an IaaS provider.

[0059] The control plane VCN 516 can include a control plane demilitarized zone (DMZ) layer 520 that acts as a border network (e.g., a portion of a corporate network between a corporate intranet and an external network). DMZ-based servers have limited responsibilities and can help suppress security breaches. Further, the DMZ layer 520 can include one or more load balancer (LB) subnets 522, a control plane application layer 524 that can include an app subnet 526, and a control plane data layer 528 that can include a database (DB) subnet 530 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 522 included in the control plane DMZ layer 520 can be communicatively coupled to the app subnet 526 included in the control plane application layer 524 and to an Internet gateway 534 that can be included in the control plane VCN 516. The app subnet 526 can be communicatively coupled to the DB subnet 530 included in the control plane data layer 528, a service gateway 536, and a network address translation (NAT) gateway 538. The control plane VCN 516 can include the service gateway 536 and the NAT gateway 538.

[0060] The control plane VCN 516 can include a data plane mirror app layer 540 that can include an app subnet 526. The app subnet 526 included in the data plane mirror app layer 540 can include a virtual network interface controller (VNIC) 542 that can execute a compute instance 544. The compute instance 544 can be communicatively coupled to the app subnet 526 of the data plane mirror app layer 540 to the app subnet 526 that can be included in the data plane app layer 546.

[0061] The data plane VCN 518 can include a data plane application layer 546, a data plane DMZ layer 548, and a data plane data layer 550. The data plane DMZ layer 548 can include an LB subnet 522 that can be communicatively coupled to the application subnet 526 of the data plane application layer 546 and the Internet gateway 534 of the data plane VCN 518. The application subnet 526 can be communicatively coupled to the service gateway 536 of the data plane VCN 518 and the NAT gateway 538 of the data plane VCN 518. The data plane data layer 550 can also include a DB subnet 530 that can be communicatively coupled to the application subnet 526 of the data plane application layer 546.

[0062] The Internet gateway 534 of the control plane VCN 516 and the Internet gateway 534 of the data plane VCN 518 can be communicatively coupled to a metadata management service 552 that can be communicatively coupled to the public Internet 554. The public Internet 554 can be communicatively coupled to the NAT gateway 538 of the control plane VCN 516 and the NAT gateway 538 of the data plane VCN 518. The service gateway 536 of the control plane VCN 516 and the service gateway 536 of the data plane VCN 518 can be communicatively coupled to a cloud service 556.

[0063] In some examples, the service gateway 536 of the control plane VCN 516 or the data plane VCN 518 can make application programming interface (API) calls to the cloud service 556 without going through the public Internet 554. The API calls from the service gateway 536 to the cloud service 556 can be one-way. That is, the service gateway 536 can make API calls to the cloud service 556, and the cloud service 556 can send the requested data to the service gateway 536. However, the cloud service 556 cannot initiate an API call to the service gateway 536.

[0064] In some examples, the secure host tenancy 504 can be directly connected to the service tenancy 519 that would otherwise be potentially isolated. The secure host subnet 508 can communicate with the SSH subnet 514 via the LPG 510 that can enable two-way communication in a system that would otherwise be isolated. By connecting the secure host subnet 508 to the SSH subnet 514, the secure host subnet 508 can access other entities within the service tenancy 519.

[0065] The control plane VCN516 can enable users of service tenancy 519 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN516 can be deployed or otherwise used in the data plane VCN518. In some examples, the control plane VCN516 can be isolated from the data plane VCN518, and the data plane mirror app layer 540 of the control plane VCN516 can communicate with the data plane app layer 546 of the data plane VCN518 via the VNIC542 that can be included in the data plane mirror app layer 540 and the data plane app layer 546.

[0066] In some examples, a user or customer of the system can make requests, such as requests for create, read, update, or delete (CRUD) operations, via the public internet 554, and the public internet 554 can communicate such requests to the metadata management service 552. The metadata management service 552 can communicate the requests to the control plane VCN516 via the internet gateway 534. The requests can be received by the LB subnet 522 included in the control plane DMZ layer 520. The LB subnet 522 may determine that the requests are valid, and in response to this determination, the LB subnet 522 can send the requests to the app subnet 526 included in the control plane app layer 524. If the requests are verified and require calls to the public internet 554, the calls to the public internet 554 can be sent to the NAT gateway 538 that can make calls to the public internet 554. Memory that may be desired to be stored by the requests can be stored in the DB subnet 530.

[0067] In some examples, the data plane mirror application layer 540 can facilitate direct communication between the control plane VCN 516 and the data plane VCN 518. For example, when it is desired to apply changes, updates, or other suitable modifications to the configuration for the resources included in the data plane VCN 518. The control plane VCN 516 can communicate directly with the resources included in the data plane VCN 518 via the VNIC 542, thereby enabling changes, updates, or other appropriate modifications to the configuration for the resources to be executed.

[0068] In some embodiments, the control plane VCN 516 and the data plane VCN 518 can be included in the service tenancy 519. In this case, the user or customer of the system does not have to own and operate either the control plane VCN 516 or the data plane VCN 518. Instead, the IaaS provider can own or operate the control plane VCN 516 and the data plane VCN 518, and both of these can be included in the service tenancy 519. This embodiment can enable network isolation, thereby preventing a user or customer from interacting with the resources of other users or other customers. Also, this embodiment can enable the user or customer of the system to store the database privately without having to rely on the public Internet 654, which may not have the desired level of security for storage.

[0069] In other embodiments, the LB subnet 522 included in the control plane VCN 516 can be configured to receive signals from the service gateway 536. In this embodiment, the control plane VCN 516 and the data plane VCN 518 can be configured to be invoked by the IaaS provider's customers without invoking the public Internet 554. Since the databases used by the customers can be controlled by the IaaS provider and stored in the service tenancy 519 that can be isolated from the public Internet 554, the IaaS provider's customers may desire this embodiment.

[0070] FIG. 6 is a block diagram 600 showing another example pattern of an IaaS architecture according to at least one embodiment. A service operator 602 (e.g., the service operator 502 of FIG. 5) can be communicatively coupled to a secure host tenancy 604 (e.g., the secure host tenancy 504 of FIG. 5) that can include a virtual cloud network (VCN) 606 (e.g., the VCN 506 of FIG. 5) and a secure host subnet 608 (e.g., the secure host subnet 508 of FIG. 5). The VCN 606 can include a local peering gateway (LPG) 610 (e.g., the LPG 510 of FIG. 5), and the LPG 610 can be communicatively coupled to a secure shell (SSH) VCN 612 (e.g., the SSH VCN 512 of FIG. 5) via the LPG 510 included in the SSH VCN 612. The SSH VCN 612 can include an SSH subnet 614 (e.g., the SSH subnet 514 of FIG. 5), and the SSH VCN 612 can be communicatively coupled to a control plane VCN 616 (e.g., the control plane VCN 516 of FIG. 5) via the LPG 610 included in the control plane VCN 616. The control plane VCN 616 can be included in a service tenancy 619 (e.g., the service tenancy 519 of FIG. 5), and the data plane VCN 618 (e.g., the data plane VCN 518 of FIG. 5) can be included in a customer tenancy 621 that can be owned or operated by a user or customer of the system.

[0071] The control plane VCN 616 can include a control plane DMZ layer 620 (e.g., the control plane DMZ layer 520 in FIG. 5) that can include an LB subnet 622 (e.g., the LB subnet 522 in FIG. 5), a control plane application layer 624 (e.g., the control plane application layer 524 in FIG. 5) that can include an application subnet 626 (e.g., the application subnet 526 in FIG. 5), and a control plane data layer 628 (e.g., the control plane data layer 528 in FIG. 5) that can include a database (DB) subnet 630 (similar to the DB subnet 530 in FIG. 5 for example). The LB subnet 622 included in the control plane DMZ layer 620 can be communicatively coupled to the application subnet 626 included in the control plane application layer 624 and to an Internet gateway 634 (e.g., the Internet gateway 534 in FIG. 5) that can be included in the control plane VCN 616. The application subnet 626 can be communicatively coupled to the DB subnet 630 included in the control plane data layer 628, to a service gateway 636 (e.g., the service gateway in FIG. 5) and to a network address translation (NAT) gateway 638 (e.g., the NAT gateway 538 in FIG. 5). The control plane VCN 616 can include the service gateway 636 and the NAT gateway 638.

[0072] The control plane VCN 616 can include a data plane mirror app layer 640 (e.g., the data plane mirror app layer 540 of FIG. 5) that can include an app subnet 626. The app subnet 626 included in the data plane mirror app layer 640 can include a virtual network interface controller (VNIC) 642 (e.g., VNIC 542) that can execute a compute instance 644 (similar to the compute instance 544 of FIG. 5 for example). The compute instance 644 can facilitate communication between the app subnet 626 of the data plane mirror app layer 640 and an app subnet 626 that can be included in a data plane app layer 646 (e.g., the data plane app layer 546 of FIG. 5) via the VNIC 642 included in the data plane mirror app layer 640 and the VNIC 642 included in the data plane app layer 646.

[0073] The internet gateway 634 included in the control plane VCN 616 can be communicatively coupled to a metadata management service 652 (e.g., the metadata management service 552 of FIG. 5) that can be communicatively coupled to a public internet 654 (e.g., the public internet 554 of FIG. 5). The public internet 654 can be communicatively coupled to a NAT gateway 638 included in the control plane VCN 616. The service gateway 636 included in the control plane VCN 616 can be communicatively coupled to a cloud service 656 (e.g., the cloud service 556 of FIG. 5).

[0074] In some examples, the data plane VCN 618 can be included in the customer tenancy 621. In this case, the IaaS provider can provide a control plane VCN 616 for each customer, and the IaaS provider can set up unique compute instances 644 included in the service tenancy 619 for each customer. Each compute instance 644 can enable communication between the control plane VCN 616 included in the service tenancy 619 and the data plane VCN 618 included in the customer tenancy 621. The compute instance 644 can enable resources provisioned in the control plane VCN 616 included in the service tenancy 619 to be deployed or otherwise used in the data plane VCN 618 included in the customer tenancy 621.

[0075] In other examples, a customer of an IaaS provider can have a database that resides in customer tenancy 621. In this example, control plane VCN 616 can include a data plane mirror app layer 640 that can include an app subnet 626. The data plane mirror app layer 640 can reside in data plane VCN 618, but the data plane mirror app layer 640 may not be present in data plane VCN 618. That is, the data plane mirror app layer 640 can access customer tenancy 621, but the data plane mirror app layer 640 may not be present in data plane VCN 618 or may not be owned and operated by the IaaS provider's customer. The data plane mirror app layer 640 may be configured to make calls to data plane VCN 618, but may not be configured to make calls to any entity included in control plane VCN 616. A customer may wish to deploy or otherwise use resources within data plane VCN 618 that are provisioned in control plane VCN 616, and the data plane mirror app layer 640 can facilitate the desired deployment or other use of the customer's resources.

[0076] In some embodiments, a customer of an IaaS provider can apply a filter to data plane VCN 618. In this embodiment, the customer can determine what the data plane VCN 618 can access, and the customer can restrict access from the data plane VCN 618 to the public Internet 654. The IaaS provider may not be able to apply a filter or otherwise control access from the data plane VCN 618 to any external network or database. A customer applying filters and controls to the data plane VCN 618 included in customer tenancy 621 can help isolate the data plane VCN 618 from other customers and from the public Internet 654.

[0077] In some embodiments, the service gateway 636 can call a cloud service 656 to access services that may not be present on the public Internet 654, on the control plane VCN 616, or on the data plane VCN 618. The connection between the cloud service 656 and the control plane VCN 616 or the data plane VCN 618 may not be live or continuous. The cloud service 656 may be present on a different network owned or operated by an IaaS provider. The cloud service 656 may be configured to receive calls from the service gateway 636 and may be configured not to receive calls from the public Internet 654. Some cloud services 656 may be isolated from other cloud services 656, and the control plane VCN 616 may be isolated from cloud services 656 that may not be in the same region as the control plane VCN 616. For example, the control plane VCN 616 may be located in "Region 1", and the cloud service "Deployment 6" may be located in Region 1 and "Region 2". If a call to Deployment 6 is made by the service gateway 636 included in the control plane VCN 616 located in Region 1, this call can be sent to Deployment 6 within Region 1. In this example, the control plane VCN 616 or Deployment 6 in Region 1 may not be communicatively coupled to or otherwise communicating with Deployment 6 in Region 2.

[0078] FIG. 7 is a block diagram 700 showing another example pattern of an IaaS architecture according to at least one embodiment. A service operator 702 (e.g., service operator 502 of FIG. 5) can be communicatively coupled to a secure host tenancy 704 (e.g., secure host tenancy 504 of FIG. 5) that can include a virtual cloud network (VCN) 706 (e.g., VCN 506 of FIG. 5) and a secure host subnet 708 (e.g., secure host subnet 508 of FIG. 5). The VCN 706 can include an LPG 710 (e.g., LPG 510 of FIG. 5), and the LPG 710 can be communicatively coupled to an SSH VCN 712 (e.g., SSH VCN 512 of FIG. 5) via the LPG 710 included in the SSH VCN 712. The SSH VCN 712 can include an SSH subnet 714 (e.g., SSH subnet 514 of FIG. 5), and the SSH VCN 712 can be communicatively coupled to a control plane VCN 716 (e.g., control plane VCN 516 of FIG. 5) via the LPG 710 included in the control plane VCN 716 and to a data plane VCN 718 (e.g., data plane 518 of FIG. 5) via the LPG 710 included in the data plane VCN 718. The control plane VCN 716 and the data plane VCN 718 can be included in a service tenancy 719 (e.g., service tenancy 519 of FIG. 5).

[0079] The control plane VCN 716 can include a control plane DMZ layer 720 (e.g., the control plane DMZ layer 520 in FIG. 5) that can include a load balancer (LB) subnet 722 (e.g., the LB subnet 522 in FIG. 5), a control plane application layer 724 (e.g., the control plane application layer 524 in FIG. 5) that can include an application subnet 726 (similar to the application subnet 526 in FIG. 5), and a control plane data layer 728 (e.g., the control plane data layer 528 in FIG. 5) that can include a DB subnet 730. The LB subnet 722 included in the control plane DMZ layer 720 can be communicatively coupled to the application subnet 726 included in the control plane application layer 724 and an Internet gateway 734 (e.g., the Internet gateway 534 in FIG. 5) that can be included in the control plane VCN 716. The application subnet 726 can be communicatively coupled to the DB subnet 730 included in the control plane data layer 728, a service gateway 736 (e.g., the service gateway in FIG. 5), and a network address translation (NAT) gateway 738 (e.g., the NAT gateway 538 in FIG. 5). The control plane VCN 716 can include the service gateway 736 and the NAT gateway 738.

[0080] The data plane VCN 718 can include a data plane application layer 746 (e.g., the data plane application layer 546 in FIG. 5), a data plane DMZ layer 748 (e.g., the data plane DMZ layer 548 in FIG. 5), and a data plane data layer 750 (e.g., the data plane data layer 550 in FIG. 5). The data plane DMZ layer 748 can include a reliable application subnet 760 and an unreliable application subnet 762 of the data plane application layer 746 included in the data plane VCN 718, and an LB subnet 722 that can be communicatively connected to the Internet gateway 734. The reliable application subnet 760 can be communicatively connected to a service gateway 736 included in the data plane VCN 718, a NAT gateway 738 included in the data plane VCN 718, and a DB subnet 730 included in the data plane data layer 750. The unreliable application subnet 762 can be communicatively connected to the service gateway 736 included in the data plane VCN 718 and the DB subnet 730 included in the data plane data layer 750. The data plane data layer 750 can include a DB subnet 730 that can be communicatively connected to the service gateway 736 included in the data plane VCN 718.

[0081] The untrusted application subnet 762 can include one or more primary VNICs 764(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 766(1)-(N). Each tenant VM 766(1)-(N) can be communicatively coupled to respective application subnets 767(1)-(N) that can be included in respective container egress VCNs 768(1)-(N) that can be included in respective customer tenancies 770(1)-(N). Each secondary VNIC 772(1)-(N) can facilitate communication between the untrusted application subnet 762 included in the data plane VCN 718 and the application subnets included in the container egress VCNs 768(1)-(N). Each container egress VCN 768(1)-(N) can include a NAT gateway 738 that can be communicatively coupled to the public Internet 754 (e.g., the public Internet 554 of FIG. 5).

[0082] The Internet gateway 734 included in the control plane VCN 716 and the Internet gateway 734 included in the data plane VCN 718 can be communicatively coupled to a metadata management service 752 (e.g., the metadata management system 552 of FIG. 5) that can be communicatively coupled to the public Internet 754. The public Internet 754 can be communicatively coupled to the NAT gateways 738 included in the control plane VCN 716 and the NAT gateways 738 included in the data plane VCN 718. The service gateways 736 included in the control plane VCN 716 and the service gateways 736 included in the data plane VCN 718 can be communicatively coupled to cloud services 756.

[0083] In some embodiments, the data plane VCN 718 can be integrated with the customer tenancy 770. This integration may be useful or desirable for customers of the IaaS provider in some cases, such as when they may desire support when running code. The customer may provide code that can be disruptive, may communicate with other customer resources, or may otherwise have undesirable effects. In response, the IaaS provider can determine whether to execute the code provided by the customer.

[0084] In some examples, the customer of the IaaS provider can permit the IaaS provider temporary network access and request a function to be attached to the data plane layer app 746. The code to execute the function can be executed on the VMs 766(1) to (N) and need not be configured to execute anywhere else on the data plane VCN 718. Each VM 766(1) to (N) can be connected to one customer tenancy 770. Each container 771(1) to (N) included in the VMs 766(1) to (N) can be configured to execute the code. In this case, there can be double isolation (e.g., the containers 771(1) to (N) execute the code and the containers 771(1) to (N) can be included at least in the VMs 766(1) to (N) included in the untrusted app subnet 762). This can help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or the networks of different customers. The containers 771(1) to (N) can be communicatively coupled to the customer tenancy 770 and configured to send or receive data from the customer tenancy 770. The containers 771(1) to (N) need not be configured to send or receive data from any other entity within the data plane VCN 718. When the execution of the code is complete, the IaaS provider can force stop or otherwise discard the containers 771(I) to (N).

[0085] In some embodiments, the trusted application subnet 760 can execute code that can be owned or operated by an IaaS provider. In this embodiment, the trusted application subnet 760 can be communicatively coupled to the DB subnet 730 and configured to perform CRUD operations in the DB subnet 730. The untrusted application subnet 762 can be communicatively coupled to the DB subnet 730, but in this embodiment, the untrusted application subnet can be configured to perform read operations within the DB subnet 730. The containers 771(1)-(N) that can be included in each customer's VM766(1)-(N) and execute code from the customer may not need to be communicatively coupled to the DB subnet 730.

[0086] In other embodiments, the control plane VCN 716 and the data plane VCN 718 may not need to be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 716 and the data plane VCN 718. However, communication can occur indirectly by at least one method. The IaaS provider may establish an LPG 710 that can facilitate communication between the control plane VCN 716 and the data plane VCN 718. In another example, the control plane VCN 716 or the data plane VCN 718 can make calls to the cloud service 756 via the service gateway 736. For example, a call from the control plane VCN 716 to the cloud service 756 can include a request for a service that can communicate with the data plane VCN 718.

[0087] FIG. 8 is a block diagram 800 showing another pattern example of an IaaS architecture according to at least one embodiment. A service operator 802 (e.g., service operator 502 in FIG. 5) can be communicatively coupled to a secure host tenancy 804 (e.g., secure host tenancy 504 in FIG. 5) that can include a virtual cloud network (VCN) 806 (e.g., VCN 506 in FIG. 5) and a secure host subnet 808 (e.g., secure host subnet 508 in FIG. 5). The VCN 806 can be communicatively coupled to an SSH VCN 812 (e.g., SSH VCN 512 in FIG. 5) via an LPG 810 (e.g., LPG 510 in FIG. 5) included in the SSH VCN 812. The SSH VCN 812 can include an SSH subnet 814 (e.g., SSH subnet 514 in FIG. 5), and the SSH VCN 812 can be communicatively coupled to a control plane VCN 816 (e.g., control plane VCN 516 in FIG. 5) via an LPG 810 included in the control plane VCN 816 and to a data plane VCN 818 (e.g., data plane 518 in FIG. 5) via an LPG 810 included in the data plane VCN 818. The control plane VCN 816 and the data plane VCN 818 can be included in a service tenancy 819 (e.g., service tenancy 519 in FIG. 5).

[0088] The control plane VCN816 can include a control plane DMZ layer 820 (e.g., the control plane DMZ layer 520 in FIG. 5) that can include an LB subnet 822 (e.g., the LB subnet 522 in FIG. 5), a control plane app layer 824 (e.g., the control plane app layer 524 in FIG. 5) that can include an app subnet 826 (e.g., the app subnet 526 in FIG. 5), and a control plane data layer 828 (e.g., the control plane data layer 528 in FIG. 5) that can include a DB subnet 830 (e.g., the DB subnet 730 in FIG. 7). The LB subnet 822 included in the control plane DMZ layer 820 can be communicatively coupled to the app subnet 826 included in the control plane app layer 824 and to an internet gateway 834 (e.g., the internet gateway 534 in FIG. 5) that can be included in the control plane VCN816. The app subnet 826 can be communicatively coupled to the DB subnet 830 included in the control plane data layer 828, to a service gateway 836 (e.g., the service gateway in FIG. 5), and to a network address translation (NAT) gateway 838 (e.g., the NAT gateway 538 in FIG. 5). The control plane VCN816 can include the service gateway 836 and the NAT gateway 838.

[0089] The data plane VCN 818 can include a data plane application layer 846 (e.g., the data plane application layer 546 in FIG. 5), a data plane DMZ layer 848 (e.g., the data plane DMZ layer 548 in FIG. 5), and a data plane data layer 850 (e.g., the data plane data layer 550 in FIG. 5). The data plane DMZ layer 848 can include a trusted application subnet 860 (e.g., the trusted application subnet 760 in FIG. 7) and an untrusted application subnet 862 (e.g., the untrusted application subnet 762 in FIG. 7) included in the data plane VCN 818, and an LB subnet 822 that can be communicatively coupled to the Internet gateway 834. The trusted application subnet 860 can 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 subnet 830 included in the data plane data layer 850. The untrusted application subnet 862 can be communicatively coupled to the service gateway 836 included in the data plane VCN 818 and the DB subnet 830 included in the data plane data layer 850. The data plane data layer 850 can include a DB subnet 830 that can be communicatively coupled to the service gateway 836 included in the data plane VCN 818.

[0090] The untrusted application subnet 862 can include primary VNICs 864(1) to (N) that can be communicatively coupled to tenant virtual machines (VMs) 866(1) to (N) resident within the untrusted application subnet 862. Each tenant VM 866(1) to (N) can execute code in respective containers 867(1) to (N) and can be communicatively coupled to an application subnet 826 that can be included in a data plane application layer 846 that can be included in a container egress VCN 868. Each secondary VNIC 872(1) to (N) can facilitate communication between the untrusted application subnet 862 included in the data plane VCN 818 and the application subnet included in the container egress VCN 868. The container egress VCN 868 can include a NAT gateway 838 that can be communicatively coupled to a public internet 854 (e.g., the public internet 554 of FIG. 5).

[0091] The internet gateway 834 included in the control plane VCN 816 and the internet gateway 834 included in the data plane VCN 818 can be communicatively coupled to a metadata management service 852 (e.g., the metadata management system 552 of FIG. 5) that can be communicatively coupled to the public internet 854. The public internet 854 can be communicatively coupled to the 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 can be communicatively coupled to a cloud service 856.

[0092] In some examples, the pattern shown by the architecture of block diagram 800 of FIG. 8 may be considered an exception to the pattern shown by the architecture of block diagram 600 of FIG. 6 and may be desirable for customers of the IaaS provider when the IaaS provider cannot communicate directly with the customer (e.g., in a non-connected region). The customer can access each of the containers 867(1) to (N) included in each customer's VMs 866(1) to (N) in real time. The containers 867(1) to (N) can be configured to call each of the secondary VNICs 872(1) to (N) included in the app subnet 826 of the data plane app layer 846 that can be included in the container egress VCN 868. The secondary VNICs 872(1) to (N) can send the call to a NAT gateway 838 that can send the call to the public internet 854. In this example, the containers 867(1) to (N) that the customer can access in real time can be isolated from the control plane VCN 816 and from other entities included in the data plane VCN 818. The containers 867(1) to (N) can also be isolated from the resources of other customers.

[0093] In other examples, a customer can use containers 867(1) to (N) to invoke cloud service 856. In this example, the customer can execute code in containers 867(1) to (N) that requests a service from cloud service 856. Containers 867(1) to (N) can send this request to secondary VNICs 872(1) to (N), which can send the request to a NAT gateway that can send the request to public internet 854. Public internet 854 can send this request to LB subnet 822 included in control plane VCN 816 via internet gateway 834. In response to determining that the request is valid, the LB subnet can send this request to app subnet 826, which can send this request to cloud service 856 via service gateway 836.

[0094] It should be understood that the IaaS architectures 500, 600, 700, 800 shown in the figures may include components other than those shown. Further, the embodiments shown in the figures are merely examples of a part of a cloud infrastructure system that can incorporate embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown in the figures, may combine two or more components, or may have different configurations or arrangements of components.

[0095] In some embodiments, the IaaS systems described herein can include a set of application, middleware, and database service offerings that are provided 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 present assignee.

[0096] FIG. 9 shows an example computer system 900 that can execute various embodiments. System 900 can be used to execute any of the computer systems described above. As shown in the figure, computer system 900 includes a processing unit 904 that communicates with a plurality of peripheral subsystems via a bus subsystem 902. These peripheral subsystems can include a processing acceleration unit 906, an I / O subsystem 908, a storage subsystem 918, and a communication subsystem 924. Storage subsystem 918 includes a tangible computer-readable storage medium 922 and system memory 910.

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

[0098] The processing unit 904, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 900. The processing unit 904 can include one or more processors. These processors can include single-core processors or multi-core processors. In some embodiments, the processing unit 904 can be implemented as one or more independent processing units 932 and / or 934 having single-core or multi-core processors included in each processing unit. In other embodiments, the processing unit 904 may be implemented as a quad-core processing unit formed by integrating two dual-core processors on a single chip.

[0099] In various embodiments, the processing unit 904 can execute various programs according to program code and can maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed can be present in the processor 904 and / or the storage subsystem 918. Through suitable programming, the processor 904 can provide the various functions described above. The computer system 900 can further include a processing acceleration unit 906, which can include a digital signal processor (DSP), an application-specific processor, and the like.

[0100] The I / O subsystem 908 can include user interface input devices and user interface output devices. User interface input devices can include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen incorporated in a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device having a voice command recognition system, a microphone, and other types of input devices. The user interface input devices can enable a user to control and interact with an input device such as a Microsoft Xbox (registered trademark) 360 game controller through, for example, a natural user interface that uses gestures and spoken commands, and can include a motion sensing and / or gesture recognition device such as a Microsoft Kinect (registered trademark) motion sensor. The user interface input devices can also include an eye gesture recognition device such as a Google Glass (registered trademark) blink detector that detects eye activity (e.g., a "blink" during photo taking and / or menu selection) from the user and converts the eye gesture into an input to the input device (e.g., Google Glass (registered trademark)). Further, the user interface input devices may include a voice recognition sensing device that enables the user to interact with a voice recognition system (e.g., a Siri (registered trademark) navigator) via voice commands.

[0101] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, joystick or pointing stick, game pad and graphic tablet, and audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, web cameras, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye tracking devices. Further, the user interface input device may include, for example, medical image input devices such as computed tomography devices, magnetic resonance imaging devices, positron emission tomography devices, and medical ultrasonic inspection devices. The user interface input device may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, etc.

[0102] The user interface output device can include a non-visual display such as a display subsystem, indicator light, or audio output device. The display subsystem may be, for example, a flat panel device using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. Generally, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 900 to the user or another computer. For example, the user interface output device can include, but is not limited to, monitors, printers, speakers, headphones, automotive navigation systems, plotters, audio output devices, and modems, and various display devices for visually conveying text, graphics, and audio / video information.

[0103] The computer system 900 can include a storage subsystem 918 that includes software elements shown as being currently located within system memory 910. The system memory 910 can store program instructions that are loadable into and executable by the processing unit 904, and data generated during the execution of these programs.

[0104] Depending on the configuration and type of computer system 900, system memory 910 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically includes data and / or program modules that are immediately accessible and / or currently being operated on and executed by processing unit 904. In some embodiments, system memory 910 can include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, ROM can typically store a basic input / output system (BIOS) that includes basic routines useful for transferring information between elements within computer system 900, such as during startup. By way of example and not limitation, system memory 910 also shows application program 912, which can include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 914, and operating system 916. By way of example, operating system 916 can include various versions of Microsoft Windows (registered trademark), Apple Macintosh (registered trademark), and / or Linux operating systems, various commercially available UNIX (registered trademark) or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome (registered trademark) OS, etc.), and / or mobile operating systems such as iOS, Windows (registered trademark) Phone, Android (registered trademark) OS, BlackBerry (registered trademark) 10 OS, and Palm (registered trademark) OS.

[0105] The storage subsystem 918 can also provide a tangible computer-readable storage medium for storing the basic programming and data structures that provide the functionality of some embodiments. The storage subsystem 918 can store software (programs, code modules, instructions) that, when executed by a processor, provides the functionality described above. These software modules or instructions can be executed by the processing unit 904. The storage subsystem 918 can also provide a repository for storing data used in accordance with the present disclosure.

[0106] The storage subsystem 900 can also include a computer-readable storage medium reader 920 that can be further connected to a computer-readable storage medium 922. Together with the system memory 910, optionally in combination, the computer-readable storage medium 922 can comprehensively represent by adding storage media to remote, local, fixed, and / or removable storage devices for temporarily and / or more permanently accommodating, storing, transmitting, and acquiring computer-readable information.

[0107] A computer-readable storage medium 922 that includes code, or a portion of code, can include any suitable medium known or used in the art, including, but not limited to, storage media and communication media such as volatile and non-volatile, removable and non-removable media implemented in any method or technology for the storage and / or transmission of information. This can include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disks (DVD) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or other tangible computer-readable media. This can also include non-tangible computer-readable media such as data signals, data transmissions, or any other medium that can be used to transmit desired information and that can be accessed by computing system 900.

[0108] As an example, computer-readable storage medium 922 can include a hard disk drive that reads from or writes to a non-removable non-volatile magnetic medium, a magnetic disk drive that reads from or writes to a removable non-volatile magnetic disk, and an optical disk drive that reads from or writes to a removable non-volatile optical disk such as a CD ROM, DVD, and Blu-Ray (registered trademark) disk, or other optical media. Examples of computer-readable storage medium 922 can include, but are not limited to, Zip (registered trademark) drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tapes, etc. Computer-readable storage medium 922 can also include solid state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, solid state ROMs, 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. Disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 900.

[0109] Communication subsystem 924 provides an interface to other computer systems and networks. The communication subsystem 924 functions as an interface for receiving data from the computer system 900 and transmitting data from the computer system 900 to other systems. For example, the communication subsystem 924 can enable the computer system 1000 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 924 can include radio frequency (RF) transceiver components, a global positioning system (GPS) receiver component, and / or other components for accessing wireless voice and / or data networks (e.g., using cellular phone technology, advanced data network technologies such as 3G, 4G, or EDGE (enhanced data rates for global evolution), Wi-Fi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof)). In some embodiments, the communication subsystem 924 can provide wired network connectivity (e.g., Ethernet (registered trademark)) in addition to or instead of a wireless interface.

[0110] In some embodiments, the communication subsystem 924 can also receive input communications in the form of structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc., on behalf of one or more users who can use the computer system 900.

[0111] As an example, the communication subsystem 924 may be configured to receive in real time a data feed 926 from users of social networks and / or other communication services, such as Twitter (registered trademark) feeds, Facebook (registered trademark) updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0112] Furthermore, the communication subsystem 924 may be configured to receive data in the form of a continuous data stream that can include an event stream 928 and / or event updates 930 of real-time events that may be inherently continuous or infinite with no clear end. Examples of applications that generate continuous data can include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0113] The communication subsystem 924 may also be configured to output structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc., to one or more databases that can communicate with one or more streaming data source computers coupled to the computer system 900.

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

[0115] Since the nature of computers and networks is constantly changing, the description of the computer system 900 shown in the figures is merely intended as a specific example. Many other configurations are possible that have more or fewer components than the system shown in the figures. For example, customized hardware may be used and / or certain elements may be implemented in hardware, firmware, software (including applets), or combinations. Additionally, connections to other computing devices such as network input / output devices may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will understand other manners and / or methods for implementing various embodiments.

[0116] While specific embodiments have been described, various changes, modifications, alternative structures, and equivalents are also encompassed within the scope of the present disclosure. Embodiments are not limited to operating within a certain specific data processing environment and can operate freely within multiple data processing environments. Further, while embodiments have been described using a particular series of transactions and steps, it should be apparent to one of ordinary skill in the art that the scope of the present disclosure is not limited to the series of transactions and steps described. The various features and aspects of the embodiments described above may be used individually or jointly.

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

[0118] Accordingly, the specification and drawings are to be considered in an illustrative rather than a restrictive sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and changes may be made without departing from the broader spirit and scope as set forth in the claims. Thus, while specific embodiments of the disclosure have been described, these are not intended to be limiting. Various variations and equivalents are within the scope of the following claims.

[0119] In the context of describing the disclosed embodiments (particularly in the context of the following claims), the use of the terms "a," "an," and "the" and similar referents should be interpreted to include both the singular and the plural, unless the context clearly dictates otherwise and there is no specific indication in this specification. The terms "comprising," "having," "including," and "containing" should be interpreted as open-ended terms (i.e., meaning "including but not limited to") unless otherwise specified. The term "connected" should be interpreted as being either partially or wholly within, attached to, or joined to one another, even if there are intervening elements. The recitation of a range of values herein is merely intended to serve as a shorthand way of referring individually to each separate value within that range, and each separate value is incorporated herein as if it were individually recited herein, unless otherwise indicated in this specification. Unless otherwise indicated in this specification or clearly inconsistent with the context, all methods described herein can be performed in any suitable order. The use of any examples, or exemplary language (e.g., "such as") provided herein is merely intended to make the embodiments clearer and does not limit the scope of the disclosure unless otherwise claimed. No language in this specification should be construed as indicating that any non-claimed element is essential for the practice of the disclosure.

[0120] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is generally used and understood within the context to indicate that items, terms, etc. may be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically provided otherwise. Thus, such disjunctive language is not generally intended, nor should it be taken, to mean that some embodiments require the presence of at least one of each of at least one of X, at least one of Y, or at least one of Z.

[0121] This specification describes preferred embodiments of the present disclosure, including the best mode known to the applicant for practicing the disclosure. Variations of these preferred embodiments will be apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to adopt such variations as appropriate, and the present disclosure may be practiced in ways other than 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. Further, any combination of the above-described elements in all possible variations thereof, unless otherwise indicated herein, is included within the scope of the present disclosure.

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

[0123] In the foregoing specification, embodiments of the present disclosure have been described with reference to specific embodiments, but those skilled in the art will recognize that the present disclosure is not limited thereto. The various features and aspects of the disclosure described above can be used individually or in combination. Further, the embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method comprising: a compute instance running in a source cloud environment generating a request to use a service provided in a target cloud environment, wherein the source cloud environment is different from the target cloud environment, the method further comprising: sending the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway; and based on an access role associated with the compute instance, executing the service in the target cloud environment.

2. The method further comprising the compute instance sending the request to a source inter-cloud service gateway located in the source cloud environment, wherein the request includes an identity principal associated with the compute instance, The method of claim 1, further comprising the source inter-cloud service gateway verifying the identity principal of the compute instance.

3. Verifying the identity principal includes verifying whether the compute instance is permitted to access the service in the target cloud environment, the method of claim 2.

4. In response to successful verification of the identity principal, the method of claim 2, further comprising the source inter-cloud service gateway obtaining the access role associated with the compute instance from pre-configured information stored in the source cloud environment.

5. The method further includes, in response to the identity principal being successfully verified, the source inter-cloud service gateway modifying the request to generate a modified request, wherein modifying the request includes removing the identity principal included in the metadata of the request and incorporating the access role associated with the compute instance into the metadata, The method according to claim 4, further comprising the source inter-cloud service gateway sending the modified request to a target inter-cloud service gateway disposed in the target cloud environment. **Claim 6** The source inter-cloud service gateway is disposed in a first data plane of the source cloud environment, the target inter-cloud service gateway is disposed in a second data plane of the target cloud environment, and the source inter-cloud service gateway is communicatively coupled to the target inter-cloud service gateway via a reliable communication channel. The method according to claim 5. **Claim 7** The method according to claim 5, further comprising the target inter-cloud service gateway extracting the access role associated with the compute instance from the modified request, and the target inter-cloud service gateway obtaining a token associated with the access role from a management service included in the target cloud environment. **Claim 8** The method according to claim 5, further comprising the target inter-cloud service gateway signing the modified request with the token associated with the access role to form a signed modified request. The method of claim 7, further comprising transferring the signed, modified request to the service that the compute instance desires to use. **Claim 9** The service validating the signed, modified request based on the token, The method of claim 8, further comprising the service executing the request in response to successful validation. **Claim 10** A computer-readable medium storing specific computer-executable instructions that, when executed by a processor, cause a computer system to, at least, generate a request to use a service provided in a target cloud environment by a compute instance running in a source cloud environment, wherein the source cloud environment is different from the target cloud environment, the computer-executable instructions cause the computer system to, at least, send the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway, and further cause execution of the service in the target cloud environment based on an access role associated with the compute instance. **Claim 11** The computer system is further configured to send the request by the compute instance to a source inter-cloud service gateway located in the source cloud environment, wherein the request includes an identity principal associated with the compute instance, The computer-readable medium storing the specific computer-executable instructions according to claim 10, wherein the computer system is further configured to verify the identity principal of the compute instance by the source inter-cloud service gateway. **Claim 12** The computer-readable medium storing the specific computer-executable instructions according to claim 11, wherein verifying the identity principal includes verifying whether the compute instance is permitted to access the service in the target cloud environment. **Claim 13** The computer-readable medium storing the specific computer-executable instructions according to claim 11, wherein, in response to successful verification of the identity principal, the computer system is further configured to obtain, by the source inter-cloud service gateway, the access role associated with the compute instance from pre-configured information stored in the source cloud environment. **Claim 14** In response to successful verification of the identity principal, the computer system is further configured to modify the request by the source inter-cloud service gateway to generate a modified request, wherein modifying includes removing the identity principal included in the metadata of the request and incorporating the access role associated with the compute instance into the metadata, The computer-readable medium storing the specific computer-executable instructions according to claim 13, wherein the computer system is further configured to send the modified request to a target inter-cloud service gateway disposed in the target cloud environment by the source inter-cloud service gateway. **Claim 15** The source inter-cloud service gateway is arranged in a first data plane of the source cloud environment, the target inter-cloud service gateway is arranged in a second data plane of the target cloud environment, and the source inter-cloud service gateway is communicatively connected to the target inter-cloud service gateway via a reliable communication channel. A computer-readable medium storing the specific computer-executable instructions according to claim 14.

16. The computer system is configured to extract, by the target inter-cloud service gateway, the access role associated with the compute instance from the changed request, and further configured to obtain, by the target inter-cloud service gateway, a token associated with the access role from a management service included in the target cloud environment. A computer-readable medium storing the specific computer-executable instructions according to claim 14.

17. The computer system is configured to sign, by the target inter-cloud service gateway, the changed request with the token associated with the access role to form a signed changed request, and further configured to transfer the signed changed request to the service that the compute instance desires to use. A computer-readable medium storing the specific computer-executable instructions according to claim 16.

18. A system comprising a processor and a memory including instructions, where when the instructions are executed by the processor, the system is caused to at least Cause a compute instance running in a source cloud environment to generate a request to use a service provided in a target cloud environment, wherein the source cloud environment is different from the target cloud environment, The instructions cause the system to, at least, Send the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway, And further cause the service to be executed in the target cloud environment based on an access role associated with the compute instance.

19. The system is further configured to cause the compute instance to send the request to a source inter-cloud service gateway located in the source cloud environment, wherein the request includes an identity principal associated with the compute instance, The system according to claim 18, further configured to cause the source inter-cloud service gateway to verify the identity principal of the compute instance.

20. The system according to claim 19, configured to verify the identity principal by verifying whether the compute instance is permitted to access the service in the target cloud environment.

Images