Nested resource identity management for cloud resources

Abstract

A system is disclosed that includes functionality allowing nested sub-resources residing in a service tenancy to access customer-owned resources residing in a customer tenancy without using cross-tenancy policies. The disclosed system provides functionality for nested sub-resources residing in a service tenancy to obtain the resource principal identity of a higher-level resource residing in the customer tenancy and to access customer-owned resources residing in the customer tenancy using the identity of that higher-level resource. By using the resource principal identity of its own higher-level resource, the sub-resource can access customer-owned resources residing in the customer tenancy in a seamless manner without having to write a cross-tenancy policy statement that grants the sub-resource permission to access those customer-owned resources.

Description

TECHNICAL FIELD

[0001] This application is a PCT application of U.S. Non-Provisional Application No. 18 / 373,707 entitled "Nested Resource Identity Management for Cloud Resources" filed on September 27, 2023, and claims the benefit and priority of such application under 35 U.S.C. § 119(e), the entire content of which is incorporated herein by reference in its entirety for all purposes.

[0002] This application also claims the benefit and priority of Indian Provisional Patent Application No. 202341062291 entitled "Nested Resource Identity Management for Cloud Resources" filed on September 15, 2023, the entire content of which is incorporated herein by reference in its entirety for all purposes.

[0003] Technical Field The present disclosure relates generally to secure access to cloud-based resources. More specifically, but not by way of limitation, the present disclosure describes a nested resource principal management system that includes functionality to allow resources residing in a first tenant to access customer-owned resources residing in a different tenant without using cross-tenant policies.

BACKGROUND ART

[0004] Background Demand for cloud-based services continues to increase rapidly. The term "cloud service" is generally used to refer to services made available on demand (e.g., through a subscription model) to users or customers using systems and infrastructure (cloud infrastructure) provided by a cloud service provider. Typically, the servers and systems that make up the cloud service provider's infrastructure are separate from the customer's own on-premises servers and systems. Therefore, customers can use cloud services provided by a cloud service provider without needing to purchase separate hardware and software resources for the service. There are various different types of cloud services, including SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service), and IaaS (Infrastructure-as-a-Service).

[0005] Customers can subscribe to one or more cloud services provided by the CSP. Customers can be any entity, including individuals, organizations, and corporations. When a customer registers for or subscribes to a service provided by the CSP, a tenancy or account is created for that customer. Through this account, the customer can access one or more subscribed cloud resources associated with that account. [Overview of the project] [Problems that the invention aims to solve]

[0006] To leverage the numerous benefits offered by cloud services, customers may in some cases want to share their resources with external entities outside their own tenancy (e.g., CSPs or third-party tenancies). Accessing and sharing resources typically requires administrators in both tenancies to create special policy statements explicitly describing which resources are accessible and shareable. In some situations, internal resource details (e.g., resource identity) need to be exposed to administrators in different tenancies to enable cross-tenancy access and sharing. Furthermore, writing complex cross-tenancy policies can be cumbersome for customers and may compromise the security of cloud-based services.

[0007] Brief Overview This disclosure broadly pertains to secure access to cloud-based resources. More specifically, but not limited to, this disclosure describes a nested resource principal management system that includes the ability to enable resources residing in a first tenancy to access customer-owned resources residing in different tenancies without the use of cross-tenancy policies. [Means for solving the problem]

[0008] In one embodiment, a nested resource principal management system is disclosed. The system obtains a first identity for a first resource residing in a service tenancy of a cloud service provider (CSP). In one example, the first resource may represent a nested sub-resource residing in the CSP's service tenancy, which is part of a higher-level resource (a second resource). The second resource resides in a customer tenancy. The first identity associated with the first resource may correspond to a resource principal identity (RPT) associated with the first resource. The RPT is a secure identity provided to a cloud infrastructure resource that enables that resource to be authorized to access other cloud infrastructure resources.

[0009] In one example, the system retrieves the RPT for the first resource from the service control plane associated with the resource. The system then retrieves information identifying the second resource. This information may identify the endpoint of the second resource and may represent the URL of the resource endpoint of the second resource.

[0010] Next, the system uses the first identity to obtain the first token for the first resource. The first token enables the first resource to assert its first identity. The first token corresponds to the Resource Principal Session Token (RPST) associated with the first resource. The resource's RPST is a temporary session token and secure credentials that allows the resource to authenticate itself to other cloud resources owned by the CSP (assert its own resource principal identity).

[0011] In one embodiment, the system obtains a second identity associated with a second resource. The second identity may correspond to a resource principal identity (RPT) associated with the second resource, which can be obtained from the control plane associated with the second resource by a nested resource principal management system. The system then uses the second identity to obtain a second token for the first resource. The second token enables the first resource to claim the second identity. In one embodiment, the second token may correspond to a resource principal session token (RPST) associated with the second resource. In one example, the resource then uses the second token to access customer-owned resources residing in the customer tenancy. [Brief explanation of the drawing]

[0012] [Figure 1] This is a simplified diagram of a computing environment 100 that includes a nested resource principal management system, which includes the ability to enable nested sub-resources residing in a cloud service provider's (CSP) service tenancy to access customer-owned resources in a customer tenancy without cross-tenancy policy calls. [Figure 2] This figure illustrates an example of processing performed by the control plane associated with the services of a service tenancy in order to provision resources to the service tenancy, according to one embodiment. [Figure 3] This is a sequence diagram illustrating a series of interactions, according to one embodiment, that enable nested sub-resources residing in a service tenancy to access customer-owned resources residing in a customer tenancy. [Figure 4] This diagram shows the resource hierarchy configured in a machine learning (ML) application according to one embodiment. [Figure 5]This sequence diagram illustrates a series of interactions, according to one embodiment, that enable nested lower-level resources of an ML application residing in a service tenancy to access customer-owned resources residing in a customer tenancy. [Figure 6] This figure shows an example of a process performed by a nested resource principal management system and identity management system within the computing environment shown in Figure 1, according to one embodiment. [Figure 7] This is a block diagram illustrating one pattern for implementing a cloud infrastructure system as a service, in at least one embodiment. [Figure 8] This block diagram illustrates another pattern for implementing a cloud infrastructure system as a service, in at least one embodiment. [Figure 9] This block diagram illustrates another pattern for implementing a cloud infrastructure system as a service, in at least one embodiment. [Figure 10] This block diagram illustrates another pattern for implementing a cloud infrastructure system as a service, in at least one embodiment. [Figure 11] A block diagram showing an exemplary computer system according to at least one embodiment. [Modes for carrying out the invention]

[0013] Detailed explanation In the following description, specific details are provided to fully understand certain embodiments for illustrative purposes. However, it will be apparent that various embodiments can be carried out without these specific details. The figures and descriptions are not intended to be restrictive. The word “exemplary” is used herein to mean “serving as an example, case, or illustration.” No embodiment or design described herein as “exemplary” is necessarily to be construed as preferable or advantageous to any other embodiment or design.

[0014] This disclosure broadly pertains to secure access to cloud-based resources. More specifically, but not limited to, this disclosure describes a nested resource principal management system that includes the ability to enable resources residing in a first tenancy to access customer-owned resources residing in different tenancies without the use of cross-tenancy policies.

[0015] As mentioned earlier, successfully writing cross-policy statements that enable resource sharing across different tenancies requires exposing internal resource details (e.g., resource identity) to administrators in different tenancies. Existing methods for enabling resources residing in a first tenancy (e.g., a service tenancy) to access customer-owned resources residing in a different tenancy (e.g., a customer tenancy) traditionally involve the customer writing a cross-tenancy policy that allows that resource to successfully make a cross-tenancy call to the customer-owned resource. This typically involves making the resource principal identity of the resource available to the customer so that the customer can successfully write a cross-tenant policy that grants permission for resources residing in the service tenancy to access customer-owned resources. Exposing the resource principal identity of a resource provisioned in a tenancy different from the customer's tenancy (e.g., a service tenancy) is not ideal and could compromise the security of cloud resources.

[0016] As described herein, a service tenant and a customer tenant may correspond to secure and isolated partitions of cloud infrastructure provided by a CSP for creating, organizing, and managing cloud resources. For example, a customer tenant may refer to an account created for a customer of the CSP. A customer can be any entity, such as an individual, an organization, an enterprise, or the like. When a customer subscribes to or registers for a service provided by the CSP, a tenant or account for that customer is created, and this tenant or account is referred to as a customer tenant. Different customer tenants may be created for different customers of the CSP. Then, the customer can access one or more subscribed cloud resources associated with the customer's account via the customer's tenant. In some examples, a customer tenant is associated with a compartment. A compartment refers to a logical container for organizing and controlling access to cloud resources (e.g., computing, storage, network, load balancers, etc.) created within that compartment.

[0017] A service tenant (also referred to as a cloud provider tenant) is a tenant associated with a CSP for provisioning, configuring, and managing the lifecycle of cloud resources associated with services provided by the CSP, and provides a secure and isolated partition or provisioning platform. In some embodiments, different service tenants may be provided for different cloud services provided by the CSP. For example, a first service tenant may be provided for a first cloud service provided by the CSP (e.g., a Fusion Application (FA) cloud service), a second service tenant may be provided for a second cloud service provided by the CSP (e.g., a data science service for training and provisioning machine learning (ML) models), a third service tenant may be provided for a third cloud service provided by the CSP, and so on.

[0018] The various embodiments described in this disclosure address shortcomings of existing methods by disclosing a nested resource principal management system that includes the ability for nested cloud resources residing in a first tenancy (e.g., a service tenancy) to access customer-owned resources residing in a second tenancy (e.g., a customer tenancy) without using cross-tenant policies. In one embodiment, the nested cloud resources are part of a higher-level resource created in the customer tenancy. The internal configuration of such a higher-level resource is typically hidden from the customer, who perceives the resource as a single entity (i.e., a single logical resource) in the customer tenancy. The actual provisioning / allocation of infrastructure resources (i.e., sub-resources) configured within the higher-level resource is performed by a service in the service tenancy responsible for managing those resources.

[0019] The disclosed system provides a function that allows nested sub-resources present in a service tenant to obtain the resource principal identity of a higher-level resource present in a customer tenant, and use the identity of the higher-level resource to access customer-owned resources present in the customer tenant. The resource principal identity, also referred to throughout the present disclosure as a resource principal token (RPT), is a secure identity provided to cloud infrastructure resources, which enables the resource to receive authorization to access other cloud infrastructure resources. In one example, the resource principal identity is a token signed by an authoritative service of the CSP responsible for resource management, providing reliable metadata related to the resource. By obtaining the resource principal identity of the higher-level resource, the sub-resources present in the service tenant are granted the same permissions as the higher-level resource for accessing other customer-owned resources. By using the resource principal identity of the higher-level resource, the sub-resources present in the service tenant can access the customer-owned resources present in the customer tenant in a seamless manner using a general-purpose policy associated with the higher-level resource that provides permission for the higher-level resource to interact with other customer-owned resources within the customer tenant. Customers do not need to write separate cross-tenant policy statements that grant sub-resources permission to access customer-owned resources.

[0020] The system described in this disclosure offers several technical advancements and / or improvements over traditional methods for providing secure access to cloud-based resources. Using the disclosed system, customers can write robust and simple access control policies that provide streamlined and secure access management to cloud resources. The functionality provided by the disclosed system allows customers to write only a single policy for the higher-level resources they own within their customer tenancy. Because customers do not need to write policies for sub-resources configured within the higher-level resources, details of sub-resources (e.g., resource principal identity) do not need to be exposed to the customer. In addition, changes can be made to sub-resources configured within the higher-level resources (e.g., adding new resources, changing hierarchies or resources, deleting resources, etc.) without affecting the customer or compromising the security of the resources.

[0021] Referring to the drawings, Figure 1 shows a simplified diagram of a computing environment 100 that includes a nested resource principal management system, which, according to one embodiment, includes a function that allows nested sub-resources residing in a service tenancy of a cloud service provider (CSP) to access customer-owned resources in a customer tenancy without cross-tenancy policy calls. As mentioned above, service tenancies and customer tenancies may correspond to secure and isolated partitions of the cloud infrastructure provided by the CSP for creating, organizing, and managing cloud resources. For example, a customer tenancy may refer to an account created for a customer of the CSP. A customer can be any entity, such as an individual, organization, or company. When a customer subscribes to or registers for services provided by the CSP, a tenancy or account is created for that customer, and this tenancy or account is called a customer tenancy. Different customer tenancies may be created for different customers of the CSP. A customer can then access one or more subscribed cloud resources associated with their account through their customer tenancy. In one example, a customer tenancy is associated with a compartment. A compartment refers to a logical container used to organize and control access to cloud resources (such as compute, storage, networking, and load balancers) created within that compartment.

[0022] A service tenancy (also known as a cloud provider tenancy) is a tenancy associated with a CSP for provisioning, configuring, and managing the lifecycle of cloud resources associated with services provided by the CSP, providing a secure and isolated partition or provisioning platform. In some embodiments, different service tenancies may be provided for different cloud services provided by the CSP. For example, a first service tenancy may be provided for a first cloud service provided by the CSP (e.g., a Fusion Application (FA) cloud service), a second service tenancy may be provided for a second cloud service provided by the CSP (e.g., a data science service for training and provisioning machine learning (ML) models), a third service tenancy may be provided for a third cloud service provided by the CSP, and so on.

[0023] For example, in the case of a Fusion Application (FA) cloud service, the service tenancy provided for this service may include the ability to provision FA resources for the CSP's customers. FA resources may represent a type of cloud resource that the CSP provides to the customer for enterprise resource planning purposes. In one example, provisioning a cloud resource (e.g., an FA resource) may involve provisioning several lower-level infrastructure resources configured within the cloud resource, such as databases, buckets, and object stores. However, the internal configuration of the cloud resource is typically hidden from the customer, who perceives the resource as a single entity (i.e., a single logical resource). While the creation of cloud resources is typically performed by the customer within the customer tenancy, the actual provisioning / allocation of lower-level infrastructure resources (also referred to herein as sub-resources) that are part of higher-level resources is performed by a service in the service tenancy responsible for managing those resources. Once provisioned, customers can interact with higher-level resources (also known as root resources in this specification) and write policies for those resources and resources residing in different tenancies (e.g., service tenancies, third-party tenancies) that grant those resources access to other resources within the customer tenancy (e.g., object storage buckets, vault secrets, etc.).

[0024] For example, as shown in Figure 1, a customer can create resource R1 in customer tenancy 102. Resource R1 can consist of multiple lower-level resources (sub-resources, R2 and R3). Resource R1 represents the top-level resource (root resource), and R2 and R3 represent child resources of resource R1. For example, as mentioned above, resource R1 may represent a fusion pod or fusion application (FA) resource that a customer can use for enterprise resource planning purposes. Such a resource (R1) can consist of multiple sub-resources, R2 and R3 (e.g., a database, a bucket, and a key). In the example shown in Figure 1, R2 and R3, which are sub-resources of resource R1, are also hierarchically related, with R3 being a child resource of its parent resource, R2.

[0025] The internal configuration of resource R1 (e.g., R2 and R3) is typically hidden from the customer, and the customer perceives resource R1 as a single entity (i.e., a single logical resource) within their customer tenancy. Sub-resources are typically provisioned by various downstream service control planes residing in one or more service tenancies of the CSP. For example, as shown in Figure 1, to provision resource R1, a customer (e.g., an end user associated with the customer) can send a resource creation request to the customer control plane associated with resource R1 (e.g., 108). The resource creation request is received by the customer control plane R1 108 associated with resource R1. The customer control plane R1 108 may be associated with an authoritative service that owns resource R1 and is responsible for creating and managing resource R1 within the customer tenancy. Upon receiving the resource creation request, the customer control plane R1 108 bootstraps / provisions an instance of resource R1 and sets the endpoint of resource R1 to the customer control plane R1 108. Next, the customer control plane R1 108 can create the resource principal identity for resource R1 and provide the customer with metadata associated with resource R1 (e.g., tags, customer tenancy compartment identifiers, etc.).

[0026] Resource Principal Identity, also referred to as Resource Principal Token (RPT) throughout this disclosure, is a secure identity provided to a cloud infrastructure resource that enables the resource to be authorized to access other cloud infrastructure resources. In one example, the Resource Principal Identity is a token signed by an authoritative service of the CSP, providing trusted metadata about the resource. Once provisioned, the customer can interact with resource R1 and write policies that grant this resource access to other customer tenancy resources, such as vault resource 118 and object store 120.

[0027] As described above, once an instance of resource R1 is created in customer tenancy 102, customer control plane R1 108 then initiates the creation of child resource R2 by communicating with service control plane R2 110, which is associated with the authoritative service that owns resource R2 in service tenancy 1 104. Upon receiving the resource creation request, service control plane R2 110 bootstraps / provisions an instance of resource R2 and sets the endpoint for resource R2 to service control plane R2 110. Next, service control plane R2 110 creates the resource principal identity for resource R2. Similarly, resource R3, a child resource of resource R2, is provisioned by its service control plane R3 112 in service tenancy 2 106. Details regarding the processes that the service control plane performs to provision sub-resources (e.g., R2 or R3) configured within a higher-level resource (R1) are described below with reference to Figure 2 and its description.

[0028] In a certain scenario, a sub-resource (e.g., R3) configured within resource R1 may want to access a customer-owned resource (e.g., vault resource 118) located in the customer tenancy. Since sub-resource R3 is provisioned in the service tenancy and the customer-owned resource resides in the customer tenancy, for sub-resource R3 to access the vault resource, the customer is typically required to write a cross-tenant policy that allows sub-resource R3 to access the vault resource. For example, sub-resource R3 may represent a database resource configured within the higher-level FA resource described above. The database resource may need to access a resource (e.g., an encryption key) from the customer-owned vault resource 118. Data within the database resource can be encrypted using an encryption key provided by the customer, and the encryption key resides in the customer tenancy. Since the database resource resides in the service tenancy, when the database resource attempts to access the key from vault resource 118, the database resource needs to make a cross-tenancy call to access the vault resource.

[0029] Existing methods for enabling sub-resources configured within higher-level resources to access customer-owned resources typically involve the customer writing cross-tenancy policies that allow sub-resources to successfully make cross-tenancy calls to customer-owned resources. This usually involves making the resource principal identities of both database and vault resources available to the customer so that the customer can successfully write cross-tenancy policies that grant sub-resources permission to access customer-owned resources. Exposing the resource principal identities of resources provisioned in a different tenancy from the customer's tenancy (e.g., a service tenancy) is not ideal and could compromise the security of cloud resources.

[0030] The various embodiments described in this disclosure address shortcomings of existing methods for providing secure resource access by disclosing a nested resource principal management system 116, which includes the ability for a nested sub-resource residing in one tenancy (e.g., a service tenancy) to access customer-owned resources residing in a different tenancy (e.g., a customer tenancy) without using cross-tenant policies. The nested resource principal management system 116 provides the ability for a nested sub-resource residing in a service tenancy to obtain the resource principal identity of a higher-level resource residing in a customer tenancy and to use that higher-level resource identity to access customer-owned resources residing in the customer tenancy. By obtaining the resource principal identity of a higher-level resource, the sub-resource residing in the service tenancy is granted the same permissions as the higher-level resource to access other customer-owned resources. By using the resource principal identity of a higher-level resource, the sub-resource can seamlessly access customer-owned resources residing in the customer tenancy using a generic policy associated with the higher-level resource that provides the higher-level resource with permissions to interact with other customer-owned resources. Customers do not need to write separate cross-tenancy policy statements that grant permission for sub-resources to access customer-owned resources.

[0031] Therefore, the disclosed system enables customers to write robust and simple access control policies that provide streamlined and secure access management of cloud resources. By using the functionality provided by the disclosed system, customers only need to write a single policy for the top-level (root resource) resources they own within their customer tenancy. Customers do not need to write policies for sub-resources configured within the higher-level resources, and therefore do not need to expose sub-resource details (e.g., resource principal identity) to the customer. In addition, changes can be made to sub-resources configured within the higher-level resources (e.g., adding new resources, changing the resource hierarchy, deleting resources, etc.) without affecting the customer or compromising the security of the resources.

[0032] In one embodiment, the nested resource principal management system 116 interacts with the identity management system 114 within the CSP to obtain the resource principal identity of the nested sub-resource. Details regarding the nested resource identity management system and the processes performed by the identity management system are described below with reference to Figure 3 and its description.

[0033] The computing environment 100 shown in Figure 1 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, substitutions, and modifications. For example, in some embodiments, the computing environment 100 may be implemented using more or fewer subsystems than those shown in Figure 1, may be a combination of two or more subsystems, or may have subsystems of different configurations or arrangements. Subsystems 114 and 116 shown in Figure 1 may be implemented using only software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the computing system, using hardware, or a combination thereof. The software may be stored in a non-temporary storage medium (e.g., a memory device).

[0034] Figure 2 illustrates an example of the process performed by the control plane associated with a service in a service tenancy to provision a resource in the service tenancy, according to one embodiment. In one example, such as the embodiment described in Figure 1, a resource may represent a nested sub-resource (e.g., R2) that exists in the service tenancy, and resource R2 is configured within a higher-level resource R1 that exists in the customer tenancy. For example, the higher-level resource may represent an FA resource, and sub-resource R2 may represent a database resource configured within the FA resource. As described in Figure 1, when an instance of the higher-level (root) resource R1 is created in the customer tenancy, the customer control plane R1 108 associated with resource R1 initiates the creation of the sub-resource (R2) by calling the service control plane (e.g., control plane R2 110) associated with an authoritative downstream service that owns resource R2 in the service tenancy and is responsible for provisioning sub-resource R2 in the service tenancy.

[0035] In the example shown in Figure 2, the downstream service represents the database service (Database as a Service (DBaaS)) of the service tenancy 216 and is responsible for provisioning instances of the database resource configured within the higher-level FA resource. Upon receiving an instance creation request from the customer control plane 218 of the FA resource, the DBaaS control plane (CP) 202, which is the control plane of the database service, provisions instances of the database resource by allocating virtual machines (VMs) and disk storage for the database resource within the Exadata Rack 204. As described herein, the Exadata Rack 204 represents the computing platform (i.e., a hardware and software combination platform) within the service tenancy 216 of the database service that allocates computing resources (storage and servers) to run the database resource.

[0036] In one example, the allocation of a database resource instance (also referred to herein as an Exadata resource instance) involves DBaaS CP202 allocating a database process ("abc_1") running on VM204 within Exadata Rack204, along with disk storage 212 for the database process ("abc_1"). In the example shown in Figure 2, Exadata Rack204 consists of multiple VMs (e.g., VM1 204, VM2 206, VM3 208, VMn 210). Multiple database processes (e.g., abc_1, def_1) may run within a particular VM (Exadata instance). For example, "abc_1" may represent a database process in an Exadata resource instance allocated to the first customer of the CSP, and "def_1" may represent a database process in the same Exadata instance allocated to another customer of the CSP, along with disk storage 214. Each database instance (Exa instance) further has a secondary instance running on a secondary VM (e.g., VM2 206) for high availability. Each database process running on a VM is seeded with a file (e.g., a JSON file) that is accessible to that database process. This file contains metadata information about the resource instance. Each database process also has a service identifier, which is a unique identifier that identifies the service that owns the database process. Each VM is also seeded with a DBaaS control plane endpoint that can be called to retrieve the resource principal identity.

[0037] As described above, the resource principal identity is a resource identifier (also referred to herein as a resource principal token (RPT)) that is signed by an authoritative service (e.g., DBaaS) that provides trusted metadata about the resource (e.g., resource ID, tags, compartment identifier, etc.). In one example, a nested resource principal management system 116 (shown in Figure 1) obtains the database resource's RPT from the database resource's control plane 202 and then obtains the higher-level FA resource's RPT by communicating with the FA resource's customer control plane 218. The FA resource's RPT is associated with a compartment (tenant) identifier and a service identifier belonging to the customer tenancy. The database resource can then use the FA resource's RPT to access customer-owned resources (e.g., the vault resource 118 shown in Figure 1). The customer-owned resource recognizes the database resource having an RPT with a service identifier and tenancy information within the customer tenancy, and the database resource is provided with access to the vault resource 118's cryptographic key without the database resource needing to make a cross-tenancy call to access the vault resource 118.

[0038] In one embodiment, the nested resource principal management system 116 can be implemented using software (e.g., code, instructions, programs) executed by a client application running within the database process (e.g., abc_1) shown in Figure 2. This software may represent a collection of software development kit (SDK) tools that include the ability to retrieve the resource's RPT from the service control plane corresponding to the resource. Using the resource's RPT in the resource hierarchy, the nested resource principal management system 116 further interacts with an identity management system (e.g., 114 shown in Figure 1) to obtain the resource's resource principal session token (RPST). In one example, the resource's RPST represents a temporary session token and secure credentials associated with the resource, provided by the identity management system to the nested resource principal management system 116. The resource uses its RPST to authenticate itself to other cloud resources (e.g., infrastructure resources) and services owned by the CSP. Using the RPST, the resource can assert its resource principal identity (RPT) to other cloud resources and services owned by the CSP. In one embodiment, the RPST may be formatted as a JSON Web Token (JWT) token and include claims that identify the resource's host tenancy and compartment information. By using the RPST of a higher-level resource, a nested sub-resource residing in a service tenancy (e.g., R2) can access customer-owned resources in a customer tenancy without making a cross-tenancy policy call. Details of the interaction between the nested resource identity management system and the identity management system to enable nested sub-resources residing in a service tenancy to access customer-owned resources residing in a customer tenancy are shown in Figure 3.

[0039] Figure 3 is a sequence diagram illustrating a series of interactions in one embodiment that enable a nested sub-resource residing in a service tenancy to access customer-owned resources residing in a customer tenancy. In the example shown in Figure 3, the nested sub-resource R3 is part of a resource hierarchy that includes R2 and R1. Resources R1, R2, and R3 are hierarchically related to each other, with R1 representing the top-level resource in the hierarchy and R2 and R3 representing sub-resources within the hierarchy. In addition, R2 and R3 are hierarchically related, with R3 being a child resource (sub-resource) of R2.

[0040] As shown in Figure 3, processing begins in operation 314, when the nested sub-resource R3 302 provisioned to the service tenancy sends a request to the service control plane (CP R3 304) associated with the authoritative service that owns resource R3, requesting the resource principal identifier (i.e., RPT) of R3. In one embodiment, the nested resource principal management system 116 (shown in Figure 1) retrieves the RPT of resource R3 from the control plane 202 of resource R3. For example, as illustrated in Figure 2, the nested resource principal management system 116 can be implemented using software (e.g., code, instructions, programs) executed by a client application running within the process shown in Figure 2 (e.g., abc_1) in a virtual machine provisioned for the resource by the service. This software may represent a collection of software development kit (SDK) tools that include the ability to retrieve the RPT of that resource from the service control plane corresponding to that resource.

[0041] The control plane of R3 validates the request and, after validation, issues an RPT for resource R3. In operation 316, the control plane of R3 sends the RPT for resource R3 along with information (e.g., an endpoint) that identifies the resource at the next level in the resource hierarchy. In one embodiment, the endpoint may represent the uniform resource locator (URL) of the resource endpoint of the resource at the next level in the resource hierarchy. In one embodiment, such as the embodiment shown in Figure 1, resource R3 is a child resource of its parent resource R2 in the resource hierarchy, so as a result of executing operation 316, resource R3 302 receives endpoint information that identifies R2, which is the next level resource in the resource hierarchy.

[0042] In operation 318, resource R3 sends a request containing its RPT to the Identity Management System (IDM) 310 to obtain a Resource Principal Session Token (RPST) to assert its resource principal identity. As a result of performing operation 318, IDM 310 exchanges resource R3's RPT for R3's RPST. As mentioned above, the resource's RPST is a temporary session token and secure credentials that enables the resource to authenticate itself to other cloud resources owned by the CSP (assert its resource principal identity). The Identity Management System 310 shown in Figure 3 can be implemented in a similar manner to the Identity Management System 116 described in Figure 1.

[0043] In operation 320, the identity management system 310 sends the RPST to R3. In operation 322, resource R3 uses the RPST obtained in 320 to call the endpoint of resource R2, the next level in the resource hierarchy. In operation 324, the control plane of resource R2 (CP R2 306), which received the call, validates the request and, after validation, returns the RPT of resource R2 and the endpoint information of the resource at the next level in the resource hierarchy (if any). In the example shown in Figure 3, the control plane of resource R2 identifies resource R1 as the next level resource in the resource hierarchy and returns the RPT of resource R2 and the endpoint information of resource R1 to R3. In one embodiment, the nested resource principal management system 116 (shown in Figure 1) obtains the RPT of resource R2 from the control plane associated with resource R2. In operation 326, resource R3 sends a request containing the RPT of R2 to the identity management system (IDM) 310 to obtain the resource principal session token (RPST) of R2. As a result of performing operation 326, IDM 310 exchanges resource R2's RPT for its RPST, and in operation 328, IDM sends R2's RPST to R2.

[0044] In operation 330, resource R3 uses R2's RPT to call the endpoint of resource R1, the next level in the resource hierarchy, and obtains resource R1's RPT. In operation 332, R1's control plane 308 validates the request and, after validation, issues R1's RPT. In one embodiment, the nested resource principal management system 116 (shown in Figure 1) obtains resource R1's RPT from the control plane associated with resource R1. In operation 334, resource R3 requests resource R1's RPST from the identity management system, and in operation 336, resource R3 obtains R1's RPST from IDM 310.

[0045] In this way, resource R3 obtains resource RSPTs until it reaches the top level or root level of the resource hierarchy (resource R1 in this example). As a result of performing operation 338, resource R3 has three RSPTs: a first RPST representing its own identity, a second RPST representing the identity of its parent resource (R2), and a third RPST representing the identity of its grandparent resource (root) resource R1. The third RPST represents the identity of the top-level (root) resource R1 in the resource hierarchy, and since R1 resides in the customer tenancy, the nested lower-level resource R3 asserts its identity using resource R1's RPST when performing various operations, such as accessing the customer-owned resource 312. The customer-owned resource recognizes that resource R3 has an RPST containing tenancy information and service identifiers belonging to the customer tenancy, allowing resource R3 to access the customer-owned resource without having to make a cross-tenancy call.

[0046] The embodiments shown in Figures 1-3 above illustrate the creation of cloud resources using specific examples of Fusion Application (FA) resources created in a customer tenancy, where sub-resources configured within the FA application resource are provisioned by different service tenancies of the CSP. In addition, Figures 1-3 illustrate the capabilities provided by a disclosed nested resource principal management system that enable nested lower-level resources (e.g., a database resource within an FA resource) to obtain and use the resource principal identity of a higher-level FA resource to access customer-owned resources residing in the customer tenancy without using a separate cross-tenancy policy that provides permission for the lower-level resource to access customer-owned resources.

[0047] The disclosed nested resource principal management system can further be configured to allow other different types of cloud resources provisioned in a service tenancy to access customer-owned resources residing in a customer tenancy without the use of cross-tenancy policies. For example, in one embodiment, the disclosed nested resource principal management system includes the ability for nested sub-resources configured within a machine learning (ML) application to access customer-owned resources in a customer tenancy without the sub-resources making cross-tenancy calls to access customer-owned resources. As described herein, an ML application represents a type of cloud resource that a CSP provides to a customer for building, training, deploying, and managing machine learning models (also referred to herein as ML applications). An ML application typically consists of a set of one or more building blocks, including data storage resources (e.g., object storage buckets), execution resources, and resources for providing model predictions. Execution resources may represent Job Run resources and Pipeline Run resources. These execution resources can be provisioned by managed infrastructure (i.e., service tenancy or provisioning platform) provided by the CSP's services. Job Run resources enable the execution of repeatable machine learning tasks for an ML application. Job Run resources can automatically provision compute resources (such as CPUs or GPUs) based on the block volume, shape, and network configuration of the job required for model building. Pipeline Run resources enable the execution of end-to-end machine learning workflows for ML applications. Pipeline Run resources define workflows of tasks or steps for data import, data transformation, model training, and model evaluation.

[0048] In one embodiment, the creation of an ML application (also referred to herein as an ML resource) is typically performed by the customer in their customer tenancy. The internal configuration of the ML application is typically hidden from the customer, who perceives the application as a single entity (i.e., a single logical resource). The actual provisioning / allocation of the infrastructure resources configured within the ML application (e.g., Pipeline Run resources and Job Run resources) is performed by a service in a service tenancy responsible for managing those resources. Once provisioned, the customer can interact with the ML application and write policies that grant the ML application permission to access other resources within their customer tenancy and resources residing in different tenancies (e.g., service tenancies, third-party tenancies, etc.).

[0049] In one embodiment, a sub-resource configured within an ML application (e.g., a Job Run resource) may want to access customer-owned resources (e.g., object store 120) residing in the customer tenancy. The disclosed nested resource principal management system enables the sub-resource to access customer-owned resources using the resource principal identity of a higher-level resource (ML application) residing in the customer tenancy. By obtaining the resource identity of the higher-level resource, the sub-resource can access customer-owned resources seamlessly without making cross-tenancy policy calls. Because the sub-resource is associated with the resource principal identifier of the higher-level resource, it can access customer-owned resources using a generic policy associated with the higher-level resource that grants permission for the higher-level resource to interact with other customer-owned resources.

[0050] Figure 4 shows a hierarchy of resources configured in a machine learning (ML) application according to one embodiment. In the example shown in Figure 4, the ML application 402 represents the top-level (root) resource created in the customer tenancy. The Pipeline Run resource 404 and Job Run resource 406 represent sub-resources configured within the ML application 402. Sub-resources 404 and 406 represent child resources of the root resource 402. In addition, the Pipeline Run resource 404 and Job Run resource 406 are also hierarchically related, with Job Run resource 406 being a child resource of its parent Pipeline Run resource 404. The internal configuration of the ML application (e.g., the Pipeline Run resource and Job Run resource) is typically hidden from the customer, who perceives the ML application as a single entity (i.e., a single logical resource) in the customer tenancy 408. Sub-resources are typically provisioned by various downstream service control planes residing in one or more service tenancies of the CSP. In the example shown in Figure 4, both sub-resources 404 and 406 are provisioned to a single service tenancy 410 of the CSP. In an alternative embodiment, as shown in Figure 1, the sub-resources of higher-level resources may be provisioned to different service tenancies.

[0051] The provisioning of resources 402, 404, and 406 can be performed by a control plane associated with an authoritative service that owns / manages the resources in one or more service tenancies of the CSP, as illustrated in Figure 1. For example, using the example resources R1, R2, and R3 shown in Figure 1, resource R1 (e.g., representing ML application 402) may be provisioned to a customer tenancy in response to a resource creation request submitted by a customer of the customer tenancy. The resource creation request is received by the customer control plane associated with resource R1 (e.g., 108). Upon receiving the resource creation request, the service control plane for resource R1 bootstraps / provisions an instance of resource R1 and sets the endpoint for resource R1 to service control plane R1. Service control plane R1 can then also create a resource principal identity for resource R1 and provide the customer with trusted metadata associated with resource R1 (e.g., tags, customer tenancy compartment identifiers, etc.). Once provisioned, the customer can interact with resource R1 (i.e., the ML application) and write policies that grant the ML application access to other customer tenancy resources such as vault resource 118 and object store 120.

[0052] As described above, when an instance of resource R1 (e.g., an instance of an ML application) is created in customer tenancy 102, the service control plane of resource R1 then initiates the creation of its child resource R2 (e.g., a Pipeline Run resource) by communicating with service control plane R2 (e.g., 110), which is associated with the authoritative service that owns resource R2. Upon receiving the resource creation request, the service control plane of resource R2 bootstraps / provisions an instance of resource R2 and sets the endpoint of resource R2 in the service control plane. The service control plane of resource R2 then creates the resource principal identity for resource R2. Similarly, resource R3 (e.g., a Job Run resource), which is a child resource of the Pipeline Run resource, is provisioned by its service control plane R3 (e.g., 112).

[0053] In certain situations, a sub-resource configured within a higher-level ML application 402 (e.g., a Job Run resource 406) may want to access customer-owned resources (e.g., object storage resources) residing in a customer tenancy. Figure 5 is a sequence diagram illustrating a set of interactions that, in one embodiment, enable nested lower-level resources of an ML application residing in a service tenancy to access customer-owned resources residing in a customer tenancy. As illustrated in the example in Figure 4, the Job Run resource is part of a resource hierarchy that includes pipeline resources and top-level ML applications / resources. The Job Run resource and Pipeline Run resource are child resources of the ML application and are hierarchically related to each other. The ML application represents a higher-level resource, the Pipeline Run resource is a child resource of the ML application, and the Job Run resource is a child resource of its parent Pipeline Run resource.

[0054] As shown in Figure 5, processing begins in operation 514, when the Job Run resource 502 sends a request to the service control plane (CP JR 504) associated with the authoritative service that owns the Job Run resource, requesting its resource principal identifier (i.e., RPT). The Job Run resource's control plane validates the request and, after validation, issues the Job Run resource's RPT. In operation 516, the Job Run resource's control plane sends the Job Run resource's RPT along with information (e.g., endpoint information) that identifies the resource at the next level in the resource hierarchy. In some embodiments, such as the embodiment described in Figure 4, the Job Run resource is a child resource of the Pipeline Run (PR) resource, which is its parent resource in the resource hierarchy. As a result of performing operation 516, the Job Run resource 502 receives endpoint information that identifies the resource at the next level in the resource hierarchy (i.e., the Pipeline Run resource). In operation 518, the Job Run resource sends a request containing its RPT to the Identity Management System (IDM) 510 to obtain a resource principal session token (RPST) to assert its resource principal identity. As a result of performing operation 518, IDM 510 exchanges the Job Run resource's RPT for its RPST. As mentioned above, the resource's RPST is a temporary session token and secure credentials that allows the resource to authenticate itself to other cloud resources owned by the CSP (assert its own resource principal identity). The identity management system 510 shown in Figure 5 can be implemented in a similar manner to the identity management systems described in Figures 3 and 1.

[0055] In operation 520, the identity management system 510 sends the RPST to the Job Run resource. In operation 522, the Job Run resource uses the RPST obtained in operation 520 to invoke the endpoint of the next level resource in the resource hierarchy (Pipeline Run resource). In operation 524, the control plane (CP PR 506) of the Pipeline Run resource that received the invoke validates the request and, after validation, returns the RPT of the Pipeline Run resource and the endpoint information of the next level resource in the resource hierarchy (if any). In the example shown in Figure 5, the control plane 506 of the Pipeline Run resource identifies the ML application / ML resource as the next level resource in the resource hierarchy and returns the RPT of the Pipeline Run resource and the endpoint information of the ML application to the Job Run resource. In operation 526, the Job Run resource sends a request containing the RPT of the Pipeline Run resource to the identity management system (IDM) 310 to obtain the Resource Principal Session Token (RPST) of the Pipeline Run resource. As a result of executing operation 526, IDM510 exchanges the RPT of the Pipeline Run resource for its RPST, and in operation 528, IDM510 sends the RPST of the Pipeline Run resource to the Job Run resource.

[0056] In operation 530, the Job Run resource uses the Pipeline Run resource's RPT to call the endpoint of the next level resource in the resource hierarchy (i.e., the ML application) and obtains the ML application's RPT. In operation 532, the ML application's control plane 508 validates the request and, after validation, issues the ML application's RPT. In operation 534, the Job Run resource requests the ML application's RPST from the identity management system, and in operation 536, the Job Run resource obtains the ML application's RPST from the identity management system 510. The Job Run resource obtains resource RPTs until it reaches the root level of the resource hierarchy (in this example, the ML application instance).

[0057] As a result of performing operation 538, the Job Run resource has three RSPTs: a first RPST representing its own identity, a second RPST representing the identity of its parent resource (Pipeline Run resource), and a third RPST representing the identity of its grandparent resource (ML application). The third RPST represents the identity of the top-level (root) resource in the resource hierarchy (i.e., the ML application), and since the ML application resides in the customer tenancy, nested lower-level resources such as the Job Run resource can assert their resource principal identity using the ML application resource's RPST when performing various operations, such as accessing customer-owned resources (object store) 512. Customer-owned resources recognize that the Job Run resource is associated with an RPST containing tenancy information and service identifiers belonging to the customer tenancy, enabling the Job Run resource to access customer-owned resources without making cross-tenancy calls.

[0058] Figure 6 shows an example of a process 600 executed by a nested resource principal management system and identity management system in the computing environment shown in Figure 1, according to one embodiment. The process shown in Figure 6 can be performed by software (e.g., code, instructions, programs), hardware, or a combination thereof, executed by one or more processing units (e.g., processors, cores) of each system. The software may be stored in a non-temporary storage medium (e.g., a memory device). The process 600 shown in Figure 6 and described below is illustrative and intended to be non-limiting. Figure 6 shows various processing steps occurring in a particular sequence or order, but this is not intended to be limiting. In some alternative embodiments, the steps may be executed in a different order, or some steps may be executed in parallel. In some embodiments, such as the embodiment described in Figure 1, the process shown in Figure 6 may be executed by one or more subsystems (e.g., 114 and 116) shown in Figure 1.

[0059] In block 602, processing begins when the nested resource principal management system retrieves the first identity associated with the first resource residing in the first tenancy of the CSP. In one example, the first resource might represent a nested sub-resource residing in the CSP's service tenancy, which is part of a higher-level resource (the second resource) residing in the customer tenancy. For example, as shown in Figure 2, the higher-level resource (the second resource) might represent an FA resource, and the sub-resource (the first resource) might represent a database resource configured within the FA resource. The first identity associated with the first resource may correspond to a resource principal token (RPT) associated with the first resource. As mentioned earlier, an RPT is a secure identity provided to a cloud infrastructure resource, enabling that resource to receive authorization to access other cloud infrastructure resources.

[0060] In one embodiment, the nested resource principal management system retrieves the RPT of the first resource from the control plane associated with the resource, as described in relation to Figures 2 and 3. In one embodiment, as part of the processing performed in step 602, the nested resource principal management system also retrieves information identifying a second resource. This information identifies the endpoint of the second resource and may represent the URL of the resource endpoint of the second resource.

[0061] In block 604, the identity management system obtains the first token for the first resource using the first identity obtained in block 602. The first token enables the first resource to assert its first identity. The first token corresponds to the Resource Principal Session Token (RPST) associated with the first resource. As discussed above, the resource's RPST is a temporary session token and secure credentials that enables the resource to authenticate itself to other cloud resources owned by the CSP (assert its own resource principal identity).

[0062] In block 606, the nested resource principal management system obtains a second identity associated with a second resource residing in the service tenancy. This second identity can correspond to a resource principal identity (RPT) associated with the second resource, which can be obtained by the nested resource principal management system from the control plane associated with the second resource, as described in relation to Figures 2 and 3.

[0063] In block 608, the identity management system uses the second identity to obtain a second token for the first resource. The second token enables the first resource to claim the second identity. In one embodiment, the second token corresponds to a Resource Principal Session Token (RPST) associated with the second resource.

[0064] In block 610, the first resource uses the second token to access a customer-owned resource residing in the customer tenancy. The customer-owned resource recognizes that the first resource has an RPST associated with the second resource, which has a service identifier and tenancy information within the customer tenancy, enabling the first resource to access the customer-owned resource without making a cross-tenancy call.

[0065] The disclosed system enables customers to write robust and simple access control policies that provide streamlined and secure access management of cloud resources. Using the functionality provided by the disclosed system, customers only need to write a single policy for the higher-level resources they own within their customer tenancy. Because customers do not need to write policies for sub-resources configured within the higher-level resources, they do not need to expose sub-resource details (e.g., resource principal identity) to the customer. In addition, changes can be made to sub-resources configured within the higher-level resources (e.g., adding new resources, changing the resource hierarchy, deleting resources) without affecting the customer or compromising the security of the resources.

[0066] As mentioned above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, the IaaS provider can also supply a variety of services associated with these infrastructure components (e.g., billing, monitoring, logging, load balancing, and clustering, etc.). Therefore, since these services can be policy-driven, IaaS users may be able to implement policies that promote load balancing to maintain application availability and performance.

[0067] In some cases, IaaS customers can access resources and services through a wide area network (WAN), such as the internet, and install the remaining elements of their application stack using the cloud provider's services. For example, a user can log into the IaaS platform and create virtual machines (VMs), install operating systems (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on those VMs. The customer can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0068] In most cases, the cloud computing model requires the participation of a cloud provider. A cloud provider may, but does not have to be, a third-party service specializing in providing IaaS (e.g., granting, leasing, or selling). An entity could also choose to deploy a private cloud and become its own provider of infrastructure services.

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

[0070] In some cases, IaaS provisioning may refer to acquiring the computers or virtual hosts to be used, and even installing the necessary libraries or services for them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0071] In some cases, IaaS provisioning presents two distinct challenges. Firstly, there is the initial challenge of provisioning an initial set of infrastructure before anything is executed. Secondly, there is the challenge of evolving the existing infrastructure after everything has been provisioned (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges can be addressed by enabling the declarative definition of infrastructure configuration. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which and how each resource works together) can be described declaratively. In some cases, once the topology is defined, it is possible to generate workflows that create and / or manage the various components described in the configuration files.

[0072] In some examples, infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as core networks (e.g., potential on-demand pools of configurable and / or shared computing resources). In some examples, there may also be one or more inbound / outbound traffic group rules provisioned to define how inbound and / or outbound network traffic is configured, as well as one or more virtual machines (VMs). Other infrastructure elements such as load balancers and databases may also be provisioned. Infrastructure can evolve incrementally as more infrastructure elements are desired and / or added.

[0073] In some cases, sequential deployment techniques can be employed to enable the deployment of infrastructure code across various virtual computing environments. In addition, the techniques described can enable infrastructure management within these environments. In some cases, a service team may write code that is desirable to be deployed to one or more, but often numerous, different generation environments (e.g., geographically diverse locations, sometimes even worldwide). However, in some cases, the infrastructure to which the code is deployed must be configured first. In some cases, provisioning can be performed manually, resources can be provisioned using provisioning tools, and / or code can be deployed using deployment tools after the infrastructure has been provisioned.

[0074] Figure 7 is a block diagram 700 showing an exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 702 can be communicatively coupled to a secure host tenancy 704 which may include a virtual cloud network (VCN) 706 and a secure host subnet 708. In some examples, the service operator 702 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google® Glass head-mounted display) that run software such as Microsoft Windows Mobile® and / or a wide range of mobile operating systems such as iOS®, Windows Phone, Android, BlackBerry 8, Palm OS, and are capable of using the Internet, email, short message service (SMS), BlackBerry®, or other communication protocols. Alternatively, the client computing device may be a general-purpose personal computer, including, for example, personal computers and / or laptop computers running various versions of the Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. The client computing device may also be a workstation computer running any of the wide range of commercially available UNIX® or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin client computer that can communicate via a network that can access the VCN706 and / or the Internet, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect® gesture input device), and / or a personal messaging device.

[0075] VCN706 may include an LPG710 that can communicately connect to SSH VCN712 via a local peering gateway (LPG) 710 included in Secure Shell (SSH) VCN712. SSH VCN712 may include an SSH subnet 714, and SSH VCN712 can communicately connect to control plane VCN716 via an LPG710 included in control plane VCN716. Furthermore, SSH VCN712 can communicately connect to data plane VCN718 via an LPG710. Control plane VCN716 and data plane VCN718 may be included in a service tenancy 719 that can be owned and / or operated by an IaaS provider.

[0076] The control plane VCN 716 may include a control plane demilitarized zone (DMZ) layer 720 that operates as a perimeter network (e.g., part of the corporate network between the corporate intranet and the external network). DMZ-based servers can help limit liability and keep breaches contained. In addition, the DMZ layer 720 may include a control plane application layer 724 that may include one or more load balancer (LB) subnets 722, an application subnet 726, and a control plane data layer 728 that may include a database (DB) subnet 730 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 722 included in the control plane DMZ layer 720 can be communicatively coupled to the application subnet 726 included in the control plane application layer 724 and an internet gateway 734 that may be included in the control plane VCN 716, and the application subnet 726 can be communicatively coupled to the DB subnet 730, a service gateway 736, and a network address translation (NAT) gateway 738 included in the control plane data layer 728. The control plane VCN716 may include a service gateway 736 and a NAT gateway 738.

[0077] The control plane VCN 716 may include a data plane mirror application layer 740 which may include an application subnet 726. The application subnet 726 included in the data plane mirror application layer 740 may include a virtual network interface controller (VNIC) 742 which can run compute instance 744. Compute instance 744 can communicatively connect the application subnet 726 of the data plane mirror application layer 740 to the application subnet 726 which may be included in the data plane application layer 746.

[0078] The data plane VCN718 may include a data plane application layer 746, a data plane DMZ layer 748, and a data plane data layer 750. The data plane DMZ layer 748 may include an LB subnet 722 that can be communicatively coupled to the application subnet 726 of the data plane application layer 746 and the internet gateway 734 of the data plane VCN718. The application subnet 726 can be communicatively coupled to the service gateway 736 of the data plane VCN718 and the NAT gateway 738 of the data plane VCN718. The data plane data layer 750 may also include a DB subnet 730 that can be communicatively coupled to the application subnet 726 of the data plane application layer 746.

[0079] The Internet gateway 734 of the control plane VCN716 and data plane VCN718 can communicately connect to a metadata management service 752, which can communicately connect to the public internet 754. The public internet 754 can communicately connect to the NAT gateway 738 of the control plane VCN716 and data plane VCN718. The service gateway 736 of the control plane VCN716 and data plane VCN718 can communicately connect to a cloud service 756.

[0080] In some examples, the service gateway 736 of the control plane VCN716 and data plane VCN718 can make application programming interface (API) calls to the cloud service 756 without going through the public internet 754. API calls from the service gateway 736 to the cloud service 756 can be unidirectional. The service gateway 736 can make API calls to the cloud service 756, and the cloud service 756 can send the requested data to the service gateway 736. However, the cloud service 756 may not initiate an API call to the service gateway 736.

[0081] In some examples, secure host tenancy 704 can connect directly to service tenancy 719, or otherwise be isolated. Secure host subnet 708 can communicate with SSH subnet 714 via LPG 710, which can enable bidirectional communication through a system that would otherwise be isolated. By connecting secure host subnet 708 to SSH subnet 714, secure host subnet 708 becomes accessible to other entities within service tenancy 719.

[0082] The control plane VCN716 can enable users of the service tenancy 719 to configure or otherwise provision desired resources. Desired resources provisioned in the control plane VCN716 can be deployed or otherwise used in the data plane VCN718. In some examples, the control plane VCN716 can be isolated from the data plane VCN718, and the data plane mirror application layer 740 of the control plane VCN716 can communicate with the data plane application layer 746 of the data plane VCN718 via a VNIC 742 which may be included in the data plane mirror application layer 740 and the data plane application layer 746.

[0083] In some cases, a user or customer of the system can make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet 754, and the public internet 754 can communicate the request to the metadata management service 752. The metadata management service 752 can communicate the request to the control plane VCN 716 through the internet gateway 734. The request can be received by the LB subnet 722, which is included in the control plane DMZ layer 720. The LB subnet 722 can determine that the request is valid, and in response to this determination, the LB subnet 722 can send the request to the application subnet 726, which is included in the control plane application layer 724. If the request is validated and a call to the public internet 754 is required, the call to the public internet 754 can be sent to the NAT gateway 738, which can make the call to the public internet 754. Metadata that may be desirable to remember by the request can be stored in the DB subnet 730.

[0084] In some cases, the data plane mirror application layer 740 can facilitate direct communication between the control plane VCN716 and the data plane VCN718. For example, it may be desirable that configuration changes, updates, or other appropriate modifications be applied to resources contained in the data plane VCN718. The control plane VCN716 can perform configuration changes, updates, or other appropriate modifications to resources by communicating directly with the resources contained in the data plane VCN718 via VNIC742.

[0085] In some embodiments, the control plane VCN716 and data plane VCN718 can be included in the service tenancy 719. In this case, the system user or customer does not have to own or operate either the control plane VCN716 or the data plane VCN718. Alternatively, the IaaS provider may own the control plane VCN716 and the data plane VCN718, or operate them, and may include both in the service tenancy 719. This embodiment can enable network isolation that can prevent a user or customer from interacting with resources of other users or other customers. This embodiment can also enable the system user or customer to store databases privately without having to rely on the public internet 754, which may not have the desired level of threat prevention for storage.

[0086] In another embodiment, the LB subnet 722 included in the control plane VCN 716 can be configured to receive signals from the service gateway 736. In this embodiment, the control plane VCN 716 and the data plane VCN 718 can be configured to be invoked by the IaaS provider's customer without calling the public internet 754. The IaaS provider's customer may prefer this embodiment because the database used by the customer can be controlled by the IaaS provider and stored in a service tenancy 719 that can be isolated from the public internet 754.

[0087] Figure 8 is a block diagram 800 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 802 (e.g., service operator 702 in Figure 7) can communicately connect to a secure host tenancy 804 (e.g., secure host tenancy 704 in Figure 7), which may include a virtual cloud network (VCN) 806 (e.g., VCN706 in Figure 7) and a secure host subnet 808 (e.g., secure host subnet 708 in Figure 7). VCN806 may include an LPG810 (e.g., LPG710 in Figure 7), which can communicately connect to the SSH VCN812 via a local peering gateway (LPG) 710 included in the Secure Shell (SSH) VCN812 (e.g., SSH VCN712 in Figure 7). SSH VCN812 may include SSH subnet 814 (e.g., SSH subnet 714 in Figure 7), and SSH VCN812 may be communicably coupled to control plane VCN816 (e.g., control plane VCN716 in Figure 7) via LPG810 included in control plane VCN816. Control plane VCN816 may be included in service tenancy 819 (e.g., service tenancy 719 in Figure 7), and data plane VCN818 (e.g., data plane VCN718 in Figure 7) may be included in customer tenancy 821, which may be owned or operated by a user or customer of the system.

[0088] The control plane VCN816 may include a control plane DMZ layer 820 (e.g., control plane DMZ layer 720 in Figure 7) which may include an LB subnet 822 (e.g., LB subnet 722 in Figure 7), a control plane application layer 824 (e.g., control plane application layer 724 in Figure 7) which may include an application subnet 826 (e.g., application subnet 726 in Figure 7), and a control plane data layer 828 (e.g., control plane data layer 728 in Figure 7) which may include a database (DB) subnet 830 (e.g., similar to DB subnet 730 in Figure 7). The LB subnet 822 included in the control plane DMZ layer 820 can be communicatively coupled to the application subnet 826 included in the control plane application layer 824 and to an internet gateway 834 (e.g., internet gateway 734 in Figure 7) which can be included in the control plane VCN 816. The application subnet 826 can be communicatively coupled to the DB subnet 830 included in the control plane data layer 828, a service gateway 836 (e.g., service gateway 736 in Figure 7), and a network address translation (NAT) gateway 838 (e.g., NAT gateway 738 in Figure 7). The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0089] The control plane VCN 816 may include a data plane mirror application layer 840 (e.g., the data plane mirror application layer 740 in Figure 7) which may include an application subnet 826. The application subnet 826 included in the data plane mirror application layer 840 may include a virtual network interface controller (VNIC) 842 (e.g., VNIC 742) capable of running a compute instance 844 (e.g., similar to compute instance 744 in Figure 7). The compute instance 844 can facilitate communication between the application subnet 826 of the data plane mirror application layer 840 and the application subnet 826 that can be included in the data plane application layer 846 via the VNIC 842 included in the data plane mirror application layer 840 and the VNIC 842 included in the data plane application layer 846 (e.g., the data plane application layer 746 in Figure 7).

[0090] The Internet gateway 834 included in the control plane VCN816 can communicate with a metadata management service 852 (e.g., metadata management service 752 in Figure 7), which can communicate with the public internet 854 (e.g., public internet 754 in Figure 7). The public internet 854 can communicate with a NAT gateway 838 included in the control plane VCN816. The service gateway 836 included in the control plane VCN816 can communicate with a cloud service 856 (e.g., cloud service 756 in Figure 7).

[0091] In some examples, the data plane VCN818 can be included in a customer tenancy 821. In this case, the IaaS provider can provide a control plane VCN816 per customer, and the IaaS provider can configure a unique compute instance 844 included in a service tenancy 819 for each customer. Each compute instance 844 can enable communication between the control plane VCN816 included in the service tenancy 819 and the data plane VCN818 included in the customer tenancy 821. The compute instance 844 can enable resources provisioned in the control plane VCN816 included in the service tenancy 819 to be deployed or otherwise used in the data plane VCN818 included in the customer tenancy 821.

[0092] In another example, an IaaS provider's customer may have a database residing in customer tenancy 821. In this example, control plane VCN 816 may include a data plane mirror app layer 840, which may include app subnet 826. The data plane mirror app layer 840 may reside in data plane VCN 818, but may not reside in data plane VCN 818. That is, the data plane mirror app layer 840 may have access to customer tenancy 821, but may not reside in data plane VCN 818, nor may it be owned or operated by the IaaS provider's customer. The data plane mirror app layer 840 may be configured to make calls to data plane VCN 818, but may not be configured to make calls to any entities included in control plane VCN 816. The customer may want to deploy or otherwise use resources in data plane VCN 818 that are provisioned in control plane VCN 816, and the data plane mirror app layer 840 can facilitate the deployment or other use of the resources desired by the customer.

[0093] In some embodiments, a customer of the IaaS provider can apply filters to the data plane VCN818. In this embodiment, the customer can determine what the data plane VCN818 can access and can restrict access from the data plane VCN818 to the public internet 854. The IaaS provider may not be able to apply filters or otherwise control the data plane VCN818's access to any external network or database. The application of filters and controls by the customer to the data plane VCN818 included in the customer tenancy 821 can help isolate the data plane VCN818 from other customers and the public internet 854.

[0094] In some embodiments, the cloud service 856 can access services that may not exist on the public internet 854, the control plane VCN 816, or the data plane VCN 818 via a call from the service gateway 836. The connection between the cloud service 856 and the control plane VCN 816 or the data plane VCN 818 may not be live or continuous. The cloud service 856 may reside on different networks owned or operated by the IaaS provider. The cloud service 856 may be configured to receive calls from the service gateway 836 and not to receive calls from the public internet 854. Some cloud services 856 may be isolated from other cloud services 856, and the control plane VCN 816 may be isolated from cloud services 856 that may not be in the same region as the control plane VCN 816. For example, the control plane VCN 816 may be located in "Region 1", and the cloud service "Deployment 7" may be located in Region 1 and "Region 2". If a call to deployment 7 is made by a service gateway 836 included in the control plane VCN816 located in region 1, the call can be sent to deployment 7 in region 1. In this example, the control plane VCN816 or deployment 7 in region 1 does not have to be communicatively coupled to deployment 7 in region 2, nor does it have to communicate with deployment 7 in region 2 in any other way.

[0095] Figure 9 is a block diagram 900 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 902 (e.g., service operator 702 in Figure 7) can be communicatively coupled to a secure host tenancy 904 (e.g., secure host tenancy 704 in Figure 7), which may include a virtual cloud network (VCN) 906 (e.g., VCN706 in Figure 7) and a secure host subnet 908 (e.g., secure host subnet 708 in Figure 7). VCN906 may include an LPG910 (e.g., LPG710 in Figure 7) which is contained in an SSH VCN912 (e.g., SSH VCN712 in Figure 7). SSH VCN912 may include SSH subnet 914 (e.g., SSH subnet 714 in Figure 7), and SSH VCN912 may be communicatively coupled to control plane VCN916 (e.g., control plane VCN716 in Figure 7) via LPG910 included in control plane VCN916, and may be communicatively coupled to data plane VCN918 (e.g., data plane VCN718 in Figure 7) via LPG910 included in data plane VCN918. Control plane VCN916 and data plane VCN918 may be included in service tenancy 919 (e.g., service tenancy 719 in Figure 7).

[0096] The control plane VCN916 may include a control plane DMZ layer 920 (e.g., control plane DMZ layer 720 in Figure 7) which may include a load balancer (LB) subnet 922 (e.g., LB subnet 722 in Figure 7), a control plane application layer 924 (e.g., control plane application layer 724 in Figure 7) which may include an application subnet 926 (e.g., similar to application subnet 726 in Figure 7), and a control plane data layer 928 (e.g., control plane data layer 728 in Figure 7) which may include a DB subnet 930. The LB subnet 922 included in the control plane DMZ layer 920 can be communicatively coupled to the application subnet 926 included in the control plane application layer 924 and to an internet gateway 934 (e.g., internet gateway 734 in Figure 7) which can be included in the control plane VCN 916. The application subnet 926 can be communicatively coupled to the DB subnet 930 included in the control plane data layer 928, a service gateway 936 (e.g., service gateway in Figure 7), and a network address translation (NAT) gateway 938 (e.g., NAT gateway 738 in Figure 7). The control plane VCN 916 may include the service gateway 936 and the NAT gateway 938.

[0097] The data plane VCN918 may include a data plane application layer 946 (e.g., data plane application layer 746 in Figure 7), a data plane DMZ layer 948 (e.g., data plane DMZ layer 748 in Figure 7), and a data plane data layer 950 (e.g., data plane data layer 750 in Figure 7). The data plane DMZ layer 948 may include an LB subnet 922 that can be communicatively coupled to the trusted application subnet 960 and the untrusted application subnet 962 of the data plane application layer 946, as well as the internet gateway 934 included in the data plane VCN918. The trusted application subnet 960 can be communicatively coupled to the service gateway 936 included in the data plane VCN918, the NAT gateway 938 included in the data plane VCN918, and the DB subnet 930 included in the data plane data layer 950. The untrusted application subnet 962 can be communicatively coupled to the service gateway 936 included in the data plane VCN918, and the DB subnet 930 included in the data plane data layer 950. The data plane data layer 950 may include a DB subnet 930 that can be communicatively coupled to a service gateway 936 included in the data plane VCN 918.

[0098] The untrusted application subnet 962 may include one or more primary VNICs 964(1)-(N) that can be communicatively connected to tenant virtual machines (VMs) 966(1)-(N). Tenant VMs 966(1)-(N) can be communicatively connected to each application subnet 967(1)-(N) that can be included in each container output VCN 968(1)-(N) that can be included in each customer tenancy 970(1)-(N). Each secondary VNIC 972(1)-(N) can facilitate communication between the untrusted application subnet 962 included in the data plane VCN 918 and the application subnets included in the container output VCN 968(1)-(N). Each container output VCN 968(1)-(N) may include a NAT gateway 938 that can be communicatively connected to the public internet 954 (e.g., public internet 754 in Figure 7).

[0099] The Internet gateway 934 included in the control plane VCN916 and data plane VCN918 can be communicatively connected to a metadata management service 952 (e.g., the metadata management system 752 in Figure 7), which can be communicatively connected to the public internet 954. The public internet 954 can be communicatively connected to the NAT gateway 938 included in the control plane VCN916 and data plane VCN918. The service gateway 936 included in the control plane VCN916 and data plane VCN918 can be communicatively connected to a cloud service 956.

[0100] In some embodiments, the data plane VCN918 can be integrated with the customer tenancy 970. This integration may be useful or desirable for the IaaS provider's customers, for example, if they may want support for executing code. The customer may provide code to be executed, which may be destructive, communicate with other customer resources, or have undesirable effects. In response, the IaaS provider can decide whether or not to execute the code provided to the IaaS provider by the customer.

[0101] In some examples, an IaaS provider's customer may request that temporary network access to the IaaS provider be granted and that functionality be added to the data plane application layer 946. The code that performs this functionality may run in VMs 966(1)-(N) and may not be configured to run elsewhere on the data plane VCN 918. Each VM 966(1)-(N) may be connected to one customer tenancy 970. Each container 971(1)-(N) contained within VMs 966(1)-(N) may be configured to run the code. In this case, a double isolation may exist (for example, the container 971(1)-(N) that runs the code may be contained in at least one VM 966(1)-(N) that is in the non-trusted application subnet 962), which can help prevent damage to the IaaS provider's network or the networks of different customers by incorrect or otherwise undesirable code. Containers 971(1)-(N) can be communicatively coupled to customer tenancy 970 and can be configured to send or receive data to or from customer tenancy 970. Containers 971(1)-(N) do not need to be configured to send or receive data to or from any other entities in the data plane VCN918. Upon completion of code execution, the IaaS provider may disable or otherwise discard containers 971(1)-(N).

[0102] In some embodiments, the trusted application subnet 960 can execute code that may be owned or operated by the IaaS provider. In this embodiment, the trusted application subnet 960 can be communicatively coupled to the DB subnet 930 and configured to perform CRUD operations in the DB subnet 930. The non-trusted application subnet 962 can be communicatively coupled to the DB subnet 930, but in this embodiment, the non-trusted application subnet can be configured to perform read operations in the DB subnet 930. Containers 971(1)~(N), which may be included in each customer's VM966(1)~(N) and can execute code from the customer, do not need to be communicatively coupled to the DB subnet 930.

[0103] In other embodiments, the control plane VCN916 and the data plane VCN918 do not have to be directly communicatively coupled. In this embodiment, direct communication between the control plane VCN916 and the data plane VCN918 is not required. However, communication can be performed indirectly by at least one method. An LPG910 can be established by the IaaS provider to facilitate communication between the control plane VCN916 and the data plane VCN918. In another example, the control plane VCN916 or the data plane VCN918 can make a call to a cloud service 956 via a service gateway 936. For example, a call from the control plane VCN916 to the cloud service 956 may include a request for a service that can communicate with the data plane VCN918.

[0104] Figure 10 is a block diagram 1000 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1002 (e.g., service operator 702 in Figure 7) can be communicatively coupled to a secure host tenancy 1004 (e.g., secure host tenancy 704 in Figure 7), which may include a virtual cloud network (VCN) 1006 (e.g., VCN 706 in Figure 7) and a secure host subnet 1008 (e.g., secure host subnet 708 in Figure 7). VCN 1006 may include an LPG 1010 (e.g., LPG 710 in Figure 7), which can be communicatively coupled to SSH VCN 1012 (e.g., SSH VCN 712 in Figure 7) via an LPG 1010 (e.g., LPG 710 in Figure 7). SSH VCN1012 may include SSH subnet 1014 (e.g., SSH subnet 714 in Figure 7), and SSH VCN1012 may be communicatively coupled to control plane VCN1016 (e.g., control plane VCN716 in Figure 7) via LPG1010 included in control plane VCN1016, and may be communicatively coupled to data plane VCN1018 (e.g., data plane VCN718 in Figure 7) via LPG1010 included in data plane VCN1018. Control plane VCN1016 and data plane VCN1018 may be included in service tenancy 1019 (e.g., service tenancy 719 in Figure 7).

[0105] The control plane VCN1016 may include a control plane DMZ layer 1020 (e.g., control plane DMZ layer 720 in Figure 7) which may include an LB subnet 1022 (e.g., LB subnet 722 in Figure 7), a control plane application layer 1024 (e.g., control plane application layer 724 in Figure 7) which may include an application subnet 1026 (e.g., application subnet 726 in Figure 7), and a control plane data layer 1028 (e.g., control plane data layer 728 in Figure 7) which may include a DB subnet 1030 (e.g., DB subnet 930 in Figure 9). The LB subnet 1022 included in the control plane DMZ layer 1020 can be communicatively coupled to the application subnet 1026 included in the control plane application layer 1024 and to the internet gateway 1034 (e.g., internet gateway 734 in Figure 7), which can be included in the control plane VCN 1016. The application subnet 1026 can be communicatively coupled to the DB subnet 1030 included in the control plane data layer 1028, the service gateway 1036 (e.g., the service gateway in Figure 7), and the network address translation (NAT) gateway 1038 (e.g., NAT gateway 738 in Figure 7). The control plane VCN 1016 may include the service gateway 1036 and the NAT gateway 1038.

[0106] The data plane VCN 1018 may include a data plane application layer 1046 (e.g., data plane application layer 746 in Figure 7), a data plane DMZ layer 1048 (e.g., data plane DMZ layer 748 in Figure 7), and a data plane data layer 1050 (e.g., data plane data layer 750 in Figure 7). The data plane DMZ layer 1048 may include a trusted application subnet 1060 (e.g., trusted application subnet 960 in Figure 9) and an untrusted application subnet 1062 (e.g., untrusted application subnet 962 in Figure 9) of the data plane application layer 1046, as well as an LB subnet 1022 that can be communicatively coupled to an internet gateway 1034 included in the data plane VCN 1018. Trusted application subnet 1060 can be communicatively connected to service gateway 1036 included in data plane VCN 1018, NAT gateway 1038 included in data plane VCN 1018, and DB subnet 1030 included in data plane data layer 1050. Non-trusted application subnet 1062 can be communicatively connected to service gateway 1036 included in data plane VCN 1018, and DB subnet 1030 included in data plane data layer 1050. Data plane data layer 1050 may include DB subnet 1030 that can be communicatively connected to service gateway 1036 included in data plane VCN 1018.

[0107] The untrusted application subnet 1062 may include primary VNICs 1064(1) to (N) that can be communicatively connected to tenant virtual machines (VMs) 1066(1) to (N) residing within the untrusted application subnet 1062. Each tenant VM 1066(1) to (N) can execute code in its respective container 1067(1) to (N) and can be communicatively connected to an application subnet 1026 that can be included in a data plane application layer 1046 that can be included in the container output VCN 1068. Each secondary VNIC 1072(1) to (N) can facilitate communication between the untrusted application subnet 1062 included in the data plane VCN 1018 and the application subnet included in the container output VCN 1068. The container output VCN may include a NAT gateway 1038 that can be communicatively connected to the public internet 1054 (e.g., the public internet 754 in Figure 7).

[0108] The Internet gateway 1034 included in the control plane VCN1016 and data plane VCN1018 can communicately connect to a metadata management service 1052 (e.g., metadata management system 752 in the figure) which can communicately connect to the public internet 1054. The public internet 1054 can communicately connect to the NAT gateway 1038 included in the control plane VCN1016 and data plane VCN1018. The service gateway 1036 included in the control plane VCN1016 and data plane VCN1018 can communicately connect to a cloud service 1056.

[0109] In some examples, the pattern shown by the architecture of block diagram 1000 in Figure 10 can be considered an exception to the pattern shown by the architecture of block diagram 900 in Figure 9, and may be desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in an unconnected region). Each container 1067(1)~(N) contained within VM 1066(1)~(N) for each customer can be accessed by the customer in real time. Each container 1067(1)~(N) can be configured to make calls to each secondary VNIC 1072(1)~(N) contained within the application subnet 1026 of the data plane application layer 1046, which can be included in the container output VCN 1068. The secondary VNICs 1072(1)~(N) can send calls to the NAT gateway 1038, which can send calls to the public internet 1054. In this example, containers 1067(1)-(N), which can be accessed by customers in real time, can be isolated from the control plane VCN1016 and from other entities included in the data plane VCN1018. Containers 1067(1)-(N) can also be isolated from resources from other customers.

[0110] In another example, a customer can invoke cloud service 1056 using containers 1067(1)-(N). In this example, the customer can execute code in containers 1067(1)-(N) that requests a service from cloud service 1056. Containers 1067(1)-(N) can send this request to secondary VNICs 1072(1)-(N), which can send the request to the NAT gateway, which can send the request to the public internet 1054. The public internet 1054 can send this request to the LB subnet 1022 included in the control plane VCN 1016 via the internet gateway 1034. In response to determining that the request is valid, the LB subnet can send the request to the application subnet 1026, which can send the request to cloud service 1056 via the service gateway 1036.

[0111] It should be understood that the IaaS architectures 700, 800, 900, and 1000 shown in the figures may have components other than those shown. Furthermore, the embodiments shown in the figures are only some examples of cloud infrastructure systems that may incorporate one embodiment of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown, may combine two or more components, or may have different configurations or arrangements of components.

[0112] In one embodiment, the IaaS system described herein may include the provision of a set of applications, middleware, and database services delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. Oracle Cloud Infrastructure (OCI), offered by the assignee, is an example of such an IaaS system.

[0113] Figure 11 shows an exemplary computer system 1100 in which various embodiments can be implemented. Any of the above computer systems can be implemented using system 1100. As shown in the figure, computer system 1100 includes a processing unit 1104 that communicates with a number of peripheral subsystems via a bus subsystem 1102. These peripheral subsystems may include a processing acceleration unit 1106, an I / O subsystem 1108, a storage subsystem 1118, and a communication subsystem 1124. The storage subsystem 1118 includes a tangible computer-readable storage medium 1122 and system memory 1110.

[0114] The bus subsystem 1102 provides a mechanism that enables various components and subsystems of the computer system 1100 to communicate with each other as intended. Although the bus subsystem 1102 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1102 can be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using one of a wide range of bus architectures. For example, such architectures may include industry standard architecture (ISA) buses, microchannel architecture (MCA) buses, extended ISA (EISA) buses, video electronics standards (VESA) local buses, and peripheral interconnect (PCI) buses, which can be implemented as mezzanine buses manufactured according to the IEEEP1386.1 standard.

[0115] A processing unit 1104, which can be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1100. One or more processors can be included in the processing unit 1104. These processors may include single-core or multi-core processors. In one embodiment, the processing unit 1104 can be implemented as one or more independent processing units 1132 and / or 1134, each containing a single-core or multi-core processor. In another embodiment, the processing unit 1104 can also be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip.

[0116] In various embodiments, the processing unit 1104 can execute a wide range of programs in response to program code and can maintain multiple concurrently running programs or processes. At any given time, some or all of the program code to be executed may reside in the processor 1104 and / or the storage subsystem 1118. Through appropriate programming, the processor 1104 can provide the various functions described above. The computer system 1100 may further include a processing acceleration unit 1106, which may include a digital signal processor (DSP), a dedicated processor, and the like.

[0117] The I / O subsystem 1108 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include motion sensing devices and / or gesture recognition devices such as Microsoft Kinect® motion sensors that enable user control and interaction with input devices such as Microsoft Xbox® 360 game controllers through a natural user interface using gestures and voice commands. User interface input devices may also include eye gesture recognition devices such as Google Glass® blink detectors that detect the user's eye movements (e.g., blinks when taking a picture and / or selecting a menu) and translate those eye gestures into input to an input device (e.g., Google Glass®). In addition, user interface input devices may also include voice recognition sensing devices that enable users to interact with voice recognition systems (e.g., Siri® Navigator) through voice commands.

[0118] Other examples of user interface input devices, though not limited to, include three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphics tablets, and audio / visual 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-tracking devices. In addition, user interface input devices may include medical imaging input devices such as computed tomography, magnetic resonance imaging, oscillating tomography, and medical ultrasound imaging devices. User interface input devices may also include audio input devices such as MIDI keyboards and digital musical instruments.

[0119] User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. Display subsystems may also include flat panel devices such as cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, touchscreens, etc. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1100 to a user or another computer. For example, user interface output devices may include, but are not limited to, a wide range of display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems.

[0120] The computer system 1100 may include a storage subsystem 1118 containing software elements as shown in the system memory 1110. The system memory 1110 can store program instructions that are readable and executable by the processing unit 1104, as well as data generated during the execution of these programs.

[0121] Depending on the configuration and type of the computer system 1100, the system memory 1110 may be volatile (e.g., random access memory (RAM)) and / or non-volatile (e.g., read-only memory (ROM), flash memory). RAM typically contains data and / or program modules that are immediately accessible by the processing unit 1104 and / or are currently being operated on and executed. In some embodiments, the system memory 1110 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, a basic input / output system (BIOS), which includes basic routines that help transfer information between elements within the computer system 1100 during startup, etc., may be stored, typically in ROM. As an example, but not an limitation, the system memory 1110 also includes application programs 1112, program data 1114, and an operating system 1116, which may include client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), etc. For example, operating system 1116 may include Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, a wide range of commercially available UNIX® or UNIX-like operating systems (including, but not limited to, a wide range of GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems, such as a wide range of versions of iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems.

[0122] The storage subsystem 1118 can provide a tangible, computer-readable storage medium for storing basic programming and data configurations that provide the functionality of certain embodiments. Software (programs, code modules, instructions) that provides the aforementioned functionality when executed by the processor may be stored in the storage subsystem 1118. These software modules or instructions may be executed by the processing unit 1104. The storage subsystem 1118 may also provide a repository for storing data used in accordance with this disclosure.

[0123] The storage subsystem 1100 may also include a computer-readable storage medium reader 1120 which may be further connected to the computer-readable storage medium 1122. Together with the system memory 1110, and in optional combinations, the computer-readable storage medium 1122 may comprehensively represent storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information, in addition to remote, local, fixed, and / or removable storage media.

[0124] The computer-readable storage medium 1122 containing code or a portion of code may also include, but is not limited to, any suitable medium known or used in the art, including storage and communication media, such as volatile and non-volatile, removable and non-removable media, implemented in any way or technique for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or other tangible computer-readable media. The computer-readable storage medium 1122 may also include intangible computer-readable media such as data signals, data transmissions, or any other media, which can be used to transmit desired information and can be accessed by the computing system 1100.

[0125] For example, the computer-readable storage medium 1122 may include a hard disk drive that reads and writes to a non-removable non-volatile magnetic medium, a magnetic disk drive that reads and writes to a removable non-volatile magnetic disk, and an optical disk drive that reads and writes to a removable non-volatile optical disk such as a CD-ROM, DVD, Blu-ray® disc, or other optical medium. The computer-readable storage medium 1122 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, digital videotapes, etc. The computer-readable storage medium 1122 may also include SSDs based on non-volatile memory such as flash memory-based solid-state drives (SSDs), enterprise flash drives, solid-state ROMs, etc., and SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. Disk drives and their associated computer-readable media can provide non-volatile storage for computer-readable instructions, data structures, program modules, and other data for the computer system 1100.

[0126] The communication subsystem 1124 provides interfaces to other computer systems and networks. The communication subsystem 1124 functions as an interface for sending and receiving data between the computer system 1100 and other systems. For example, the communication subsystem 1124 can enable the computer system 1100 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1124 may include radio frequency (RF) transceiver components for accessing radio voice and / or data networks (e.g., the use of advanced data network technologies such as cellular technology, 3G, 4G, or EDGE (Enhanced Data Speed ​​for Global Evolution)), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), Global Positioning System (GPS) receiver components, and / or other components. In some embodiments, the communication subsystem 1124 may provide wired network connectivity (e.g., Ethernet®) in addition to, or instead of, the radio interface.

[0127] In some embodiments, the communication subsystem 1124 may also receive input communications in the form of structured and / or unstructured data feeds 1126, event streams 1128, event updates 1130, etc., on behalf of one or more users who can use the computer system 1100.

[0128] For example, the communication subsystem 1124 can be configured to receive data feeds 1126 in real time from users of social networks and / or other communication services, such as web feeds like Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0129] In addition, the communication subsystem 1124 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1128 of real-time events and / or event updates 1130, which may have no explicit termination and may be inherently continuous or unrestricted. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring.

[0130] The communication subsystem 1124 may also be configured to output structured data feeds and / or unstructured data feeds 1126, event streams 1128, event updates 1130, etc., to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 1100.

[0131] The computer system 1100 can be one of a variety of types, including handheld portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), PCs, workstations, mainframes, kiosks, server racks, or other data processing systems.

[0132] Due to the constantly changing nature of computers and networks, the description of the computer system 1100 shown in the figure is intended only as a specific example. Many other configurations are possible, having more or fewer components than the system shown in the figure. For example, customized hardware may be used, and / or certain elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Furthermore, connections to other computing devices, such as network input / output devices, may be used. Based on the disclosures and teachings provided herein, those skilled in the art will understand other ways and / or methods for carrying out various embodiments.

[0133] While specific embodiments have been described, various modifications, changes, alternative configurations, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within a specific data processing environment, but can freely operate within multiple data processing environments. Furthermore, while the embodiments have been described using a specific set of transactions and steps, those skilled in the art should understand that the scope of this disclosure is not limited to the described set of transactions and steps. Various features and aspects of the above embodiments can be used individually or in combination.

[0134] Furthermore, while embodiments have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of this disclosure. Embodiments can be implemented using hardware alone, software alone, or a combination thereof. The various processes described herein may be implemented on the same processor or on different processors in any combination. Thus, although components or modules are described as being configured to perform a certain operation, such configurations can be achieved, for example, by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or by any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or pairs of the same process may use different techniques at different times.

[0135] Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, it is clear that additions, subtractions, deletions, and other modifications and changes can be made without departing from the broader intent and scope set forth in the claims. Thus, specific embodiments of the disclosure have been described, but these are not intended to be limiting. Various modifications and equivalents are included in the following claims.

[0136] In the context describing the embodiments disclosed (particularly in the context of the subsequent claims), the terms “a, an” and “the” and similar reference subjects should be interpreted as encompassing both singular and plural, unless otherwise indicated herein and unless the context clearly contradicts the interpretation. The terms “comprising,” “having,” “including,” and “containing” should be interpreted as open-ended terms (i.e., meaning “not limited, but including”) unless otherwise specified. The term “connected” should be interpreted as being contained within, attached to, or joined to one another, in part or as a whole, even if there is an intermediary. Unless otherwise indicated herein, the enumeration of value ranges is intended merely as a way of referring individually to each distinct value within that range, and each distinct value is incorporated herein as if it were individually enumerated herein. All methods described herein may be performed in any suitable order, unless otherwise indicated herein or unless it is clearly inconsistent with the context. The use of any examples or exemplary language provided herein (e.g., "etc.") is intended solely to clarify embodiments and, unless otherwise requested, does not limit the scope of this disclosure. Nothing in this disclosure, nor any unrequested element, should be construed as indicating that it is essential to the practice of this disclosure.

[0137] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood, unless otherwise specified, in the context of its general use to indicate that an item, term, etc., may be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive language is not generally intended, nor should it be, to be interpreted as suggesting that a particular embodiment requires the presence of at least one X, at least one Y, or at least one Z.

[0138] This specification describes preferred embodiments of the Disclosure, including the best known mode for carrying out the Disclosure. Those skilled in the art will be able to see variations of these preferred embodiments by reading the foregoing description. Those skilled in the art can appropriately adopt such variations, and the Disclosure may be carried out in ways other than those specifically described herein. Therefore, the Disclosure includes all variations and equivalents of the subject matter described in the claims appended herein, as permitted by applicable law. Furthermore, unless otherwise indicated herein, any combination of the elements described above in all possible variations is incorporated herein.

[0139] All references cited herein, including publications, patent applications, and patents, are incorporated by reference to the same extent as they would be incorporated in whole herein, with each reference specifically indicated as being incorporated by reference.

[0140] While the above specification has described aspects of the disclosure with respect to specific embodiments, those skilled in the art will recognize that the disclosure is not limited thereto. The various features and aspects of the above disclosure can be used individually or in combination. Furthermore, the embodiments can be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Accordingly, the specification and drawings should be considered illustrative rather than limiting.

Claims

1. It is a method, The method includes obtaining a first identity associated with a first resource and information identifying a second resource for a first resource that exists in one of several service tenancies provided by a cloud service provider (CSP), wherein the first resource is a sub-resource of the second resource, and the method is The method further includes obtaining a first token for the first resource using the first identity, the first token enabling the first resource to claim the first identity, and the method further includes The method further includes obtaining a second identity associated with the first resource, wherein the second resource is created in a customer tenancy provided by the CSP, and the method further includes The method further includes obtaining a second token for the first resource using the second identity, the second token enabling the first resource to claim the second identity, and the method further includes A method comprising the first resource using the second token to access another resource existing in the customer tenancy.

2. The method according to claim 1, wherein the service tenancy represents a provisioning platform for provisioning, configuring, and managing a plurality of cloud resources associated with a plurality of cloud services provided by the CSP.

3. The method according to claim 1 or 2, wherein the customer tenancy represents an account created for a customer of the CSP who subscribes to one or more services provided by the CSP.

4. The method according to claim 1, claim 2, or claim 3, wherein the first identity associated with the first resource is obtained from a control plane associated with the service that owns the first resource in the service tenancy of the CSP.

5. The method according to any one of the preceding claims, wherein the first identity represents a resource principal identity associated with the first resource, which enables the first resource to be authorized to access a plurality of cloud resources provided by the CSP.

6. The method according to any one of the preceding claims, wherein the first token represents a resource principal session token associated with the first resource, and the resource principal session token represents a temporary session token and secure credentials associated with the first resource that enable the first resource to authenticate itself to a plurality of cloud resources provided by the CSP.

7. The method according to any one of the preceding claims, wherein the information identifying the second resource represents a uniform resource locator (URL) of a resource endpoint associated with the second resource.

8. The method according to any one of the preceding claims, wherein the second identity of the second resource is obtained using the information identifying the second resource, and the second identity represents a resource principal identity associated with the second resource that enables the second resource to be authorized to access a plurality of cloud resources provided by the CSP.

9. The method according to any one of the preceding claims, wherein the second identity of the second resource is obtained from the customer control plane associated with the second resource.

10. The method according to claim 1, wherein the second token represents a resource principal session token associated with the second resource, and the resource principal session token represents a temporary session token and secure credentials associated with the second resource that enable the second resource to authenticate itself to one or more resources provided by the CSP.

11. Memory and The system comprises one or more processors configured to perform a process, the process being: The process includes obtaining a first identity associated with a first resource and information identifying a second resource, for a first resource existing in one of several service tenancies provided by a Cloud Service Provider (CSP), wherein the first resource is a sub-resource of the second resource, and the process further includes: The process includes obtaining a first token for the first resource using the first identity, the first token enabling the first resource to claim the first identity, and the process further includes: The process includes obtaining a second identity associated with the first resource, wherein the second resource is created in a customer tenancy provided by the CSP, and the process further includes: The process includes obtaining a second token for the first resource using the second identity, the second token enabling the first resource to claim the second identity, and the process further includes: A system in which the first resource uses the second token to access another resource existing in the customer tenancy.

12. The system according to claim 11, wherein the service tenancy represents a provisioning platform for provisioning, configuring, and managing a plurality of cloud resources associated with a plurality of cloud services provided by the CSP.

13. The system according to claim 11 or 12, wherein the customer tenancy represents an account created for a customer of the CSP who subscribes to one or more services provided by the CSP.

14. The system according to claim 11, 12, or 13, wherein the first identity represents a resource principal identity associated with the first resource, which enables the first resource to be authorized to access a plurality of cloud resources provided by the CSP.

15. The system according to any one of claims 11 to 15, wherein the first token represents a resource principal session token associated with the first resource, and the resource principal session token represents a temporary session token and secure credentials associated with the first resource that enable the first resource to authenticate itself to a plurality of cloud resources provided by the CSP.

16. The system according to claim 11, wherein the information identifying the second resource represents a uniform resource locator (URL) of a resource endpoint associated with the second resource.

17. A non-temporary computer-readable medium for storing instructions that can be executed by a computer system, wherein, when an instruction is executed by one or more processors of the computer system, it causes the one or more processors to perform an operation, and the operation is The operation includes obtaining a first identity associated with a first resource and information identifying a second resource, for a first resource existing in one of several service tenancies provided by a cloud service provider (CSP), wherein the first resource is a sub-resource of the second resource, and the operation further includes: The operation includes obtaining a first token for the first resource using the first identity, the first token enabling the first resource to claim the first identity, and the operation further includes, The operation further includes obtaining a second identity associated with the first resource, wherein the second resource is created in a customer tenancy provided by the CSP, and the operation further includes: This includes obtaining a second token for the first resource using the second identity, the second token enabling the first resource to claim the second identity, and the operation further includes, A non-temporary computer-readable medium in which the first resource uses the second token to access another resource existing in the customer tenancy.

18. The non-temporary computer-readable medium according to claim 17, wherein the first identity represents a resource principal identity associated with the first resource, enabling the first resource to be authorized to access a plurality of cloud resources provided by the CSP.

19. The non-temporary computer-readable medium according to claim 17, wherein the service tenancy represents a provisioning platform for provisioning, configuring, and managing a plurality of cloud resources associated with a plurality of cloud services provided by the CSP.

20. The non-temporary computer-readable medium according to claim 17, claim 18, or claim 19, wherein the customer tenancy represents an account created for a customer of the CSP who subscribes to one or more services provided by the CSP.

21. A computer program product that includes computer program instructions, wherein when the computer program instructions are executed by a processor, the processor... For a first resource existing in one of several service tenancies provided by a Cloud Service Provider (CSP), the first resource is a sub-resource of the second resource, and the computer program instruction further causes the processor to obtain the first identity associated with the first resource and information identifying the second resource, the first resource is a sub-resource of the second resource, and the computer program instruction further causes the processor to Using the first identity, a first token is obtained for the first resource, the first token enables the first resource to claim the first identity, and the computer program instruction further causes the processor to With respect to the first resource, a second identity associated with the second resource is obtained, the second resource is created in a customer tenancy provided by the CSP, and the computer program instructions are further transmitted to the processor. Using the second identity, a second token is obtained for the first resource, the second token enables the first resource to claim the second identity, and the computer program instruction further causes the processor to A computer program product that causes the first resource to use the second token to access another resource existing in the customer tenancy.

Images