Inter-cloud service gateway

Abstract

A framework is discussed herein 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. A computing instance executing in a source cloud environment generates a request to use a service provided in a target cloud environment. The request is transmitted from the source cloud environment to the target cloud environment through the inter-cloud service gateway. The service is executed in the target cloud environment based on the access role associated with the compute instance.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of the filing date of U.S. Non-Provisional Application No. 17 / 742,472, filed May 12, 2022, the contents of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] 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 services is provided without exchanging or sharing identity principals (e.g., certificates or credentials) associated with resources between the two cloud environments. Background Art

[0004] Users or customers of public clouds want to get the best of the best services from various cloud service providers. In cloud environments, the current paradigm of such service design encourages building on top of local services provided by cloud environments. Cross-cloud or inter-cloud service access is not easily available. Therefore, users design their own customized solutions to access services provided in a second cloud environment that is different from and independent of the first cloud environment from a first cloud environment. Typical solutions designed to obtain access to services provided by another cloud service provider are time-consuming, error-prone, and expensive. In addition, one of the main drawbacks of typical access solutions is credential management. Specifically, accessing services provided in a first cloud environment from resources deployed in a second cloud environment involves establishing a network connection between the two cloud environments. In such a framework, accessing services in the first cloud environment involves users distributing their credentials through the cloud infrastructure. Such solutions are inherently unsafe and inconvenient.

[0005] Embodiments described herein address these and other issues related to migrating applications between different cloud environments. Summary of the invention

[0006] The present 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 services is provided without exchanging or sharing identity principals (e.g., certificates or credentials) associated with resources between the two cloud environments. Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, codes, or instructions executable by one or more processors, and the like. Mention of these illustrative embodiments is not intended to limit or define the present disclosure, but rather to provide examples to aid understanding. Other embodiments are discussed in the detailed description section, and further description is provided therein.

[0007] One aspect of the present disclosure provides a method, including: generating, by a computing instance executing in a source cloud environment, a request to use a service provided in a target cloud environment, the source cloud environment being different from the target cloud environment; 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 computing instance.

[0008] Another aspect of the present disclosure provides a computer-readable medium storing specific computer-executable instructions, which, 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 computing instance executing in a source cloud environment, the source cloud environment being different from the target cloud environment; send the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway; and execute the service in the target cloud environment based on an access role associated with the computing instance.

[0009] One aspect of the present disclosure provides a system including a processor and a memory, the memory including instructions that, when executed by the processor, cause the system to at least: generate, by a computing instance executing in a source cloud environment, a request to use a service provided in a target cloud environment, the source cloud environment being different from the target cloud environment; send the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway; and execute the service in the target cloud environment based on an access role associated with the computing instance.

[0010] The foregoing and other features and embodiments will become more apparent upon reference to the following description, claims and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 Depicted is an exemplary high-level architecture of an Inter-Cloud Services Gateway (ICSGW) according to various embodiments.

[0012] Figure 2 Depicted is a flow diagram of a process performed by an Inter-Cloud Services Gateway (ICSGW) in accordance with various embodiments.

[0013] Figure 3A Depicted is a detailed architecture of an Inter-Cloud Services Gateway (ICSGW) according to various embodiments.

[0014] Figure 3B Depicted is a flow diagram of a process performed by a source inter-cloud services gateway in accordance with certain embodiments.

[0015] Figure 3C A flow diagram of a process performed by a target inter-cloud services gateway is depicted according to certain embodiments.

[0016] Figure 4ADepicted is an exemplary process for a computing instance executing in a source cloud environment to utilize services provided in a target cloud environment in accordance with some embodiments.

[0017] Figure 4B Another exemplary process of utilizing services provided in a target cloud environment to execute a computing instance in a source cloud environment is depicted in accordance with some embodiments.

[0018] Figure 5 is a block diagram depicting one mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0019] Figure 6 is a block diagram depicting another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0020] Figure 7 is a block diagram depicting another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0021] Figure 8 is a block diagram depicting another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0022] Fig. 9 is a block diagram of an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION

[0023] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will be appreciated by those skilled in the art that the embodiments may be implemented without the specific details. In addition, well-known features may be simplified in order not to obscure the described embodiments.

[0024] In cloud computing, a cloud is a collection of servers that cloud customers access over a communications network (e.g., the Internet). Cloud service providers (CSPs), who provide various services to customers, manage the cloud's infrastructure. In contrast, a multi-cloud environment typically involves the use of several cloud infrastructures, each managed by a unique CSP. Multi-cloud deployments serve a variety of purposes. A multi-cloud deployment may utilize multiple Infrastructure as a Service (IaaS) vendors, or it may use different vendors for IaaS, Platform as a Service (PaaS), and Software as a Service (SaaS) services. Multi-cloud can be purely for redundancy and system backup purposes, or a multi-cloud deployment may incorporate different cloud vendors for different services.

[0025] So far, most multi-cloud solutions have focused primarily on simplifying network access. Users or customers with accounts at different CSPs can access resources in different clouds based on identity federation (i.e., a federation of the user's identities). Specifically, identity federation is a system for establishing trust between two parties in order to authenticate the user and pass the information needed to authorize him to access resources. However, this framework does not naturally extend to establishing trust between resources (i.e., non-user actors such as compute instances, VMs, functions).

[0026] In addition, customers prefer to keep their traffic from compute workloads (i.e., VMs, containers, functions) to cloud services private as much as possible and avoid distributing their long-term credentials to these compute workloads. Customers can achieve this type of communication, but only within their respective cloud provisioning environments, i.e., within a single cloud environment. There is currently no mechanism to achieve a similar communication pattern in an inter-cloud environment. Embodiments of the present disclosure provide an Inter-Cloud Service Gateway (ICSGW) that aims to provide a framework with which customers can configure their compute workloads or compute instances in one cloud environment (e.g., managed by a first CSP) to access services in a different cloud environment (i.e., managed by a second CSP) in a more secure manner.

[0027] Figure 1 Depicted is an exemplary high-level architecture of an Inter-Cloud Services Gateway (ICSGW) according to various embodiments. Figure 1 The high-level architecture 100 depicted in FIG. 1 includes an inter-cloud service gateway 105, which is a multi-tenant service seamlessly provided between a source cloud environment 101 and a target cloud environment 107. Specifically, the ICSGW 105 has footprints in both the source cloud environment 101 and the target cloud environment 107.

[0028] 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 services 109 provided by the target cloud environment 107 via the ICSGW 105. It should be understood that the services 109 provided by the target cloud environment 107 can be used by customers who have a tenancy in the target cloud environment 107 (i.e., a customer account in the target cloud environment 107) as well as customers who do not have a customer tenancy.

[0029] According to some embodiments, when a computing workload (e.g., a computing instance 102 in a source cloud environment 101) accesses a target service 109 in a target cloud environment using an identity principal (i.e., a resource principal corresponding to an identity of a resource) available locally in the source cloud environment 101, the ICSGW 105 service performs a set of actions. In one implementation, the set of actions includes at least: (i) intercepting requests / responses between the computing workload and the target service; (ii) verifying the identity principal associated with the computing instance; (iii) converting the identity principal into an access role of the computing instance in the target cloud environment; and (iv) forwarding the request to the final destination (e.g., the desired service) in the target cloud environment. In other words, the computing instance 102 in the source cloud environment generates a request to access the service 109 in the target cloud environment. The request is further transmitted 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 privileges) associated with the computing instance in the source cloud environment 101. In addition, the following references Figures 3A to 3C The architecture of the ICSGW 105 and the process of initiating services (in a target cloud environment) for use by computing instances in a source cloud environment are described in detail.

[0030] Figure 2 A high-level flow chart of a process performed by an Inter-Cloud Services Gateway (ICSGW) according to various embodiments is depicted. Specifically, Figure 2 A process is shown of steps for provisioning computing instances (eg, virtual machines, containers, functions) executing in a source cloud environment to access services provided in a target cloud environment via an ICSGW. Figure 2 The depicted processes may be implemented in software (e.g., code, instructions, programs), hardware, or a combination thereof, executed by one or more processing units (e.g., processors, cores) of the corresponding system. The software may be stored on a non-volatile storage medium (e.g., on a memory device). Figure 2 The methods presented in and described below are intended to be illustrative and non-limiting. Figure 2 Describe various processing steps that occur in a specific order or sequence, but this is not intended to be limiting. In some alternative embodiments, these steps can be performed in a different order, or some steps can also be performed in parallel.

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

[0032] In step 203, the request generated by the computing instance is transmitted from the source cloud environment to the target cloud environment via the inter-cloud service gateway. Figure 3A As described, a request is transmitted from a source inter-cloud service gateway (deployed in a source cloud environment) to a target inter-cloud service gateway (deployed in a target cloud environment), and the source inter-cloud service gateway and the target inter-cloud service gateway are communicatively coupled via a trusted communication channel (e.g., a Fastconnect communication channel). After the request is transmitted 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 computing instance.

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

[0034] 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 lease 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 lease 303 includes a control plane component (i.e., ICSGW control plane 305) and a data plane component (i.e., ICSGW data plane 307). The source ICSGW 309 is hosted in the ICSGW data plane 307. The source cloud service 313 includes multiple services, including identity and management services 313A and private access services 313B. Each customer VCN includes a computing instance executed therein (e.g., customer 1 VCN 315 includes a computing instance 315A, and customer 2 VCN 317 includes another computing instance 317A).

[0035] The target cloud environment 331 includes an ICSGW service account (or service lease) 337 and a target cloud service 333. The ICSGW service account 337 includes a data plane component (i.e., an ICSGW data plane 343) that hosts the target ICSGW 345. The target cloud service may include services such as identity management 333A, security 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 trusted, high-bandwidth, and low-latency communication link 350 (e.g., a fast connect communication link). Specifically, by one embodiment, a trusted communication link 350 is established by connecting the source ICSGW 309 (set in the data plane 307 of the source cloud environment 301) to the target ICSGW 345 (set in the data plane 343 of the target cloud environment 331) via a pair of routers (e.g., a dynamic routing gateway (DRG) that supports fast connect). For example, as Figure 3A As shown in , the ICSGW service lease 303 in the source cloud environment 301 includes a first DRG 351 supporting fast connection, which is communicatively coupled to a second DRG 353 supporting fast connection included in the ICSGW service lease 337 of the target cloud environment 331 .

[0036] The source ICSGW 309, together with the target ICSGW 345, provides a framework that facilitates computing instances executing in the source cloud environment 301 (e.g., computing instances 315A and 317A) to access services provided in the target cloud environment 331 (e.g., other services 333C). It should be noted that the services provided in the target cloud environment 331 are available to customers of the source cloud environment 301 that have a lease (or account) in the target cloud environment 331 (e.g., Customer B lease 335) as well as to customers of the source cloud environment 301 that do not have a lease in the target cloud environment. It should be noted that for customers that do not have a lease in the target cloud environment 331, the ICSGW control plane 305 of the source cloud environment 301 is configured to instantiate a resource group for the customer (e.g., Customer A resource group) in the ICSGW service account 337 of the target cloud environment. Resource groups include resources such as queues, buckets, access roles, etc. It will be understood that Figure 3AThe above-described embodiments do not limit the scope of the present disclosure in any way. On the contrary, modifications to the architecture of the Inter-Cloud Service Gateway (ICSGW) are entirely within the scope of the present disclosure. For example, according to some embodiments, the ICSGW data plane 307 (in the source cloud environment 301) may include a source ICSGW pool, and the ICSGW data plane 343 (in the target cloud environment 331) may include a target ICSGW pool. In such a setting, a source ICSGW in the source ICSGW pool and a target ICSGW in the target ICSGW pool may be dynamically selected based on certain conditions (e.g., the current traffic load in the system) to transmit requests from the source cloud environment 301 to the target cloud environment 331.

[0037] Below, a detailed description is provided about how resources (e.g., compute instance 315A) executing in a source cloud environment access services in a target cloud environment 331. In operation, the process of facilitating access to services in the target cloud environment 331 and resources in the source cloud environment 301 includes two operational phases: a setup phase and an execution phase. In the setup phase, dynamic groups are created in the source cloud environment. Dynamic groups provide for grouping compute instances as primary actors in a manner similar to grouping users into user groups. Policies are created in the setup phase that permit compute instances in a dynamic group to issue API calls to obtain services from the target cloud environment. Membership in a dynamic group can be determined by a set of criteria referred to as matching rules. Cloud infrastructure resources (e.g., compute instances) that satisfy the matching rules are included as members of the dynamic group.

[0038] In addition, during the establishment phase, each dynamic group is assigned a role (referred to herein as an access role) corresponding to a set of privileges that members of the dynamic group can enjoy in the target cloud environment. In addition, during the establishment phase, the customer can provide information about whether the customer has a lease (i.e., an account) in the target cloud environment. Such information may include an identifier of the target cloud environment, the region of the target cloud environment, the account ID of the customer's lease in the target cloud environment, etc. It should be understood that in the event that the customer does not have a lease in the target cloud environment, the ICSGW control plane 305 (included in the source cloud environment 301) can establish a resource group for the customer (e.g., customer A resource group 341) during the establishment phase. Note that the resource group is created in the ICSGW service account 337 of the target cloud environment 331.

[0039] According to some embodiments, during the setup phase, the ICSGW control plane 305 of the source cloud environment 301 utilizes private access services 313B to provide private connectivity from customer VCNs in customer tenancies of the source cloud environment (e.g., customer 1 VCN 315, customer 2 VCN 317) to the ICSGW data plane 307. In addition, the ICSGW control plane 305 can utilize VCN / DNS infrastructure services to program a Domain Name System (DNS) resolver in the customer VCN to reroute customer traffic destined for services in the target cloud environment to the ICSGW data plane 307.

[0040] During the execution phase, a compute instance executing in a customer VCN (e.g., compute instance 315A) sends a request to use a service provided in a target cloud environment 331. Such a request is intercepted by the source ICSGW 309. In one implementation, the request includes an identity principal (e.g., a certificate or credential) associated with the compute instance. The source ICSGW extracts the identity principal from the request and performs a validation 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 request a service provided by the target cloud environment.

[0041] After successful authentication, the source ICSGW 309 obtains the access role that is preconfigured (i.e., in the establishment phase) for the computing instance. The source ICSGW 309 then modifies the request received from the computing instance and forwards the modified request to the target ICSGW 345 included in the target cloud environment. Note that the modified request is transmitted from the source cloud environment 301 to the target cloud environment via the trusted communication channel (e.g., communication channel 350) established in the establishment phase. In one implementation, the source ICSGW 309 modifies the request by stripping (i.e., removing) the identity principal from the request and merging 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.

[0042] After receiving the modified request sent by the source ICSGW 309, the target ICSGW 345 extracts the access role (associated with the computing instance) included in the modified request. In one embodiment, the target ICSGW 345 communicates with a management service (e.g., an identity management service 333A or a security token service 333B included in the target cloud environment 331) to obtain a credential (e.g., a token) associated with the access role of the computing instance. The target ICSGW 345 signs the modified request with the obtained credential and forwards the signed request to the service (e.g., service 333C) desired to be used by the computing instance. In one embodiment, the desired service can communicate with the management service (e.g., identity management service 333A) of the target cloud environment 331 to determine whether the credential used to sign the request has sufficient privileges to perform the requested action. After successful verification, the service is executed in the customer's lease included in the target cloud environment 331, that is, the request is executed in the customer B lease 335 (in the case that the customer has a lease in the target cloud environment), or the request is executed in the customer A resource group 341 (in the case that the customer does not have its own lease in the target cloud environment).

[0043] Figure 3B A flow diagram of a process performed by a source Inter-Cloud Services Gateway (ICSGW) is shown in accordance with certain embodiments. Figure 3B The processing shown in the can be implemented in software (e.g., code, instructions, programs), hardware, or a combination thereof, executed by one or more processing units (e.g., processors, cores) of the corresponding system. The software can be stored on a non-volatile storage medium (e.g., on a memory device). Figure 3B The methods presented in and described below are intended to be illustrative and non-limiting. Figure 3B Various processing steps occurring in a particular order or sequence are shown, but this is not intended to be limiting. In some alternative embodiments, these steps may be performed in a different order, or some steps may also be performed in parallel.

[0044] The process begins at step 361, where the source ICSGW receives a request from a computing instance executing in a source cloud environment. The request corresponds to a request by the computing instance to use a service provided by a target cloud environment. In one implementation, the request includes an identity principal (e.g., a certificate or credential) associated with the computing instance. In step 363, the source ICSGW extracts the identity principal from the request and performs a verification of the permissions associated with the computing instance. For example, the source ICSGW verifies whether a particular computing instance is permitted to issue a request requesting a service provided by the target cloud environment.

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

[0046] In step 366 (i.e., after determining a negative response to the query of step 365), the source ICSGW provides a response to the request sent by the computing instance. For example, the source ICSGW sends a response message to the computing instance indicating that the identity principal of the computing instance was not successfully verified, and therefore the requested service of the target cloud environment cannot be provided to the computing instance (i.e., service access failed). After sending the response message in step 366, Figure 3A The process in terminates.

[0047] After determining a positive response to the query of step 365, the process moves to step 376. In this step, the source ICSGW obtains the access role associated with the computing instance of the requested service from the pre-configuration information (e.g., information associated with the establishment phase). The access role indicates the privileges (e.g., read-write privileges, read-only privileges) associated with the computing instance in the target cloud environment.

[0048] The process then proceeds to step 369, where the source ICSGW modifies the request obtained from the computing instance to generate a modified request. In one implementation, the source ICSGW removes the identity principal associated with the computing instance from the request and includes the access role associated with the computing instance (obtained in step 367) in the request to generate the modified request. Thereafter, the source ICSGW sends the modified request to the target ICSGW. Figure 3A It will be appreciated that the modified request is transmitted from the source ICSGW to the target ICSGW via the trusted communication channel 350 established between the source cloud environment and the target cloud environment.

[0049] Figure 3C A flow chart illustrating a process performed by a target inter-cloud service gateway (ICSGW) according to certain embodiments. Figure 3C The processing shown in the can be implemented in software (e.g., code, instructions, programs), hardware, or a combination thereof, executed by one or more processing units (e.g., processors, cores) of the corresponding system. The software can be stored on a non-volatile storage medium (e.g., on a memory device). Figure 3CThe methods presented in and described below are intended to be illustrative and non-limiting. Figure 3C Various processing steps occurring in a particular order or sequence are shown, but this is not intended to be limiting. In some alternative embodiments, these steps may be performed in a different order, or some steps may also be performed in parallel.

[0050] The process begins at step 371, where the target ICSGW receives a modified request sent by the source ICSGW (i.e., Figure 3B In 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 (e.g., Figure 3B Specifically, the target ICSGW communicates with the management service to obtain the credentials (eg, token) associated with the access role of the computing instance.

[0051] In step 377, the target ICSGW signs the modified request using the credentials obtained in step 375 and forwards the signed request to the service desired to be used by the compute instance in step 379. The process then moves to step 381, where a query is performed to determine the validity of the credentials. For example, in one implementation, the desired service may communicate with a management service (e.g., an identity management service) of the target cloud environment to determine whether the credentials used to sign the request have sufficient privileges to perform the requested action. If the response to the query in step 381 is affirmative (i.e., the credentials have sufficient privileges to perform the action), the process moves to step 383. However, if the response to the query in step 381 is negative, the process moves to step 385.

[0052] In step 385, the service responds with a message indicating that access to the requested action (e.g., read, write, update) to be performed by the service has failed. In other words, the service notifies the target ICSGW that the requested action cannot be performed due to insufficient privileges. In some implementations, the target ICSGW can forward the obtained response to the computing instance deployed in the source cloud environment via a trusted communication channel. However, in response to the successful verification of the credentials in step 381, the process in step 383 continues to execute the request for the desired service. Thereafter, Figure 3B The process shown in terminates.

[0053] Now go to Figure 4A and Figure 4B , according to some embodiments, illustrates an exemplary process for a computing instance executing in a source cloud environment to utilize services provided in a target cloud environment. Figure 4A, shows a source cloud environment 401 and a target cloud environment 451. The source cloud environment 401 includes a customer virtual cloud network (i.e., customer VCN 403) hosting two applications (i.e., application 1 405A and application 2 405B). In addition, the source cloud environment 401 includes a source ICSGW 407 communicatively coupled to a target ICSGW 459 included in the target cloud environment 451.

[0054] The target cloud environment 451 includes a target cloud service 461, a customer lease or account 463, and other target cloud services 453. Other target cloud services 453 may include additional services, such as identity management services 453A, security token services 453B, and the like. For illustration, the target cloud services 461 in the target cloud environment 451 that are expected to be used by computing instances (i.e., application 1 405A and application 2 405B in the source cloud environment 401) are shown as S3 services and SQS services. 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 the file. A bucket is a container for an object. SQS (i.e., Simple Queue Service) is a managed message queue service that is used to asynchronously send, store, and retrieve multiple messages of various sizes.

[0055] According to some embodiments, a dynamic group is created in the source cloud environment during the setup phase. The dynamic group provides for grouping computing instances as primary participants in a manner similar to grouping users into user groups. Policies that allow computing instances within the dynamic group to issue API calls to obtain services can be created during the setup phase. It is understood that membership in a 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, Figure 4A As shown in FIG. 4 , application 1 405A is included in a first dynamic group (DG1), while application 2 405B is included in a second dynamic group (DG2).

[0056] Furthermore, during the establishment phase, each dynamic group may be assigned a role (also referred to herein as an access role) corresponding to a set of privileges that members of the dynamic group may enjoy in the target cloud environment. Figure 4A As shown in FIG, application 1 405A belonging to dynamic group 1 (DG1) is assigned a first role (labeled as IAM-role1), and application 2 405B belonging to dynamic group 2 (DG2) is assigned a second role (labeled as IAM-role2). For simplicity, the privileges associated with the first role correspond to read and write privileges, while the privileges associated with the second role correspond to read-only privileges. A dynamic group set constructed in this manner is shown in FIG. Figure 4A It is shown in the dashed box 409. Figure 4AAs shown in , it should be understood that during the establishment phase, roles assigned to different dynamic groups are also instantiated in customer account 463 in the target cloud environment. Specifically, during the establishment phase, the customer specifies whether the customer has a customer tenancy in the target cloud environment. In the event that the customer has a customer tenancy in the target cloud environment (e.g., customer account 463 in target cloud environment 451), information specifying the target cloud environment, the customer tenancy in the target cloud environment, different roles assigned to dynamic groups of the customer VCN, etc. is specified during the establishment phase.

[0057] In addition, according to some embodiments, the computing instances in each dynamic group can be programmed to send requests for services provided in the target cloud environment to the endpoints associated with the dynamic group. The endpoint forwards the request to the source ICSGW, which further forwards the request to the target ICSGW via a secure communication channel. For example, Figure 4A As shown in FIG, application 1 405A included in DG1 forwards requests issued by the application (ie, requests for services provided in the target cloud environment) to ICSGW 1 endpoint 406A, while application 2 405B included in DG2 forwards requests issued by the application to ICSGW 2 endpoint 406B.

[0058] In the following, reference Figure 4A , describing in detail the processes related to four different requests (for services provided by the target cloud environment) issued by the computing instances included in the customer VCN 403. Specifically, process 1 (with steps labeled 1.1 to 1.5) corresponds to the scenario where application 1 405A issues a request to access an S3 bucket in the target cloud environment to upload a file. Process 2 (with steps labeled 2.1 to 2.5) corresponds to the scenario where application 1 405A issues a request to call an SQS service to send a message. Process 3 (with steps labeled 3.1 to 3.5) corresponds to the scenario where application 2 405B polls the SQS queue to determine the existence of a message, and process 4 (with steps labeled 4.1 to 4.5) corresponds to the scenario where application 2 405B issues a request to read a file.

[0059] Referring to Flow 1, in step 1.1, application 1 405A issues a request to upload a file. The request is forwarded to source ICSGW 407 via ICSGW 1 endpoint 406A. Source ICSGW 407 terminates the request and performs a validation check to determine whether the identity subject associated with application 1 405A is permitted to make such a request. After successful validation, source ICSGW 407 modifies the request to include an access role (e.g., IAM role 1) associated with application 1 405A in the request. In step 1.2, source ICSGW 407 forwards the modified request to target ICSGW 459. Note that the modified request is forwarded over a secure communication channel (e.g., quick connect) 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. The target ICSGW 459 communicates with a management service (e.g., a security token service 453B included in the target cloud service 453) to obtain the credentials associated with the access role. In step 1.4, the target ICSGW 459 signs the modified request with the obtained credentials (step 1.3) and forwards the signed request to the service (e.g., service 461 intended to be used by application 1 405A). In step 1.5, the target service 461 may perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., upload the file). In addition, since application 1 405A is associated with an access role with read and write privileges, in step 1.5, the file is uploaded to the S3 bucket in customer tenancy 463.

[0060] Referring now to process 2, in step 2.1, application 1 405A issues a request to call the SQS service in the target cloud environment to send a message (e.g., to an SQS queue). The request is forwarded to the source ICSGW 407 via the ICSGW 1 endpoint 406A. The source ICSGW 407 terminates the request and performs a validation check to determine whether the identity principal associated with application 1 405A is permitted to make such a request. After successful validation, the source ICSGW 407 modifies the request to include an access role (e.g., IAM role 1) associated with application 1 405A in the request. In step 2.2, the source ICSGW 407 forwards 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 a management service (e.g., a security token service 453B included in the target cloud service 453) to obtain credentials associated with the access role. In step 2.4, the target ICSGW 459 signs the modified request with the obtained credentials (step 1.3) and forwards the signed request to the service (e.g., the SQS service 461 intended for use by application 1 405A). In step 2.5, the target service 461 may perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., send a message on the SQS queue). Furthermore, since application 1 405A is associated with an access role with read and write privileges, in step 2.5, the message is added to the SQS queue in the customer lease 463.

[0061] Now refer to process 3, which corresponds to the scenario where application 2 405B polls the SQS queue to determine the existence of a message (i.e., reads a message from the SQS queue). In step 3.1, application 2 405B issues a request to obtain a message from the SQS queue. The request is forwarded to the source ICSGW 407 via ICSGW 2 endpoint 406B. The source ICSGW 407 terminates the request and performs a validation check as described above. After successful validation, the source ICSGW 407 modifies the request to include an access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 3.2, the source ICSGW 407 forwards 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 (step 3.3) and forwards the signed request to the service (e.g., the SQS service 461 intended for use by application 2 405B). In step 3.5, the target service 461 may perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., get the message from the SQS queue). Furthermore, since application 2 405B is associated with an access role with read privileges, in step 3.5, the message is obtained from the SQS queue in the customer lease 463.

[0062] Now refer to process 4, which corresponds to the scenario where application 2 405B invokes a call to the S3 service to obtain an object from the S3 bucket. In step 4.1, application 2 405B issues a request to obtain an object from the S3 bucket. The request is forwarded to the source ICSGW 407 via the ICSGW 2 endpoint 406B. The source ICSGW 407 terminates the request and performs a validation check as described above. After successful validation, the source ICSGW 407 modifies the request to include an access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 4.2, the source ICSGW 407 forwards 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 (step 4.3) and forwards the signed request to the service (e.g., the S3 service 461 intended for use by application 2 405B). In step 4.5, the target service 461 may perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., obtain the object from the S3 bucket). Furthermore, since application 2 405B is associated with an access role with read privileges, in step 4.5, the object is obtained from the S3 bucket in the customer lease 463.

[0063] Reference now Figure 4B , describing in detail the processes related to four different requests (for services provided by the target cloud environment) issued by the computing instances included in the customer VCN 403. Specifically, process 5 (with steps labeled 5.1 to 5.4) corresponds to the scenario where application 2 405B issues a request to upload a file in an S3 bucket. Process 6 (with steps labeled 6.1 to 6.4) corresponds to the scenario where application 2 405B issues a request to delete a message from an SQS queue. Process 7 (with steps labeled 7.1 to 7.5) corresponds to the scenario where application 1 405A issues a request to delete a message from an SQS queue, and process 8 (with steps labeled 8.1 to 8.5) corresponds to the scenario where application 1 405A issues a request to delete a file from an S3 bucket.

[0064] Now refer to process 5, which corresponds to the scenario where application 2 405B issues a request to upload a file in an S3 bucket. In step 5.1, application 2 405B issues a request to upload a file in an S3 bucket. The request is forwarded to source ICSGW 407 via ICSGW 2 endpoint 406B. Source ICSGW 407 terminates the request and performs a validation check as described above. After successful validation, source ICSGW 407 modifies the request to include an access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 5.2, source ICSGW 407 forwards the modified request to target ICSGW 459. In step 5.3, target ICSGW 459 extracts the corresponding access role from the modified request received from source ICSGW 407. 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 (step 5.3) and forwards the signed request to the service (e.g., S3 service 461 intended for use by application 2 405B). The target service 461 performs a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., upload the file to the S3 bucket). Since application 2 405B is associated with an access role with read-only privileges, the S3 service in the target cloud environment denies the request to upload the file in the S3 bucket (step 5.4). Therefore, the service 461 in customer account 463 does not execute the request.

[0065] Now refer to process 6, which corresponds to the scenario where application 2 405B issues a request to delete a message from an SQS queue. In step 6.1, application 2 405B issues a request to delete a message from an SQS queue. The request is forwarded to source ICSGW 407 via ICSGW 2 endpoint 406B. Source ICSGW 407 terminates the request and performs a validation check as described above. After successful validation, source ICSGW 407 modifies the request to include an access role (e.g., IAM role 2) associated with application 2 405B in the request. In step 6.2, source ICSGW 407 forwards the modified request to target ICSGW 459. In step 6.3, target ICSGW 459 extracts the corresponding access role from the modified request received from source ICSGW 407. 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 credentials obtained (of step 6.3) and forwards the signed request to the service (e.g., the SQS service 461 intended for use by application 2 405B). The target service 461 performs a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., delete the message from the SQS queue). Since application 2 405B is associated with an access role with read-only privileges, the SQS service in the target cloud environment denies the request to delete the message (step 6.4). Therefore, service 461 in customer account 463 does not execute the request.

[0066] Turning now to process 7, in step 7.1, application 1 405A issues a request to delete a message from an SQS queue. The request is forwarded to source ICSGW 407 via ICSGW 1 endpoint 406A. Source ICSGW 407 terminates the request and performs a validation check to determine whether the identity principal associated with application 1 405A is permitted to make such a request. After successful validation, source ICSGW 407 modifies the request to include an access role (e.g., IAM role 1) associated with application 1 405A in the request. In step 7.2, source ICSGW 407 forwards the modified request to target ICSGW 459. In step 7.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 of the target cloud environment (e.g., a security token service 453B included in target cloud service 453) to obtain credentials associated with the access role. In step 7.4, the target ICSGW 459 signs the modified request with the credentials obtained (of step 7.3) and forwards the signed request to the service (e.g., the SQS service 461 intended for use by application 1 405A). In step 7.5, the target service 461 may perform a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., delete the message). Furthermore, since application 1 405A is associated with an access role with read and write privileges, in step 7.5, the message is deleted from the SQS queue in the customer lease 463.

[0067] Flow 8 (with steps labeled 8.1 to 8.5) corresponds to a scenario where application 1 405A issues a request to delete a file from an S3 bucket. In step 8.1, application 1 405A issues a request to delete a file from an S3 bucket. The request is forwarded to source ICSGW 407 via ICSGW 1 endpoint 406A. Source ICSGW 407 terminates the request and performs a validation check to determine whether the identity principal associated with application 1 405A is permitted to make such a request. After successful validation, source ICSGW 407 modifies the request to include an access role (e.g., IAM role 1) associated with application 1 405A in the request. In step 8.2, source ICSGW 407 forwards the modified request to target ICSGW 459. In step 8.3, target ICSGW 459 extracts the corresponding access role from the modified request received from source ICSGW 407. The target ICSGW 459 communicates with the management service of the target cloud environment (e.g., the security 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 (of step 8.3) and forwards the signed request to the service (e.g., the S3 service 461 intended to be used by application 1 405A). In step 8.5, the target service 461 performs a check to determine whether the credentials (obtained from the target ICSGW 459) are associated with sufficient privileges to perform the requested action (i.e., delete the file from the S3 bucket). In addition, since application 1 405A is associated with an access role with read and write privileges, in step 8.5, the message is deleted from the S3 bucket in the customer lease 463.

[0068] Notice, Figure 4A and Figure 4B The exemplary scenario depicted in corresponds to a situation where a customer has a tenancy, i.e., a customer account in the target cloud environment (e.g., Figure 3A In this case, the ICSGW service account 337 is configured to manage services (in the target cloud environment) on behalf of the computing instances executing in the source cloud environment. It will be appreciated that a similar set of scenarios can be implemented for the case where the customer does not have a lease in the target cloud environment. In this case, the ICSGW control plane ( Figure 3A 305 ) may be configured to set a customer resource group (eg, customer A resource group 341 ) within the ICSGW service account 337 of the target cloud environment.

[0069] Sample cloud infrastructure

[0070] Figure 55 is a block diagram 500 illustrating an example schema of an IaaS architecture according to at least one embodiment. A service operator 502 can be communicatively coupled to a secure host lease 504, which can include a virtual cloud network (VCN) 506 and a secure host subnet 508. In some examples, the service operator 502 can use one or more client computing devices, which can be portable handheld devices (e.g., Cellular phone, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head mounted display), running software such as Microsoft Windows software, and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc., and supports Internet, email, short message service (SMS), Alternatively, the client computing device may be a general-purpose personal computer, such as a computer running various versions of Microsoft Apple The client computing device may be a personal computer and / or laptop computer running a variety of commercially available or any workstation computer running any operating system in the UNIX or UNIX-like operating system, including but not limited to varieties of the GNU / Linux operating system, such as Google Chrome OS. Alternatively or in addition, the client computing device may be any other electronic device capable of communicating over a network that can access the VCN 506 and / or the Internet, such as a thin client computer, an Internet-enabled gaming system (e.g., with or without a VCN 506 or a server), or a computer that can communicate with the client via a network that can access the VCN 506 and / or the Internet. A gesture input device such as a Microsoft Xbox game console) and / or a personal messaging device.

[0071] VCN 506 may include a local peer gateway (LPG) 510, which may be communicatively coupled to a secure shell (SSH) VCN 512 via the LPG 510 contained in an SSH VCN 512. SSH VCN 512 may include an SSH subnet 514, and SSH VCN 512 may be communicatively coupled to a control plane VCN 516 via the LPG 510 contained in a control plane VCN 516. In addition, SSH VCN 512 may be communicatively coupled to a data plane VCN 518 via the LPG 510. Control plane VCN 516 and data plane VCN 518 may be contained in a service lease 519, which may be owned and / or operated by an IaaS provider.

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

[0073] The control plane VCN 516 may include a data plane image app layer 540 that may include app subnet(s) 526. The app subnet(s) 526 included in the data plane image app layer 540 may include a virtual network interface controller (VNIC) 542 that may execute compute instances 544. The compute instances 544 may communicatively couple the app subnet(s) 526 of the data plane image app layer 540 to the app subnet(s) 526 that may be included in the data plane app layer 546.

[0074] The data plane VCN 518 may include a data plane app layer 546, a data plane DMZ layer 548, and a data plane data layer 550. The data plane DMZ layer 548 may include a LB subnet(s) 522 communicatively coupled to the app subnet(s) 526 of the data plane app layer 546 and the internet gateway 534 of the data plane VCN 518. The app subnet(s) 526 may 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 may also include a DB subnet(s) 530 communicatively coupled to the app subnet(s) 526 of the data plane app layer 546.

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

[0076] In some examples, service gateway 536 of control plane VCN 516 or data plane VCN 518 can make application programming interface (API) calls to cloud services 556 without going through public internet 554. API calls from service gateway 536 to cloud services 556 can be one-way: service gateway 536 can make API calls to cloud services 556, and cloud services 556 can send requested data to service gateway 536. However, cloud services 556 may not initiate API calls to service gateway 536.

[0077] In some examples, secure host lease 504 can be directly connected to service lease 519, which can be otherwise isolated. Secure host subnet 508 can communicate with SSH subnet 514 through LPG 510, which can support two-way communication on otherwise isolated systems. Connecting secure host subnet 508 to SSH subnet 514 can give secure host subnet 508 access to other entities within service lease 519.

[0078] The control plane VCN 516 may allow users of the service lease 519 to establish or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 516 may be deployed or otherwise used in the data plane VCN 518. In some examples, the control plane VCN 516 may be isolated from the data plane VCN 518, and the data plane image app layer 540 of the control plane VCN 516 may communicate with the data plane app layer 546 of the data plane VCN 518 via a VNIC 542 that may be included in the data plane image app layer 540 and the data plane app layer 546.

[0079] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, over the public internet 554, which may transmit the request to the metadata management service 552. The metadata management service 552 may transmit the request to the control plane VCN 516 over the internet gateway 534. The request may be received by the LB subnet(s) 522 contained in the control plane DMZ layer 520. The LB subnet(s) 522 may determine that the request is valid, and in response to the determination, the LB subnet(s) 522 may send the request to the app subnet(s) 526 contained in the control plane app layer 524. If the request is validated and a call to the public internet 554 is required, the call to the public internet 554 may be sent to the NAT gateway 538, which may make the call to the public internet 554. The storage that the request may desire to be stored may be stored in the DB subnet(s) 530.

[0080] In some examples, data plane image app layer 540 may facilitate direct communication between control plane VCN 516 and data plane VCN 518. For example, it may be desirable to apply changes, updates, or other appropriate modifications to a configuration to resources contained in data plane VCN 518. Control plane VCN 516 may communicate directly with resources contained in data plane VCN 518 via VNIC 542, and may thereby perform changes, updates, or other appropriate modifications to a configuration to resources contained in data plane VCN 518.

[0081] In some embodiments, control plane VCN 516 and data plane VCN 518 may be included in service lease 519. In this case, a user or customer of the system may not own or operate control plane VCN 516 or data plane VCN 518. Instead, an IaaS provider may own or operate control plane VCN 516 and data plane VCN 518, both of which may be included in service lease 519. This embodiment may implement network isolation, which may prevent a user or customer from interacting with the resources of other users or other customers. In addition, this embodiment may allow a user or customer of the system to store a database privately without relying on the public Internet 654, which may not have the desired level of security, for storage.

[0082] In other embodiments, the LB subnet(s) 522 contained 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 called by customers of the IaaS provider without calling the public Internet 554. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on the service lease 519, which can be isolated from the public Internet 554.

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

[0084] The control plane VCN 616 may include LB subnet(s) 622 (e.g., Figure 5 The control plane DMZ layer 620 (e.g., Figure 5 control plane DMZ layer 520), may include (multiple) app subnets 626 (e.g., Figure 5 (e.g., Figure 5 control plane app layer 524), may include (multiple) database (DB) subnets 630 (e.g., similar to Figure 5 The control plane data layer 628 (e.g., Figure 5 LB subnet(s) 622 included in the control plane DMZ layer 620 may be communicatively coupled to app subnet(s) 626 included in the control plane app layer 624 and an internet gateway 634 (e.g., Figure 5 534), and the app subnet(s) 626 can be communicatively coupled to the DB subnet(s) 630 and the service gateway 636 (e.g., Figure 5 Serving gateway) and network address translation (NAT) gateway 638 (e.g. Figure 5 The control plane VCN 616 may include a service gateway 636 and a NAT gateway 638.

[0085] The control plane VCN 616 may include a data plane mirror app layer 640 (e.g., Figure 5 The data plane image app layer 540 of the data plane image app layer 640 may include (multiple) app subnets 626. The (multiple) app subnets 626 included in the data plane image app layer 640 may include executable computing instances 644 (e.g., similar to Figure 5 The compute instance 644 can facilitate the app subnet(s) 626 of the data plane mirror app layer 640 and the app subnets 626 that can be included in the data plane app layer 646 (e.g., Figure 5 Communication between (multiple) app subnets 626 in the data plane app layer 546) 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.

[0086] The Internet gateway 634 included in the control plane VCN 616 can be communicatively coupled to the metadata management service 652 (e.g., Figure 5 The metadata management service 552 may be communicatively coupled to a public Internet 654 (e.g., Figure 5 The public Internet 654 may 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 may be communicatively coupled to a cloud service 656 (e.g., Figure 5 Cloud service 556).

[0087] In some examples, the data plane VCN 618 may be included in the customer lease 621. In this case, the IaaS provider may provide a control plane VCN 616 for each customer, and the IaaS provider may establish a unique compute instance 644 included in the service lease 619 for each customer. Each compute instance 644 may allow communication between the control plane VCN 616 included in the service lease 619 and the data plane VCN 618 included in the customer lease 621. The compute instance 644 may allow resources provisioned in the control plane VCN 616 included in the service lease 619 to be deployed or otherwise used in the data plane VCN 618 included in the customer lease 621.

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

[0089] In some embodiments, a customer of an IaaS provider may apply filters to data plane VCN 618. In this embodiment, the customer may determine what data plane VCN 618 may access, and the customer may restrict access to the public Internet 654 from data plane VCN 618. The IaaS provider may not apply filters or otherwise control access to any external network or database by data plane VCN 618. Applying filters and controls by the customer to data plane VCN 618 contained in a customer lease 621 may help isolate data plane VCN 618 from other customers and the public Internet 654.

[0090] In some embodiments, cloud services 656 may be called by service gateway 636 to access services that may not exist on public Internet 654, control plane VCN 616, or data plane VCN 618. The connection between cloud services 656 and control plane VCN 616 or data plane VCN 618 may not be real-time or continuous. Cloud services 656 may exist on different networks owned or operated by IaaS providers. Cloud services 656 may be configured to receive calls from service gateway 636 and may be configured not to receive calls from public Internet 654. Some cloud services 656 may be isolated from other cloud services 656, and control plane VCN 616 may be isolated from cloud services 656 that may not be in the same region as control plane VCN 616. For example, control plane VCN 616 may be located in "Region 1", while cloud service "Deployment 6" may be located in Region 1 and "Region 2". If a service gateway 636 contained in a control plane VCN 616 located in region 1 makes a call to deployment 6, the call may be transmitted to deployment 6 in region 1. In this example, control plane VCN 616 or deployment 6 in region 1 may be communicatively coupled to or otherwise in communication with deployment 6 in region 2.

[0091] Figure 7 7 is a block diagram 700 illustrating another example mode of an IaaS architecture according to at least one embodiment. A service operator 702 (e.g., Figure 5 The service operator 502 may be communicatively coupled to the secure host lease 704 (e.g., Figure 5 The secure host lease 704 may include a virtual cloud network (VCN) 706 (e.g., Figure 5 VCN 506) and secure host subnet 708 (e.g., Figure 5 VCN 706 may include LPG 710 (e.g., Figure 5 510), which may be communicatively coupled to the SSH VCN 712 via the LPG 710 contained in the SSH VCN 712 (e.g., Figure 5 SSH VCN 512). SSH VCN 712 may include SSH subnet 714 (e.g., Figure 5 SSH subnet 514), and SSHVCN 712 may be communicatively coupled to control plane VCN 716 via LPG 710 included in control plane VCN 716 (e.g., Figure 5 The control plane VCN 516 of the data plane VCN 718 may be communicatively coupled to the data plane VCN 718 via the LPG 710 included in the data plane VCN 718 (e.g., Figure 5 The control plane VCN 716 and the data plane VCN 718 may be included in a service lease 719 (e.g., Figure 5 Service lease 519).

[0092] The control plane VCN 716 may include a load balancer (LB) subnet 722 (e.g., Figure 5 The control plane DMZ layer 720 (e.g., Figure 5 control plane DMZ layer 520), may include (multiple) app subnets 726 (e.g., similar to Figure 5 (e.g., Figure 5 A control plane app layer 524), a control plane data layer 728 (e.g., Figure 5 The LB subnet(s) 722 included in the control plane DMZ layer 720 may be communicatively coupled to the app subnet(s) 726 included in the control plane app layer 724 and the internet gateway 734 (e.g., Figure 5 534), and the app subnet(s) 726 may be communicatively coupled to the DB subnet(s) 730 and the service gateway 736 (e.g., Figure 5 ) and a network address translation (NAT) gateway 738 (e.g., Figure 5 The control plane VCN 716 may include a service gateway 736 and a NAT gateway 738.

[0093] The data plane VCN 718 may include a data plane app layer 746 (e.g., Figure 5 Data plane app layer 546), data plane DMZ layer 748 (e.g., Figure 5 Data plane DMZ layer 548) and data plane data layer 750 (e.g., Figure 5The data plane DMZ layer 748 may include (multiple) trusted app subnets 760 and (multiple) untrusted app subnets 762 communicatively coupled to the data plane app layer 746 and (multiple) LB subnets 722 of the internet gateway 734 included in the data plane VCN 718. The (multiple) trusted app subnets 760 may be communicatively coupled to the service gateway 736 included in the data plane VCN 718, the NAT gateway 738 included in the data plane VCN 718, and the (multiple) DB subnets 730 included in the data plane data layer 750. The (multiple) untrusted app subnets 762 may be communicatively coupled to the data plane VCN 718 included in the data plane data layer 750 and the service gateway 736 included in the (multiple) DB subnets 730. The data plane data layer 750 may include (multiple) DB subnets 730 communicatively coupled to the service gateway 736 included in the data plane VCN 718.

[0094] Untrusted app subnet(s) 762 may include one or more primary VNICs 764(1)-(N) communicatively coupled to tenant virtual machines (VMs) 766(1)-(N). Each tenant VM 766(1)-(N) may be communicatively coupled to a respective app subnet 767(1)-(N) that may be contained in a respective container egress VCN 768(1)-(N), which may be contained in a respective customer tenancy 770(1)-(N). Respective secondary VNICs 772(1)-(N) may facilitate communications between untrusted app subnet(s) 762 contained in data plane VCN 718 and app subnets contained in container egress VCNs 768(1)-(N). Each container egress VCN 768(1)-(N) may include a NAT gateway 738 that may be communicatively coupled to the public Internet 754 (e.g., Figure 5 of the public Internet 554).

[0095] An internet gateway 734 included in control plane VCN 716 and included in data plane VCN 718 may be communicatively coupled to a metadata management service 752 (e.g., Figure 5 The metadata management service 752 may be communicatively coupled to the public Internet 754. The public Internet 754 may be communicatively coupled to the NAT gateway 738 included in the control plane VCN 716 and included in the data plane VCN 718. The service gateway 736 included in the control plane VCN 716 and included in the data plane VCN 718 may be communicatively coupled to the cloud service 756.

[0096] In some embodiments, data plane VCN 718 can be integrated with customer lease 770. In some cases, such integration may be useful or desirable for customers of the IaaS provider, such as where support may be required when executing code. A customer may provide code to be run that may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code provided by the customer to the IaaS provider.

[0097] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request that a function be attached to the data plane app layer 746. Code running the function may be executed in a VM 766(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 718. Each VM 766(1)-(N) may be connected to one customer tenancy 770. Individual containers 771(1)-(N) contained in a VM 766(1)-(N) may be configured to run code. In this case, there may be double isolation (e.g., containers 771(1)-(N) running code, where containers 771(1)-(N) may be contained in at least a VM 766(1)-(N) contained in an untrusted app subnet(s) 762), which may help prevent incorrect or otherwise undesirable code from compromising the IaaS provider's network or compromising a different customer's network. Containers 771(1)-(N) may be communicatively coupled to customer lease 770 and may be configured to send data to or receive data from customer lease 770. Containers 771(1)-(N) may not be configured to send data to or receive data from any other entity in data plane VCN 718. After finishing running code, the IaaS provider may kill or otherwise dispose of containers 771(1)-(N).

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

[0099] In other embodiments, the control plane VCN 716 and the data plane VCN 718 may not be coupled in direct communication. In this embodiment, there may be no direct communication between the control plane VCN 716 and the data plane VCN 718. However, the communication may be indirect through at least one method. The LPG 710 may be established by an IaaS provider, which may 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 may make a call to the cloud service 756 via the service gateway 736. For example, the call from the control plane VCN 716 to the cloud service 756 may include a request for a service that may communicate with the data plane VCN 718.

[0100] Figure 8 8 is a block diagram 800 illustrating another example mode of an IaaS architecture according to at least one embodiment. A service operator 802 (e.g., Figure 5 The service operator 502 may be communicatively coupled to the secure host lease 804 (e.g., Figure 5 The secure host lease 804 may include a virtual cloud network (VCN) 806 (e.g., Figure 5 VCN 506) and secure host subnet 808 (e.g., Figure 5 VCN 806 may include LPG 810 (e.g., Figure 5 510), which may be communicatively coupled to the SSH VCN 812 via the LPG 810 contained in the SSH VCN 812 (e.g., Figure 5 SSH VCN 812 may include SSH subnet 814 (e.g., Figure 5 SSH subnet 514), and SSHVCN 812 may be communicatively coupled to control plane VCN 816 via LPG 810 included in control plane VCN 816 (e.g., Figure 5 The control plane VCN 516 of the embodiment of the present invention may be communicatively coupled to the data plane VCN 818 via the LPG 810 contained in the data plane VCN 818 (e.g., Figure 5 The control plane VCN 816 and the data plane VCN 818 may be included in a service lease 819 (e.g., Figure 5 Service leasing 519).

[0101] The control plane VCN 816 may include LB subnet(s) 822 (e.g., Figure 5The control plane DMZ layer 820 (e.g., Figure 5 control plane DMZ layer 520), may include (multiple) app subnets 826 (e.g., Figure 5 (e.g., Figure 5 control plane app layer 524), may include (multiple) DB subnets 830 (e.g., Figure 7 The control plane data layer 828 (e.g., Figure 5 The LB subnet(s) 822 included in the control plane DMZ layer 820 may be communicatively coupled to the app subnet(s) 826 included in the control plane application layer 824 and the internet gateway 834 (e.g., Figure 5 824 ), and the app subnet(s) 826 may be communicatively coupled to the DB subnet(s) 830 and the service gateway 836 (e.g., Figure 5 ) and a network address translation (NAT) gateway 838 (e.g., Figure 5 The control plane VCN 816 may include a service gateway 836 and a NAT gateway 838.

[0102] The data plane VCN 818 may include a data plane app layer 846 (e.g., Figure 5 Data plane app layer 546), data plane DMZ layer 848 (e.g., Figure 5 Data plane DMZ layer 548) and data plane data layer 850 (e.g., Figure 5 The data plane DMZ layer 848 may include (a plurality of) trusted app subnets 860 (e.g., Figure 7 (multiple) trusted app subnets 760) and (multiple) untrusted app subnets 862 (e.g., Figure 7The trusted app subnet(s) 860 may be communicatively coupled to the service gateway 836 contained in the data plane VCN 818, the NAT gateway 838 contained in the data plane VCN 818, and the DB subnet(s) 830 contained in the data plane data layer 850. The untrusted app subnet(s) 862 may be communicatively coupled to the service gateway 836 contained in the data plane VCN 818 and the DB subnet(s) 830 contained in the data plane data layer 850. The data plane data layer 850 may include the DB subnet(s) 830 communicatively coupled to the service gateway 836 contained in the data plane VCN 818.

[0103] The untrusted app subnet(s) 862 may include primary VNICs 864(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 866(1)-(N) residing within the untrusted app subnet(s) 862. Each tenant VM 866(1)-(N) may run code in a respective container 867(1)-(N) and may be communicatively coupled to the app subnet 826 in the data plane app layer 846 that may be included in the container egress VCN 868. Respective secondary VNICs 872(1)-(N) may facilitate communications between the untrusted app subnet(s) 862 included in the data plane VCN 818 and the app subnets included in the container egress VCN 868. The container egress VCN may include a NAT gateway 838 that may be communicatively coupled to the public Internet 854 (e.g., Figure 5 of the public Internet 554).

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

[0105] In some examples, Figure 8 The architecture of block diagram 800 may be considered as Figure 6600 , and may be desired by customers of an IaaS provider if the IaaS provider cannot communicate directly with the customer (e.g., a disconnected region). Customers may have real-time access to individual containers 867(1)-(N) contained in each customer's VM 866(1)-(N). Containers 867(1)-(N) may be configured to call individual secondary VNICs 872(1)-(N) contained in app subnet(s) 826 of a data plane app layer 846 that may be contained in a container egress VCN 868. Secondary VNICs 872(1)-(N) may send calls to a NAT gateway 838, which may send calls to the public Internet 854. In this example, containers 867(1)-(N) that may be accessed by customers in real-time may be isolated from control plane VCN 816 and may be isolated from other entities contained in data plane VCN 818. Containers 867(1)-(N) may also be isolated from resources from other customers.

[0106] In other examples, a customer can use containers 867(1)-(N) to call cloud service 856. In this example, a customer can run code in container 867(1)-(N) that requests a service from cloud service 856. Container 867(1)-(N) can send the request to secondary VNIC 872(1)-(N), which can send the request to a NAT gateway, which can send the request to the public Internet 854. The public Internet 854 can send the request to LB subnet(s) 822 included in control plane VCN 816 via Internet gateway 834. In response to determining that the request is valid, LB subnet(s) can send the request to app subnet(s) 826, which can send the request to cloud service 856 via service gateway 836.

[0107] It should be understood that the IaaS architectures 500, 600, 700, 800 shown in the figures may have other components than those shown. In addition, the embodiments shown in the figures are only some examples of cloud infrastructure systems that can be combined with embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have a different configuration or arrangement of components.

[0108] In certain embodiments, the IaaS system described herein may include a set of application, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI) provided by the present assignee.

[0109] Fig. 9 An example computer system 900 is shown in which various embodiments may be implemented. System 900 may be used to implement any of the computer systems described above. As shown, computer system 900 includes a processing unit 904 that communicates with a plurality of peripheral subsystems via a bus subsystem 902. These peripheral subsystems may 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 a system memory 910.

[0110] The bus subsystem 902 provides a mechanism for allowing the various components and subsystems of the computer system 900 to communicate with each other as expected. Although the bus subsystem 902 is schematically shown as a single bus, the optional embodiment of the bus subsystem can utilize multiple buses. The bus subsystem 902 can be any of several types of bus structures, including a memory bus or a memory controller, a peripheral device bus, and a local bus using any of various bus architectures. For example, such an architecture can include an industrial standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus, which can be implemented as a mezzanine bus manufactured according to the IEEE P1386.1 standard.

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

[0112] In various embodiments, the processing unit 904 can execute various programs in response to program code, and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed can reside in (multiple) processors 904 and / or in the storage subsystem 918. Through appropriate programming, (multiple) processors 904 can provide the various functions described above. The computer system 900 can also include a processing acceleration unit 906, which can include a digital signal processor (DSP), a special processor, etc.

[0113] I / O subsystem 908 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as a mouse or trackball, touch pads or touch screens integrated into a display, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices such as Microsoft Motion sensors enable users to control input devices through a natural user interface using gestures and verbal commands and are compatible with Microsoft 360 game controller input device interaction. User interface input devices can also include such as Google Eye gesture recognition devices such as blink detectors detect eye activity from the user (e.g., blinking when taking a photo and / or making a menu selection) and convert eye gestures into input devices (e.g., Google ). In addition, the user interface input device may include a device that enables a user to communicate with a speech recognition system (e.g., Navigator) interactive voice recognition sensing device.

[0114] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, a joystick or pointing stick, a game controller, and a graphics tablet, as well as audio / video devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser rangefinders, and eye gaze tracking devices. In addition, the user interface input device may include, for example, medical imaging input devices such as computed tomography, magnetic resonance imaging, position emission tomography, and medical ultrasound imaging devices. The user interface input device may also include, for example, an audio input device such as a MIDI keyboard, a digital musical instrument, etc.

[0115] The user interface output device may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, 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 a user or other computer. For example, the user interface output device may include, but is not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0116] Computer system 900 may include storage subsystem 918, which includes software elements shown as currently located within system memory 910. System memory 910 may store program instructions that are loadable and executable on processing unit 904, as well as data generated during execution of these programs.

[0117] Depending on the configuration and type of computer system 900, system memory 910 may be volatile (e.g., random access memory (RAM)) and / or non-volatile (e.g., read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated and executed by processing unit 904. In some implementations, system memory 910 may include a variety of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), which contains basic routines such as those that help transfer information between elements within computer system 900 during startup, may typically be stored in ROM. By way of example and not limitation, system memory 910 also illustrates application programs 912, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 914, and an operating system 916. By way of example, operating system 916 may include various versions of Microsoft Apple and / or Linux operating system, various commercially available or Unix-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or mobile operating systems such as iOS, Phone, OS, 10OS and OS operating system.

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

[0119] The storage subsystem 900 may also include a computer-readable storage media reader 920, which may also be connected to computer-readable storage media 922. The computer-readable storage media 922, together and optionally in conjunction with the system memory 910, may comprehensively represent remote, local, fixed and / or removable storage devices and storage media for temporarily and / or more permanently containing, storing, transferring, and retrieving computer-readable information.

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

[0121] As examples, computer-readable storage media 922 may include hard disk drives that read and write to non-removable, nonvolatile magnetic media, magnetic disk drives that read and write to removable, nonvolatile magnetic disks, and removable, nonvolatile optical disks (such as CD ROMs, DVDs, and Computer readable storage media 922 may include, but is not limited to, The computer readable storage medium 922 may include a solid-state drive (SSD) based on non-volatile memory, such as a flash memory-based SSD, an enterprise flash drive, a solid-state ROM, etc., a volatile memory-based SSD, such as a solid-state RAM, a dynamic RAM, a static RAM, a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a combination of DRAM and a flash memory-based SSD. The disk drive and its associated computer readable media may provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for the computer system 900.

[0122] The communication subsystem 924 provides an interface to other computer systems and networks. The communication subsystem 924 is used as an interface for receiving data from other systems and sending data from the computer system 900 to other systems. For example, the communication subsystem 924 can enable the computer system 1000 to be connected to one or more devices via the Internet. In some embodiments, the communication subsystem 924 may include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular phone technology, high-layer data network technology such as 3G, 4G or EDGE (Enhanced Data Rate for Global Evolution)), Wi-Fi (IEEE 802.11 series standards, or other mobile communication technologies, or any combination thereof), a global positioning system receiver component, and / or other components. In some embodiments, in addition to or in place of a wireless interface, the communication subsystem 924 may provide a wired network connection (e.g., Ethernet).

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

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

[0125] In addition, the communication subsystem 924 can also be configured to receive data in the form of a continuous data stream, which can include an event stream 928 of real-time events and / or event updates 930, which can be continuous in nature or have 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 business management applications), clickstream analysis tools, automotive business monitoring, etc.

[0126] 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 may be in computer communication with one or more streaming data sources coupled to the computer system 900 .

[0127] Computer system 900 may be one of various types, including a handheld portable device (e.g., Cellular phone, computing tablets, PDAs), wearable devices (e.g., Google head mounted displays), PCs, workstations, mainframes, kiosks, server racks, or any other data processing system.

[0128] Due to the ever-changing nature of computers and networks, the description of computer system 900 shown in the accompanying drawings is intended only as a specific example. Many other configurations with more or less components than the system described in the accompanying drawings are also possible. For example, customized hardware and / or specific elements can be implemented in hardware, firmware, software (including small applications) or a combination thereof. In addition, connections to other computing devices such as network input / output devices can be used. Based on the disclosure and teaching provided herein, those of ordinary skill in the art will understand other ways and / or methods for implementing various embodiments.

[0129] Although specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also included within the scope of the present disclosure. The embodiments are not limited to operating in certain specific data processing environments, but are free to operate in multiple data processing environments. In addition, although the embodiments have been described using a specific series of transactions and steps, it will be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. The various features and aspects of the above-described embodiments may be used alone or in combination.

[0130] In addition, although specific combinations of hardware and software have been used to describe embodiments, it should be appreciated that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments may be implemented in hardware only, or in software only, or using a combination thereof. The various processes described herein may be implemented in any combination on the same processor or on different processors. Therefore, where a component or module is described as being configured to perform certain operations, such configuration may be implemented, for example, by an electronic circuit designed to perform the operation, by a programmable electronic circuit (such as a microprocessor) programmed to perform the operation, or any combination thereof. Processes may communicate using various techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0131] Therefore, the description and drawings should be regarded as illustrative rather than restrictive. However, it is apparent that additions, subtractions, deletions and other modifications and changes may be made thereto without departing from the broader spirit and scope set forth in the claims. Therefore, although specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

[0132] In the context of describing the disclosed embodiments (especially in the context of the following claims), unless otherwise indicated herein or clearly contradicted by the context, the use of the terms "a", "the" and similar references will be interpreted as including both the singular and the plural. Unless otherwise indicated, the terms "including", "having", and "comprising" should be interpreted as open terms (i.e., meaning "including but not limited to"). The word "connected" should be interpreted as being partially or completely contained in, attached to, or connected together, even if something intervenes. Unless otherwise indicated herein, and each individual value is incorporated into the specification as if it is quoted separately herein, otherwise, the reference range of values ​​herein is merely used as a shorthand method for individually quoting each value falling within the range. All methods described herein can be performed in any appropriate order, unless otherwise indicated herein or clearly contradicted by the context. The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate the embodiments, and unless otherwise stated, does not limit the scope of the present disclosure. Any language in the specification should not be interpreted as indicating any non-claim elements that are essential to the practice of the present disclosure.

[0133] Unless specifically stated otherwise, disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in the context of being generally used to indicate that an item, term, etc. may be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z are all present.

[0134] Preferred embodiments of the present disclosure are described herein, including the best known modes for implementing the present disclosure. Variations of these preferred embodiments may become apparent to those of ordinary skill in the art after reading the foregoing description. Those skilled in the art should be able to appropriately adopt such variations, and the present disclosure may be implemented in a manner different from that specifically described herein. Therefore, the present disclosure includes all modifications and equivalent forms of the subject matter described in the appended claims, where permitted by applicable law. In addition, unless otherwise specified herein, any combination of the above elements in all possible variations thereof is included in the present disclosure.

[0135] All references, including publications, patent applications, and patents, cited herein are hereby 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.

[0136] In the foregoing description, various aspects of the present disclosure are described with reference to their specific embodiments, but those skilled in the art will recognize that the present disclosure is not limited thereto. The various features and aspects disclosed above may be used alone or in combination. In addition, without departing from the broader spirit and scope of this specification, the embodiments may be used in any number of environments and applications outside of the environments and applications described herein. Therefore, the description and drawings should be regarded as illustrative rather than restrictive.

Claims

1. A method comprising: generating, by a computing instance executing in a source cloud environment, a request to use a service provided in a target cloud environment, the source cloud environment being different from the target cloud environment; transmitting the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway; and The service is executed in the target cloud environment based on the access role associated with the computing instance.

2. The method according to claim 1, further comprising: The computing instance sends the request to a source inter-cloud service gateway provided in the source cloud environment, wherein the request includes an identity subject associated with the computing instance; as well as The identity principal of the computing instance is verified by the source inter-cloud service gateway. 3 . The method of claim 2 , wherein authenticating the identity principal comprises verifying whether the computing instance is permitted to access the service in the target cloud environment.

4. The method according to claim 2, further comprising: In response to the identity principal being successfully authenticated, the source inter-cloud service gateway obtains the access role associated with the computing instance from pre-configuration information stored in the source cloud environment.

5. The method according to claim 4, further comprising: In response to the identity principal being successfully authenticated, modifying, by the source inter-cloud service gateway, the request to generate a modified request, wherein the modification includes removing the identity principal included in metadata of the request and merging the access role associated with the computing instance into the metadata; as well as The source inter-cloud service gateway sends the modified request to a target inter-cloud service gateway disposed in the target cloud environment.

6. The method according to claim 5, wherein the source inter-cloud service gateway is set in a first data plane of the source cloud environment, and the target inter-cloud service gateway is set 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 trusted communication channel.

7. The method according to claim 5, further comprising: extracting, by the target inter-cloud service gateway, the access role associated with the computing instance from the modified request; as well as The target inter-cloud service gateway obtains a token associated with the access role from a management service included in the target cloud environment.

8. The method according to claim 7, further comprising: Signing, by the target inter-cloud service gateway, the modified request with the token associated with the access role to form a signed modified request; as well as The signed modified request is forwarded to the service desired for use by the computing instance.

9. The method according to claim 8, further comprising: verifying, by the service, the signed modified request based on the token; as well as In response to successful authentication, the request is executed by the service.

10. A computer readable medium storing specific computer executable instructions which, when executed by a processor, cause a computer system to at least: generating, by a computing instance executing in a source cloud environment, a request to use a service provided in a target cloud environment, the source cloud environment being different from the target cloud environment; transmitting the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway; and The service is executed in the target cloud environment based on the access role associated with the computing instance.

11. The computer-readable medium storing specific computer-executable instructions according to claim 10, wherein the computer system is further configured to: The computing instance sends the request to a source inter-cloud service gateway provided in the source cloud environment, wherein the request includes an identity subject associated with the computing instance; and The identity principal of the computing instance is verified by the source inter-cloud service gateway.

12. The computer-readable medium storing specific computer-executable instructions of claim 11, wherein authenticating the identity principal comprises verifying whether the computing instance is permitted to access the service in the target cloud environment.

13. The computer-readable medium storing specific computer-executable instructions according to claim 11, wherein the computer system is further configured to: In response to the identity principal being successfully authenticated, the source inter-cloud service gateway obtains the access role associated with the computing instance from pre-configuration information stored in the source cloud environment.

14. The computer-readable medium storing specific computer-executable instructions according to claim 13, wherein the computer system is further configured to: In response to the identity principal being successfully authenticated, modifying, by the source inter-cloud service gateway, the request to generate a modified request, wherein the modification includes removing the identity principal included in metadata of the request and merging the access role associated with the computing instance into the metadata; and The source inter-cloud service gateway sends the modified request to a target inter-cloud service gateway disposed in the target cloud environment.

15. The computer-readable medium storing specific computer-executable instructions according to claim 14, wherein the source inter-cloud service gateway is set in a first data plane of the source cloud environment, and the target inter-cloud service gateway is set 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 trusted communication channel.

16. The computer-readable medium storing specific computer-executable instructions according to claim 14, wherein the computer system is further configured to: extracting, by the target inter-cloud service gateway, the access role associated with the computing instance from the modified request; and The target inter-cloud service gateway obtains a token associated with the access role from a management service included in the target cloud environment.

17. The computer-readable medium storing specific computer-executable instructions according to claim 16, wherein the computer system is further configured to: Signing, by the target inter-cloud service gateway, the modified request with the token associated with the access role to form a signed modified request; and The signed modified request is forwarded to the service desired for use by the computing instance.

18. A system comprising: processor; as well as a memory comprising instructions that, when executed by the processor, cause the system to at least: generating, by a computing instance executing in a source cloud environment, a request to use a service provided in a target cloud environment, the source cloud environment being different from the target cloud environment; transmitting the request from the source cloud environment to the target cloud environment via an inter-cloud service gateway; and The service is executed in the target cloud environment based on the access role associated with the computing instance.

19. The system according to claim 18, further configured to: The computing instance sends the request to a source inter-cloud service gateway provided in the source cloud environment, wherein the request includes an identity subject associated with the computing instance; and The identity principal of the computing instance is verified by the source inter-cloud service gateway.

20. The system of claim 19, wherein the system is configured to authenticate the identity principal by verifying whether the computing instance is permitted to access the service in the target cloud environment.

Images