Nested resource identity management of cloud resources

Abstract

A system is disclosed that includes the ability to enable nested sub-resources residing in a service lease to access resources owned by a customer residing in a customer lease without using a cross-lease policy. The disclosed system provides the ability to cause nested sub-resources residing in a service lease to obtain a resource subject identity of a higher level resource residing in a customer lease and use the identity of the higher level resource to access resources owned by a customer residing in the customer lease. Using the resource subject identity of its higher level of resource, the sub-resource can access the customer owned resource residing in the customer lease in a seamless manner without writing a cross-lease policy statement that provides permission to the sub-resource to access the customer owned resource.

Description

[0001] This application is a PCT application filed on September 27, 2023, entitled “Nested Resource Identity Management for Cloud Resources”, and claims its interest and priority under 35 U.S.SC 119(e), the contents of which are incorporated herein by reference in their entirety for all purposes.

[0002] This application also claims the benefit and priority of Indian Provisional Application No. 202341062291 entitled “Nested Resource Identity Management for Cloud Resources”, filed on September 15, 2023, the contents of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] This disclosure generally relates to secure access to cloud-based resources. More specifically, but not limitingly, this disclosure describes a nested resource principal management system that includes the ability to enable resources residing in a first lease to access customer-owned resources residing in different leases without using cross-lease policies. Background Technology

[0004] The demand for cloud-based services continues to grow rapidly. The term "cloud service" is generally used to refer to services made available to users or customers on demand (e.g., via a subscription model) 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 utilize cloud services provided by the cloud service provider without purchasing separate hardware and software resources for these services. Various types of cloud services exist, including Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and others.

[0005] A customer can subscribe to one or more cloud services offered by a CSP. A customer can be any entity, such as an individual, organization, or enterprise. When a customer subscribes to or registers for a service offered by a CSP, a lease or account is created for that customer. The customer can then access one or more subscribed cloud resources associated with that account.

[0006] To take advantage of the many benefits offered by cloud services, customers may wish to share their resources with external entities outside their own leases (e.g., CSPs or third-party leases) in some situations. To access and share resources, administrators of both leases typically need to create specific policy statements that explicitly specify which resources can be accessed and shared. In some scenarios, enabling cross-lease access and sharing of resources requires exposing internal details of the resources (e.g., resource identity) to administrators of different leases. Furthermore, writing complex cross-lease policies can be cumbersome for customers and compromise the security of cloud-based services. Summary of the Invention

[0007] This disclosure generally relates to secure access to cloud-based resources. More specifically, but not limitingly, this disclosure describes a nested resource principal management system that includes the ability to enable resources residing in a first lease to access customer-owned resources residing in different leases without using cross-lease policies.

[0008] In some embodiments, a nested resource principal management system is disclosed. This system obtains a first identity for a first resource residing in a service lease of a cloud service provider (CSP). In some examples, the first resource may represent a nested sub-resource residing in a service lease of the CSP, where the resource is part of a higher-level resource (a second resource). The second resource resides in a customer lease. The first identity associated with the first resource may correspond to a Resource Principal Identity (RPT) associated with the first resource. An 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 some examples, the system obtains the RPT of the first resource from the service control plane associated with the resource. The system additionally obtains information identifying the second resource. This information identifies the endpoints of the second resource and may represent the URL of the resource endpoints of the second resource.

[0010] The system then uses the first identity to obtain the first token for the first resource. The first token enables the first resource to assert the first identity. The first token corresponds to the Resource Principal Session Token (RPST) associated with the first resource. The RPST of a resource is a temporary session token and security credential that enables the resource to authenticate itself (assert its resource principal identity) to other cloud resources owned by the CSP.

[0011] In some embodiments, the system obtains a second identity associated with a second resource. This second identity may correspond to a Resource Principal Identity (RPT) associated with the second resource and may 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 assert the second identity. In some embodiments, the second token corresponds to a Resource Principal Session Token (RPST) associated with the second resource. In some examples, the resource then uses the second token to access customer-owned resources residing in a customer lease. Attached Figure Description

[0012] Figure 1 A simplified diagram of a computing environment 100 is depicted, which includes a nested resource principal management system that includes the ability to enable nested sub-resources residing in a service lease of a cloud service provider (CSP) to access customer-owned resources in a customer lease without cross-lease policy calls.

[0013] Figure 2 Examples of processes performed by a control plane associated with a service in a service lease to provision resources in the service lease, according to certain embodiments, are described.

[0014] Figure 3 It is a sequence diagram depicting, according to certain embodiments, a series of interactions that enable nested sub-resources residing in a service lease to access customer-owned resources residing in a customer lease.

[0015] Figure 4 A hierarchy of resources composed in a machine language (ML) application according to certain embodiments is described.

[0016] Figure 5 This is a sequence diagram illustrating a series of interactions, according to certain embodiments, that enable nested lower-level resources of an ML application residing in a service lease to access customer-owned resources residing in a customer lease.

[0017] Figure 6 The text describes a nested resource principal management system and identity management system according to certain embodiments. Figure 1 Examples of processing performed within a computing environment as depicted in the text.

[0018] Figure 7 This is a block diagram illustrating a pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0019] Figure 8 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0020] Figure 9 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0021] Figure 10 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0022] Figure 11 This is a block diagram illustrating an example computer system according to at least one embodiment. Detailed Implementation

[0023] In the following description, specific details are set forth for purposes of explanation in order to provide a thorough understanding of certain embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The accompanying drawings and description are not intended to be limiting. The word “exemplary” herein means “serving as an example, instance, or illustration.” Any embodiment or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0024] This disclosure generally relates to secure access to cloud-based resources. More specifically, but not limitingly, this disclosure describes a nested resource principal management system that includes the ability to enable resources residing in a first lease to access customer-owned resources residing in different leases without using cross-lease policies.

[0025] As previously mentioned, to successfully write cross-policy statements that enable resources to be shared across different leases, it is necessary to expose the internal details of the resources (e.g., resource identity) to administrators of the different leases. Existing methods for enabling resources residing in a first lease (e.g., a service lease) to access customer-owned resources residing in a different lease (e.g., a customer lease) traditionally involve the customer writing cross-lease policies to allow resources to successfully make cross-lease calls to customer-owned resources. This typically involves making the resource principal identity of the resources available to the customer so that the customer can successfully write cross-lease policies that grant permissions to resources residing in the service lease to access customer-owned resources. Exposing the resource principal identity of resources supplied in a different lease (e.g., a service lease) than the customer lease is not ideal and may compromise the security of cloud resources.

[0026] As described in this article, service leases and customer leases can correspond to secure and isolated partitions of the cloud infrastructure provided by a CSP for creating, organizing, and managing cloud resources. For example, a customer lease can refer to an account created for a customer of a CSP. A customer can be any entity, such as an individual, organization, or enterprise. When a customer subscribes to or registers for a service provided by a CSP, a lease or account is created for that customer, and this lease or account is called a customer lease. Different customer leases can be created for different customers of a CSP. A customer can then access one or more subscribed cloud resources associated with that customer's account through their lease. In some examples, customer leases are associated with compartments. A compartment is a logical container used to organize and control access to cloud resources (e.g., compute, storage, networking, load balancers, etc.) created within that compartment.

[0027] Service leases (also known as cloud provider leases) are leases associated with a CSP that provide a secure and isolated partition or provisioning platform for the provisioning, configuration, and management of the lifecycle of cloud resources associated with services provided by the CSP. In some implementations, different service leases can be provided for different cloud services provided by the CSP. For example, a first service lease can be provided for a first cloud service provided by the CSP (e.g., a converged application (FA) cloud service), a second service lease can 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 lease can be provided for a third cloud service provided by the CSP, and so on.

[0028] The various embodiments described in this disclosure address the shortcomings of existing methods by disclosing a nested resource principal management system that includes the ability to enable nested cloud resources residing in a first lease (e.g., a service lease) to access customer-owned resources residing in a second lease (e.g., a customer lease) without using cross-lease policies. In some embodiments, the nested cloud resource is part of a higher-level resource created in the customer lease. The internal composition of this higher-level resource is typically hidden from the customer, who treats it as a single entity (i.e., a single logical resource) within the customer lease. The actual provisioning / allocation of the infrastructure resources (i.e., sub-resources) that make up the higher-level resource is handled by the service execution unit in the service lease responsible for managing those resources.

[0029] The disclosed system provides the ability for nested sub-resources residing in a service lease to acquire the resource principal identity of a higher-level resource residing in a customer lease and use that higher-level resource identity to access customer-owned resources residing in the customer lease. A resource principal identity, also referred to throughout this disclosure as a resource principal token (RPT), is a secure identity provided to a cloud infrastructure resource that enables the resource to be authorized to access other cloud infrastructure resources. In some examples, a resource principal identity is a token signed by an authoritative service in the CSP responsible for managing the resource and providing trusted metadata about it. By acquiring the resource principal identity of a higher-level resource, a sub-resource residing in a service lease is granted the same permissions as its higher-level resource to access other customer-owned resources. Using its higher-level resource's resource principal identity, a sub-resource residing in a service lease can seamlessly access customer-owned resources residing in the customer lease using a generic policy associated with the higher-level resource that provides permission for the higher-level resource to interact with other customer-owned resources in the customer lease. The customer does not need to write separate cross-lease policy statements to grant the sub-resource permission to access customer-owned resources.

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

[0031] Now refer to the attached diagram, Figure 1A simplified diagram of a computing environment 100 according to certain embodiments is depicted. The computing environment 100 includes a nested resource principal management system that includes the ability to enable nested sub-resources residing in a service lease of a cloud service provider (CSP) to access customer-owned resources in a customer lease without cross-lease policy calls. As previously described, service leases and customer leases can correspond to secure and isolated partitions of cloud infrastructure provided by the CSP for creating, organizing, and managing cloud resources. For example, a customer lease can refer to an account created for a customer of the CSP. A customer can be any entity, such as an individual, organization, enterprise, etc. When a customer subscribes to or registers for a service provided by the CSP, a lease or account is created for that customer, and this lease or account is referred to as a customer lease. Different customer leases can be created for different customers of the CSP. The customer can then access one or more subscribed cloud resources associated with that customer's account via the customer's lease. In some examples, a customer lease is associated with a compartment. A compartment refers to a logical container used to organize and control access to cloud resources (e.g., compute, storage, network, load balancer, etc.) created within that compartment.

[0032] Service leases (also known as cloud provider leases) are leases associated with a CSP that provide a secure and isolated partition or provisioning platform for the provisioning, configuration, and management of the lifecycle of cloud resources associated with services provided by the CSP. In some implementations, different service leases can be provided for different cloud services provided by the CSP. For example, a first service lease can be provided for a first cloud service provided by the CSP (e.g., a converged application (FA) cloud service), a second service lease can 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 lease can be provided for a third cloud service provided by the CSP, and so on.

[0033] For example, for a converged application (FA) cloud service, the service lease provided for this service may include the ability to provision FA resources to the CSP's customers. FA resources can represent a type of cloud resource provided by the CSP to its customers for enterprise resource planning purposes. In some examples, the provisioning of a cloud resource (e.g., an FA resource) may involve provisioning multiple lower-level infrastructure resources, such as databases, buckets, and object repositories, that comprise the cloud resource. However, the internal composition of the cloud resource is typically hidden from the customer, who treats it as a single entity (i.e., a single logical resource). The creation of the cloud resource is typically performed by the customer within the customer lease, while the actual provisioning / allocation of the lower-level infrastructure resources (also referred to herein as sub-resources) that are part of a higher-level resource is performed by the service lease responsible for managing those resources. Once provisioned, the customer can interact with the higher-level resource (also referred to herein as the root resource) and write policies for that resource to grant it access to other resources within the customer lease (e.g., object buckets, vault secrets, etc.) and resources residing in different leases (e.g., service leases, third-party leases, etc.).

[0034] For example, such as Figure 1 As described, a customer can create resource R1 in customer lease 102. Resource R1 can consist of multiple lower-level resources (sub-resources R2 and R3). Resource R1 represents the highest-level resource (root resource), while R2 and R3 represent the child resources of resource R1. For example, as previously mentioned, resource R1 can represent a converged cluster or converged application (FA) resource that a customer can use for enterprise resource planning purposes. This resource (R1) can consist of multiple sub-resources R2 and R3 (e.g., databases, buckets, and keys). Figure 1 In the example depicted, the child resources R2 and R3 of resource R1 are also related in the hierarchy, where R3 is a child resource of its parent resource R2.

[0035] The internal components of resource R1 (e.g., R2 and R3) are typically hidden from the customer, who treats resource R1 as a single entity (i.e., a single logical resource) within the customer's lease. Sub-resources are typically supplied by various downstream service control planes residing in one or more service leases within the CSP. For example, such as Figure 1As depicted, in order to provision resource R1, a customer (e.g., an end user associated with that customer) can transmit a resource creation request to the customer control plane (e.g., 108) associated with resource R1. The resource creation request is received by the customer control plane R1 108 associated with resource R1. Customer control plane R1 108 may be associated with an authoritative service that owns and is responsible for creating and managing resource R1 in the customer's lease. Upon receiving the resource creation request, customer control plane R1 108 bootstraps / provisions an instance of resource R1 and sets the endpoint of resource R1 to customer control plane R1 108. Customer control plane R1 108 then creates a resource principal identity for resource R1 and may also provide the customer with metadata associated with resource R1 (e.g., tags, compartment identifiers for the customer's lease, etc.).

[0036] A resource principal identity, also referred to throughout this disclosure as a resource principal token (RPT), is a secure identity provided to a cloud infrastructure resource that enables the resource to be authorized to access other cloud infrastructure resources. In some examples, the resource principal identity is a token signed by an authoritative service in the CSP that provides trusted metadata about the resource. Once provisioned, a customer can interact with resource R1 and write policies that grant that resource access to other customer-leased resources (such as vault resource 118, object repository 120, etc.).

[0037] As described above, after an instance of resource R1 is created in customer lease 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 lease-1 104. Upon receiving the resource creation request, service control plane R2 110 bootstraps / provisions an instance of resource R2 and sets the endpoint of resource R2 to service control plane R2 110. Service control plane R2 110 then creates a resource principal identity for resource R2. Resource R3, as a child resource of R2, is similarly provisioned by service control plane R3 112 in service lease-2 106. Additional details related to the service control plane's provisioning of child resources (e.g., R2 or R3) that are composed within a higher-level resource (R1) are described below. Figure 2 It is described in conjunction with its accompanying description.

[0038] In some cases, a sub-resource (e.g., R3) comprised within resource R1 may wish to access customer-owned resources (e.g., vault resource 118) residing in a customer lease. Since sub-resource R3 is provisioned in a service lease, and the customer-owned resource resides in the customer lease, it is generally expected that the customer will write cross-tenant policies to enable sub-resource R3 to access the vault resource. For example, sub-resource R3 could represent a database resource comprised within the aforementioned higher-level FA resource. The database resource may need to access resources (e.g., encryption keys) from customer-owned vault resource 118. Data in the database resource can be encrypted using an encryption key provided by the customer and residing in the customer lease. Because the database resource resides in the service lease, when the database resource attempts to access the key from vault resource 118, a cross-tenant call is required to access the vault resource.

[0039] Existing methods for enabling sub-resources comprised within higher-level resources to access customer-owned resources typically involve customers writing cross-tenancy policies to allow sub-resources to successfully make cross-tenancy calls to customer-owned resources. This often 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 identity of resources supplied in a different tenancy than the customer's (e.g., a service tenancy) is not ideal and may compromise the security of cloud resources.

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

[0041] Therefore, the disclosed system enables customers to write robust and simple access control policies that provide simplified and secure cloud resource access management. Using the capabilities provided by the disclosed system, customers only need to write a single policy targeting the highest-level resource (root resource) they own in their customer lease. Since customers do not need to write policies for sub-resources comprised within higher-level resources, details of the sub-resources (e.g., resource principal identity) do not need to be exposed to customers. Furthermore, changes can be made to sub-resources comprised within higher-level resources (e.g., adding new resources, changing hierarchies or resources, deleting resources, etc.) without affecting customers or compromising resource security.

[0042] In some embodiments, the nested resource principal management system 116 interacts with the identity management system 114 in the CSP to obtain the resource principal identity of the nested sub-resources. Details related to the nested resource identity management system and the processing performed by the identity management system are described below. Figure 3 It is described in conjunction with its accompanying description.

[0043] Figure 1 The computing environment 100 depicted herein 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, alternatives, and modifications. For example, in some embodiments, the computing environment 100 may use a larger... Figure 1 The implementation can be achieved through more or fewer subsystems, or by combining two or more subsystems, or by having different subsystem configurations or arrangements. Figure 1 The subsystems 114 and 116 depicted can be implemented using only software (e.g., code, instructions, programs), hardware, or a combination thereof executed by one or more processing units (e.g., processors, cores) of a computing system. The software can be stored on a non-transitory storage medium (e.g., a memory device).

[0044] Figure 2 Examples of processes performed by a control plane associated with a service in a service lease to provision resources in the service lease, according to certain embodiments, are described. In some examples, such as in Figure 1 In the embodiments described, a resource may represent a nested sub-resource (e.g., R2) residing in a service lease, where resource R2 is comprised within a higher-level resource R1 residing in a customer lease. For example, the higher-level resource may represent an FA resource, and sub-resource R2 may represent a database resource comprised within the FA resource. Figure 1As described above, after an instance of a higher-level (root) resource R1 is created in a customer lease, the customer control plane R1 108 associated with resource R1 initiates the creation of a sub-resource (R2) by invoking a service control plane (e.g., control plane R2 110), which is associated with an authoritative downstream service that owns resource R2 in the service lease and is responsible for supplying sub-resource R2 in the service lease.

[0045] exist Figure 2 In the example shown, the downstream service refers to the database service (Database as a Service (DBaaS)) in service lease 216, which is responsible for provisioning instances of database resources composed within higher-level FA resources. Upon receiving an instance creation request from the client control plane 218 of the FA resources, the database service control plane, DBaaS control plane (CP) 202, provisiones instances of database resources by allocating virtual machines (VMs) and disk storage devices for the database resources in Exadata rack 204. As described herein, Exadata rack 204 represents the computing platform (i.e., the combined hardware and software platform) in service lease 216 of the database service, which allocates computing resources (storage devices and servers) to run the database resources.

[0046] In some examples, the allocation of an instance of a database resource (also referred to herein as an Exadata resource instance) involves a database process (“abc_1”) running in a VM 204 within an Exadata rack 204, allocated by DBaaS CP 202, and a disk storage device 212 for the database process (“abc_1”). Figure 2 In the example depicted, Exadata rack 204 consists of multiple VMs (e.g., VM1 204, VM2 206, VM3 208, VMn 210). Multiple database processes (e.g., abc_1, def_1) can execute within a specific VM (Exadata instance). For example, "abc_1" could represent the database process assigned to the first customer of the CSP within the Exadata resource instance, while "def_1" could represent database processes assigned to different customers of the CSP within the same Exadata instance, as well as disk storage device 214. Each database instance (Exa instance) additionally has a secondary instance running in a secondary VM (e.g., VM2 206) for high availability. Each database process running in a VM has a file (e.g., a JSON file) accessible to the 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 also has a DBaaS control plane endpoint that it can call to obtain its resource principal identity.

[0047] As previously mentioned, a 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 identifiers, etc.). In some examples, a nested resource principal management system 116 (in...) Figure 1 (As shown in the diagram) The database resource's RPT is obtained from the database resource's control plane 202, and then the higher-level FA resource's RPT is obtained by communicating with the FA resource's customer control plane 218. The FA resource's RPT is associated with a compartment (lease) identifier and service identifier belonging to the customer's lease. The database resource can then use the FA resource's RPT to access customer-owned resources (e.g., such as...). Figure 1 (Vault resource 118 shown). A customer-owned resource sees a database resource located in the customer's lease with an RPT containing a service identifier and lease information, and provides the database resource with access to an encryption key in vault resource 118 without requiring the database resource to make cross-lease calls to access vault resource 118.

[0048] In one implementation, the nested resource principal management system 116 can use [the following]... Figure 2 The software (e.g., code, instructions, programs) executed by a client application running within the database process (e.g., abc_1) shown is implemented. This software may represent a collection of software development kit (SDK) tools, including the ability to obtain resource RPTs from their corresponding service control planes. Using the resource RPTs in the resource hierarchy, the nested resource principal management system 116 is additionally coupled with an identity management system (e.g., Figure 1 The interaction shown in 114) is used to obtain a Resource Principal Session Token (RPST) for a resource. In some examples, the RPST of a resource represents a temporary session token and security 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 is able to assert its Resource Principal Identity (RPT) to other cloud resources and services owned by the CSP. In one implementation, the RPST may be formatted as a JSON Web Token (JWT) token and include a claim identifying the host lease and compartment information of the resource. Using the RPST of a higher-level resource, a nested sub-resource residing in a service lease (e.g., R2) can access a customer-owned resource in a customer lease without requiring cross-lease policy calls. Additional details regarding the interaction between the nested resource identity management system and the identity management system for enabling nested sub-resources residing in a service lease to access customer-owned resources residing in a customer lease are provided in [link to details]. Figure 3As described in the text.

[0049] Figure 3 This is a sequence diagram depicting, according to certain embodiments, a series of interactions that enable nested sub-resources residing in a service lease to access customer-owned resources residing in a customer lease. Figure 3 In the example depicted, nested sub-resource R3 is part of a resource hierarchy that includes resources R2 and R1. Resources R1, R2, and R3 have a hierarchical relationship with each other, where R1 represents the highest-level resource in the hierarchy, and R2 and R3 represent sub-resources in the hierarchy. Furthermore, R2 and R3 have a hierarchical relationship, where R3 is a child resource (sub-resource) of R2.

[0050] like Figure 3 As depicted, processing is initiated at operation 314 when a nested sub-resource R3 302, supplied in a service lease, transmits a request for the resource principal identifier (i.e., RPT) of R3 to the service control plane (CP R3 304) associated with the authoritative service that owns resource R3. In one embodiment, the nested resource principal management system 116 (in... Figure 1 (As shown in the diagram) The RPT of resource R3 is obtained from the control plane 202 of resource R3. For example, as... Figure 2 As described above, the nested resource principal management system 116 can use virtual machines that provide resources through services, such as... Figure 2 The software (e.g., code, instructions, programs) executed by the client application running within the process shown (e.g., abc_1) is implemented. The software may represent a collection of software development kit (SDK) tools, including the ability to obtain resources from its corresponding service control plane via RPT.

[0051] R3's control plane verifies the request and, upon successful verification, issues an RPT for resource R3. At operation 316, R3's control plane transmits the RPT for resource R3 along with information identifying the resource at the next level in the resource hierarchy (e.g., an endpoint). In some implementations, an endpoint may represent a Uniform Resource Locator (URL) of a resource endpoint at the next level in the resource hierarchy. In some embodiments, such as in... Figure 1 In the embodiment depicted, since resource R3 is a child resource of resource R2, and R2 is its parent resource in the resource hierarchy, as a result of performing operation 316, resource R3302 receives endpoint information identifying its next-level resource R2 in the resource hierarchy.

[0052] At operation 318, resource R3 transmits a request, including its RPT, to identity management system (IDM) 310 to obtain a resource principal session token (RPST) used 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 previously described, a resource's RPST is a temporary session token and security credential that enables the resource to authenticate itself (assert its resource principal identity) to other cloud resources owned by the CSP. Figure 3 The identity management system 310 shown can be used with Figure 1 It is implemented in a similar way to the identity management system 116 described in the document.

[0053] At operation 320, the identity management system 310 transmits the RPST to R3. At operation 322, resource R3 uses the RPST obtained in 320 to invoke the endpoint of the next-level resource R2 in the resource hierarchy. At operation 324, the control plane (CP R2 306) receiving the invocation of resource R2 verifies the request and, upon successful verification, returns the RPT of resource R2 and the endpoint information of the next-level resource in the resource hierarchy (if it exists). Figure 3 In the example depicted, 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 implementation, the nested resource principal management system 116 (in Figure 1 (As shown in the diagram) The RPT of resource R2 is obtained from the control plane associated with resource R2. At operation 326, resource R3 transmits a request including R2's RPT to the identity management system (IDM) 310 to obtain R2's resource principal session token (RPST). As a result of performing operation 326, IDM 310 exchanges resource R2's RPT for its RPST, and at operation 328, IDM transmits R2's RPST to R2.

[0054] At operation 330, resource R3 uses R2's RPT and calls the endpoint of the next-level resource R1 in the resource hierarchy to obtain resource R1's RPT. At operation 332, R1's control plane 308 verifies the request and issues R1's RPT upon successful verification. In one implementation, a nested resource principal management system 116 (in...) Figure 1 (As shown in the diagram) The RPT of resource R1 is obtained from the control plane associated with resource R1. At operation 334, resource R3 requests the RPST of resource R1 from the identity management system, and at operation 336, resource R3 obtains the RPST of R1 from IDM 310.

[0055] Therefore, resource R3 acquires the resource's RSPT until it reaches the highest level or root level in the resource hierarchy (resource R1 in this example). As a result of executing 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 (root) resource R1. Since the third RPST represents the identity of the highest-level (root) resource R1 in the resource hierarchy and R1 resides in the customer lease, the nested lower-level resource R3 uses resource R1's RPST to assert its identity when performing various operations (such as accessing customer-owned resources 312). The customer-owned resource sees that resource R3 has an RPST that includes lease information and service identifiers belonging to the customer lease, enabling resource R3 to access the customer-owned resource without requiring resource R3 to make cross-lease calls.

[0056] The above description Figure 1-3 The embodiments described herein depict a specific example of creating cloud resources using converged application (FA) resources created in a customer lease, wherein the sub-resources comprised of the FA application resources are supplied by different service leases of a CSP. Furthermore, Figure 1-3 The disclosed nested resource principal management system describes the capabilities provided by enabling nested lower-level resources (e.g., database resources within an FA resource) to acquire and use the resource principal identity of their higher-level FA resource to access customer-owned resources residing in a customer lease, without using a separate cross-lease policy to grant lower-level resources permission to access customer-owned resources.

[0057] The disclosed nested resource principal management system can be additionally configured to enable other different types of cloud resources provisioned in a service lease to access customer-owned resources residing in a customer lease without using cross-lease policies. For example, in some embodiments, the disclosed nested resource principal management system includes the ability to enable nested sub-resources composed in a machine language (ML) application to access customer-owned resources in a customer lease without the sub-resources making cross-lease calls to access the customer-owned resources. As described herein, an ML application refers to a type of cloud resource (also referred to herein as an ML application) provided by a CSP to a customer for building, training, deploying, and managing machine learning models. ML applications typically consist of a set of one or more building blocks, including data storage resources (e.g., object buckets), execution resources, and resources for serving model predictions. Execution resources can represent job run resources and pipeline run resources. These execution resources can be provisioned by a managed infrastructure (i.e., a service lease or provisioning platform) provided by the service in the CSP. Job run resources enable ML applications to perform repeatable machine learning tasks. Job run resources can be automatically provisioned with computing resources (such as CPUs or GPUs) based on the block size, shape, and network configuration required for model building. Pipeline runtime resources enable ML applications to execute end-to-end machine learning workflows. Pipeline runtime resources define the workflow of tasks or steps for data import, data transformation, model training, and model evaluation.

[0058] In some embodiments, the creation of the ML application (also referred to herein as an ML resource) is typically performed by the customer within a customer lease. The internal composition of the ML application is generally hidden from the customer, who treats the application as a single entity (i.e., a single logical resource). The actual provisioning / allocation of the infrastructure resources (e.g., pipeline operation resources and job operation resources) comprised within the ML application is performed by the service responsible for managing those resources in the service lease. Once provisioned, the customer can interact with the ML application and write policies to grant the ML application permission to access other resources within the customer lease as well as resources residing in different leases (e.g., service leases, third-party leases, etc.).

[0059] In some embodiments, sub-resources comprised within an ML application (e.g., job run resources) may wish to access customer-owned resources (e.g., object repository 120) residing in a customer lease. The disclosed nested resource principal management system enables sub-resources to access customer-owned resources using the resource principal identity of their higher-level resource (ML application) residing in a customer lease. By obtaining the resource identity of the higher-level resource, the sub-resource can access customer-owned resources seamlessly without requiring cross-lease policy invocations for customer-owned resources. Because the sub-resource is associated with the resource principal identifier of its higher-level resource, it can access customer-owned resources using a generic policy associated with the higher-level resource that provides permission for the higher-level resource to interact with other customer-owned resources.

[0060] Figure 4 A hierarchy of resources composed in machine language (ML) applications, according to certain embodiments, is depicted. Figure 4 In the example depicted, ML application 402 represents the highest-level (root) resource created in the customer lease. Pipeline run resource 404 and job run resource 406 represent sub-resources composed within ML application 402. Sub-resources 404 and 406 are child resources of root resource 402. Furthermore, pipeline run resource 404 and job run resource 406 also have a hierarchical relationship, where job run resource 406 is a child resource of its parent pipeline run resource 404. The internal components of the ML application (e.g., pipeline run resources and job run resources) are generally hidden from the customer, who perceives the ML application as a single entity (i.e., a single logical resource) within customer lease 408. Sub-resources are typically supplied by various downstream service control planes residing in one or more service leases residing in the CSP. Figure 4 In the example depicted, sub-resources 404 and 406 are both provisioned within a single service lease 410 in the CSP. In alternative embodiments, such as Figure 1 As described in the text, sub-resources of higher-level resources can be supplied in different service leases.

[0061] The provisioning of resources 402, 404, and 406 can be performed by a control plane associated with authoritative services that own / manage resources in one or more service leases of the CSP, such as... Figure 1 As described in [the text]. For example, using [the text]. Figure 1Examples of resources R1, R2, and R3 depicted herein, in response to a resource creation request sent by a customer leasing service, can provision resource R1 (e.g., representing ML application 402) within a customer lease. The resource creation request is received by the customer control plane (e.g., 108) associated with resource R1. Upon receiving the resource creation request, the service control plane of resource R1 bootstraps / provisions an instance of resource R1 and sets the endpoint of resource R1 to service control plane R1. Service control plane R1 then creates a resource principal identity for resource R1 and can also provide the customer with trusted metadata associated with resource R1 (e.g., tags, customer lease compartment identifiers, etc.). Once provisioned, the customer can interact with resource R1 (i.e., the ML application) and write policies granting the ML application access to other customer lease resources (such as vault resource 118, object repository 120, etc.).

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

[0063] In some cases, sub-resources that are composed within a higher-level ML application 402 (e.g., job runtime resource 406) may wish to access customer-owned resources (e.g., object storage resources) residing in a customer lease. Figure 5 This is a sequence diagram illustrating, according to certain embodiments, a series of interactions that enable nested lower-level resources of an ML application residing in a service lease to access customer-owned resources residing in a customer lease. Figure 4 As depicted in the example, job runtime resources are part of a resource hierarchy that includes pipeline resources and top-level ML applications / resources. Job runtime resources and pipeline runtime resources are child resources of ML applications and have a hierarchical relationship with each other. ML applications represent higher-level resources, pipeline runtime resources are child resources of ML applications, and job runtime resources are child resources of their parent pipeline runtime resources.

[0064] like Figure 5As depicted, when job runtime resource 502 transmits a request for its Resource Principal Identifier (i.e., RPT) to the service control plane associated with the authoritative service that owns the job runtime resource (CP JR 504), processing is initiated at operation 514. The job runtime resource's control plane verifies the request and, upon verification, issues the job runtime resource's RPT. At operation 516, the job runtime resource's control plane transmits the job runtime resource's RPT along with information identifying resources at the next level of the resource hierarchy (e.g., endpoint information). In some embodiments, such as in... Figure 4 In the embodiment depicted, since the job running resource is a child resource of the pipeline running (PR) resource, and the pipeline running resource is its parent resource in the resource hierarchy, as a result of executing operation 516, the job running resource 502 receives endpoint information identifying its next-level resource (i.e., the pipeline running resource). At operation 518, the job running resource transmits a request including its RPT to the identity management system (IDM) 510 to obtain a Resource Principal Session Token (RPST) for asserting its resource principal identity. As a result of executing operation 518, the IDM 510 exchanges the job running resource's RPT for its RPST. As previously described, a resource's RPST is a temporary session token and security credential that enables the resource to authenticate itself (assert its resource principal identity) to other cloud resources owned by the CSP. Figure 5 The identity management system 510 shown can be used with Figure 3 and Figure 1 It is implemented in a similar way to the identity management system described in [the document].

[0065] At operation 520, the identity management system 510 transmits the RPST to the job execution resource. At operation 522, the job execution resource uses the RPST obtained in 520 to invoke the endpoint of the next-level resource (pipeline execution resource) in the resource hierarchy. At operation 524, the control plane (CP PR 506) of the receiving pipeline execution resource verifies the request and, upon verification, returns the pipeline execution resource's RPT and, if any, the endpoint information of the next-level resource in the resource hierarchy. Figure 5In the example depicted, the control plane 506 of the pipeline operation resource identifies the ML application / ML resource as a next-level resource in the resource hierarchy and returns the RPT of the pipeline operation resource and the endpoint information of the ML application to the job operation resource. At operation 526, the job operation resource transmits a request including the RPT of the pipeline operation resource to the identity management system (IDM) 310 to obtain the resource principal session token (RPST) of the pipeline operation resource. As a result of executing operation 526, IDM 510 exchanges the RPT of the pipeline operation resource for its RPST, and at operation 528, IDM 510 transmits the RPST of the pipeline operation resource to the job operation resource.

[0066] At operation 530, the job execution resource uses the pipeline execution resource's RPT and invokes the endpoint of the next-level resource in the resource hierarchy (i.e., the ML application) to obtain the ML application's RPT. At operation 532, the ML application's control plane 508 verifies the request and, upon verification, issues the ML application's RPT. At operation 534, the job execution resource requests the ML application's RPST from the identity management system, and at operation 536, the job execution resource obtains the ML application's RPST from the identity management system 510. The job execution resource obtains the resource's RSPT until it reaches the root level in the resource hierarchy (in this example, the ML application instance).

[0067] As a result of 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). Since the third RPST represents the identity of the highest-level (root) resource in the resource hierarchy (i.e., the ML application) and the ML application resides in a customer lease, nested lower-level resources such as the job run resource can use the ML application resource's RPST to assert its resource principal identity when performing various operations, such as accessing customer-owned resources (object repository) 512. The customer-owned resource sees the job run resource associated with an RPST containing lease information and service identifiers belonging to the customer lease, enabling the job run resource to access the customer-owned resource without requiring cross-lease calls from the job run resource.

[0068] Figure 6 The text describes a nested resource principal management system and identity management system according to certain embodiments. Figure 1 The example described is a processing 600 performed within a computing environment. Figure 6The processing described herein can be implemented in software (e.g., code, instructions, programs), hardware, or a combination thereof, executed by one or more processing units (e.g., processors, cores) of a corresponding system. The software can be stored on a non-transitory storage medium (e.g., a memory device). Figure 6 The processing 600 presented and described below is intended to be illustrative and not restrictive. Although Figure 6 Various processing steps that occur in a specific order or sequence are described, but this is not intended to be limiting. In some alternative embodiments, the steps may be performed in a different order, or some steps may be performed in parallel. In some embodiments, such as in Figure 1 In the embodiments depicted, Figure 6 The processing described in the text can be done by Figure 1 One or more subsystems shown (e.g., 114 and 116) are executed.

[0069] At box 602, processing is initiated when the nested resource principal management system acquires a first identity associated with a first resource residing in a first lease of the CSP. In some examples, the first resource may represent a nested sub-resource residing in a service lease of the CSP, where that resource is part of a higher-level resource (second resource) residing in a customer lease. For example, as... Figure 2 As described, a higher-level resource (secondary resource) can represent an FA resource, while a sub-resource (first resource) can represent a database resource comprised within an FA resource. The primary identity associated with the primary resource can correspond to the Resource Principal Identity (RPT) associated with the primary resource. As previously mentioned, the RPT is a security identity provided to cloud infrastructure resources that enables the resource to be authorized to access other cloud infrastructure resources.

[0070] In one implementation, the nested resource principal management system obtains the RPT of the first resource from the control plane associated with the resource, such as regarding... Figure 2 and Figure 3 As described. In some embodiments, as part of the process performed in step 602, the nested resource principal management system also obtains information identifying a second resource. This information identifies the endpoints of the second resource and may represent the URL of the resource endpoints of the second resource.

[0071] At box 604, the identity management system uses the first identity obtained in box 602 to obtain a first token for the first resource. The first token enables the first resource to assert the first identity. The first token corresponds to the Resource Principal Session Token (RPST) associated with the first resource. As discussed earlier, the RPST of a resource is a temporary session token and security credential that enables the resource to authenticate itself (assert its resource principal identity) to other cloud resources owned by the CSP.

[0072] At box 606, the nested resource principal management system obtains a second identity associated with the second resource residing in the service lease. This second identity may correspond to the resource principal identity (RPT) associated with the second resource and can be obtained by the nested resource principal management system from the control plane associated with the second resource, as per [reference to...]. Figure 2 and Figure 3 As described.

[0073] At box 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 assert the second identity. In one implementation, the second token corresponds to a Resource Principal Session Token (RPST) associated with the second resource.

[0074] At box 610, the first resource uses the second token to access a customer-owned resource residing in a customer lease. The customer-owned resource sees that the first resource has an RPST associated with the second resource, which has a service identifier and lease information belonging to the customer lease, enabling the first resource to access the customer-owned resource without requiring the first resource to make cross-lease calls.

[0075] The disclosed system enables customers to write robust and simple access control policies that provide simplified and secure management of cloud resource access. Using the capabilities provided by the disclosed system, customers only need to write a single policy for the higher-level resources they own within their lease. Because customers do not need to write policies for sub-resources comprised within higher-level resources, details of the sub-resources (e.g., resource principal identity) do not need to be exposed to customers. Furthermore, changes can be made to sub-resources comprised within higher-level resources (e.g., adding new resources, changing hierarchies or resources, deleting resources, etc.) without affecting customers or compromising resource security.

[0076] As noted 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, cloud providers 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, IaaS providers can also offer various services accompanying these infrastructure components (e.g., billing, monitoring, logging, load balancing, and clustering, etc.). Therefore, because these services may be policy-driven, IaaS users can implement policies to drive load balancing to maintain application availability and performance.

[0077] In some instances, IaaS customers can access resources and services over a wide area network (WAN) such as the internet, and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create buckets for workloads and backups, and even install enterprise software into that VM. 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.

[0078] In most cases, cloud computing models will require the involvement of cloud providers. Cloud providers can, but are not necessarily, third-party providers specializing in (e.g., provisioning, renting, selling) IaaS services. Entities may also choose to deploy private clouds, thus becoming their own infrastructure service providers.

[0079] In some examples, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It may also include the processing of server preparation (e.g., installation libraries, daemons, etc.). This is typically managed by the cloud provider, below the hypervisor layer (e.g., servers, storage devices, network hardware, and virtualization). Therefore, the customer can be responsible for disposition (OS), middleware, and / or application deployment (e.g., on self-service virtual machines, etc., which can be started on demand).

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

[0081] In some cases, IaaS provisioning presents two distinct challenges. First, there's the initial challenge of provisioning the initial infrastructure set before anything is operational. Second, once everything is provisioned, there's the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both challenges can be addressed by enabling configuration that declaratively defines the infrastructure. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. Therefore, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they work together) can be described declaratively. In some instances, once the topology is defined, workflows for creating and / or managing the different components described in the configuration files can be generated.

[0082] In some examples, the infrastructure can have many interconnected elements. For example, there may be one or more Virtual Private Clouds (VPCs) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as the core network. In some examples, one or more inbound / outbound traffic group rules may also be provided to define how inbound / outbound traffic to the network and one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, etc., may also be provided. The infrastructure can evolve incrementally as more and / or more infrastructure elements are expected and added.

[0083] In some instances, continuous deployment techniques can be used to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the described techniques enable infrastructure management within these environments. In some examples, service teams may write code that they expect to deploy to one or more, but often many, different production environments (e.g., across various geographical locations, sometimes spanning the entire world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some instances, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or once the infrastructure is provisioned, the code can be deployed using deployment tools.

[0084] Figure 7This is a block diagram 700 illustrating an example pattern of an IaaS architecture according to at least one embodiment. Service operator 702 may be communicatively coupled to a secure host lease 704, which may include a virtual cloud network (VCN) 706 and a secure host subnet 708. In some examples, service operator 702 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, cellular phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display), running software (such as Microsoft Windows Mobile®) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and supporting the Internet, email, short message service (SMS), Blackberry®, or other communication protocols. Alternatively, client computing devices may be general-purpose personal computers, including, for example, personal computers and / or laptops running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. The client computing device can be a workstation computer running a variety of commercially available UNIX® or UNIX-like operating systems, including but not limited to any of the various GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, the client computing device can be any other electronic device, such as a thin client computer, an internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without Kinect® gesture input), and / or a personal messaging device capable of communicating over a network that can access VCN 706 and / or the internet.

[0085] VCN 706 may include a local peering gateway (LPG) 710, which may be communicatively coupled to a secure shell (SSH) VCN 712 via the LPG 710 included in SSH VCN 712. SSH VCN 712 may include an SSH subnet 714, and SSH VCN 712 may be communicatively coupled to a control plane VCN 716 via the LPG 710 included in control plane VCN 716. Furthermore, SSH VCN 712 may be communicatively coupled to a data plane VCN 718 via the LPG 710. Control plane VCN 716 and data plane VCN 718 may be contained within a service lease 719 that may be owned and / or operated by an IaaS provider.

[0086] The control plane VCN 716 may include a control plane demilitarized zone (DMZ) layer 720 that acts as a peripheral network (e.g., a portion of a corporate network between a corporate intranet and an external network). DMZ-based servers can assume limited liability and help control vulnerabilities. Furthermore, the DMZ layer 720 may include one or more load balancer (LB) subnets 722, a control plane application layer 724 that may include one or more application subnets 726, and a control plane data layer 728 that may include one or more database (DB) subnets 730 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). One or more LB subnets 722 contained in the control plane DMZ layer 720 may be communicatively coupled to one or more application subnets 726 contained in the control plane application layer 724 and an Internet gateway 734 that may be contained in the control plane VCN 716. The application subnets 726 may be communicatively coupled to one or more DB subnets 730 contained in the control plane data layer 728, as well as a service gateway 736 and a Network Address Translation (NAT) gateway 738. The control plane VCN 716 may include the service gateway 736 and the NAT gateway 738.

[0087] The control plane VCN 716 may include a data plane mirror application layer 740, which may include one or more application subnets 726. The one or more application subnets 726 included in the data plane mirror application layer 740 may include a virtual network interface controller (VNIC) 742 capable of executing a compute instance 744. The compute instance 744 may communicatively couple the one or more application subnets 726 of the data plane mirror application layer 740 to the one or more application subnets 726 that may be included in the data plane application layer 746.

[0088] Data plane VCN 718 may include data plane application layer 746, data plane DMZ layer 748, and data plane data layer 750. Data plane DMZ layer 748 may include one or more LB subnets 722 communicatively coupled to one or more application subnets 726 of data plane application layer 746 and Internet gateway 734 of data plane VCN 718. One or more application subnets 726 may be communicatively coupled to service gateway 736 and NAT gateway 738 of data plane VCN 718. Data plane data layer 750 may also include one or more DB subnets 730 communicatively coupled to one or more application subnets 726 of data plane application layer 746.

[0089] The Internet gateway 734 of the control plane VCN 716 and data plane VCN 718 can be communicatively coupled to the metadata management service 752, which in turn can be communicatively coupled to the public Internet 754. The public Internet 754 can be communicatively coupled to the NAT gateway 738 of the control plane VCN 716 and data plane VCN 718. The service gateway 736 of the control plane VCN 716 and data plane VCN 718 can be communicatively coupled to the cloud service 756.

[0090] In some examples, the service gateway 736 of the control plane VCN 716 or data plane VCN 718 can make application programming interface (API) calls to the cloud service 756 without traversing 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 requested data to the service gateway 736. However, the cloud service 756 may not initiate API calls to the service gateway 736.

[0091] In some examples, secure host lease 704 can be directly connected to service lease 719, which would otherwise be isolated. Secure host subnet 708 can communicate with SSH subnet 714 via LPG 710, which enables bidirectional communication between otherwise isolated systems. Connecting secure host subnet 708 to SSH subnet 714 allows secure host subnet 708 to access other entities within service lease 719.

[0092] Control plane VCN 716 allows users of service lease 719 to configure or otherwise provision desired resources. Desired resources provisioned in control plane VCN 716 can be deployed or otherwise used in data plane VCN 718. In some examples, control plane VCN 716 can be isolated from data plane VCN 718, and the data plane mirror application layer 740 of control plane VCN 716 can communicate with the data plane application layer 746 of data plane VCN 718 via VNIC 742, which can be included in both the data plane mirror application layer 740 and the data plane application layer 746.

[0093] In some examples, users or clients of the system can make requests, such as create, read, update, or delete (CRUD) operations, via the public internet 754, which can transmit requests to the metadata management service 752. The metadata management service 752 can transmit the request to the control plane VCN 716 via internet gateway 734. The request can be received by one or more LB subnets 722 contained in the control plane DMZ layer 720. The LB subnets 722 can determine that the request is valid, and in response to this determination, they can transmit the request to one or more application subnets 726 contained in the control plane application layer 724. If the request is validated and requires a call to the public internet 754, the call to the public internet 754 can be transmitted to a NAT gateway 738 that can make calls to the public internet 754. The request may expect the stored metadata to be stored in one or more DB subnets 730.

[0094] In some examples, the data plane mirroring application layer 740 can facilitate direct communication between the control plane VCN 716 and the data plane VCN 718. For example, it might be desirable to apply configuration changes, updates, or other appropriate modifications to resources contained in the data plane VCN 718. Through VNIC 742, the control plane VCN 716 can communicate directly with the resources contained in the data plane VCN 718, and thus can perform configuration changes, updates, or other appropriate modifications.

[0095] In some embodiments, the control plane VCN 716 and data plane VCN 718 may be included in a service lease 719. In this case, the system's users or customers may not own or operate the control plane VCN 716 or the data plane VCN 718. Alternatively, the IaaS provider may own or operate both the control plane VCN 716 and the data plane VCN 718, and both planes may be included in the service lease 719. This embodiment can enable the isolation of networks that might prevent users or customers from interacting with resources from other users or customers. Furthermore, this embodiment can allow users or customers of the system to privately store databases without relying on the public Internet 754, which may not have the desired level of threat prevention for storage.

[0096] In other embodiments, one or more LB subnets 722 included in the control plane VCN 716 may be configured to receive signals from the service gateway 736. In this embodiment, the control plane VCN 716 and the data plane VCN 718 may be configured to be invoked by the IaaS provider's customers without invoking the public internet 754. The IaaS provider's customers may expect this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on a service lease 719, which may be isolated from the public internet 754.

[0097] Figure 8 This is a block diagram 800 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 802 (e.g., Figure 7 The service provider (702) can communicatively couple to the secure host lease (804) (e.g., Figure 7 Secure hosting lease 704), the secure hosting lease 804 may include a Virtual Cloud Network (VCN) 806 (e.g., Figure 7 VCN706) and Secure Host Subnet 808 (e.g., Figure 7 The secure host subnet 708). VCN 806 may include a local peering gateway (LPG) 810 (e.g., Figure 7 The LPG 710), which can be communicatively coupled to the Secure Shell (SSH) VCN 812 (e.g., via the LPG 710 contained in the SSH VCN 812) Figure 7 SSH VCN 712). SSH VCN 812 can include SSH subnet 814 (e.g., Figure 7 SSH subnet 714), and SSH VCN 812 can be communicatively coupled to control plane VCN 816 via LPG 810 included in control plane VCN 816 (e.g., Figure 7 Control plane VCN 716). Control plane VCN 816 may be included in service lease 819 (e.g., Figure 7 In the service lease 719), and the data plane VCN 818 (e.g., Figure 7 The data plane VCN 718 may be included in a customer lease 821 that may be owned or operated by a user or customer of the system.

[0098] Control plane VCN 816 may include control plane DMZ layer 820 (e.g., Figure 7 The control plane DMZ layer 720), which may include one or more LB subnets 822 (e.g., Figure 7(one or more) LB subnets 722), may include (one or more) application subnets 826 (e.g., Figure 7 The control plane application layer 824 of (one or more) application subnets 726 (e.g., Figure 7 The control plane application layer 724) may include one or more database (DB) subnets 830 (e.g., similar to...). Figure 7 The control plane data layer 828 of (one or more) DB subnets 730 (e.g., Figure 7 The control plane data layer 728). One or more LB subnets 822 contained in the control plane DMZ layer 820 can be communicatively coupled to one or more application subnets 826 contained in the control plane application layer 824 and an Internet gateway 834 that can be contained in the control plane VCN 816 (e.g., Figure 7 Internet gateway 734), and application subnet(s) 826 can communicatively couple to DB subnet(s) 830 contained in control plane data layer 828 and service gateway 836 (e.g., Figure 7 Service gateway 736) and Network Address Translation (NAT) gateway 838 (e.g., Figure 7 (NAT gateway 738). The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0099] The control plane VCN 816 may include a data plane mirror of the application layer 840, which may include one or more application subnets 826 (e.g., Figure 7 The data plane mirror application layer 740). One or more application subnets 826 contained in the data plane mirror application layer 840 may include compute instances 844 capable of performing computations (e.g., similar to...). Figure 7 The virtual network interface controller (VNIC) 842 (e.g., the VNIC of 742) of the computing instance 744. The computing instance 844 may facilitate the mirroring of the application subnet(s) 826 of the application layer 840 in the data plane and may be included in the application layer 846 in the data plane (e.g., Figure 7 Communication between one or more application subnets 826 in the data plane application layer 746 via VNIC 842 contained in the data plane mirror application layer 840 and VNIC 842 contained in the data plane application layer 846.

[0100] The Internet gateway 834 included in the control plane VCN 816 can be communicatively coupled to the metadata management service 852 (e.g., Figure 7 Metadata management service 752), which can communicatively couple to the public Internet 854 (e.g., Figure 7 The public internet 854 can communicatively couple to a NAT gateway 838 contained in the control plane VCN 816. The service gateway 836 contained in the control plane VCN 816 can communicatively couple to a cloud service 856 (e.g., ...). Figure 7 Cloud services 756).

[0101] In some examples, data plane VCN 818 may be included in customer lease 821. In this case, the IaaS provider may provide control plane VCN 816 for each customer, and the IaaS provider may set up a unique compute instance 844 for each customer, included in service lease 819. Each compute instance 844 may allow communication between control plane VCN 816 included in service lease 819 and data plane VCN 818 included in customer lease 821. Compute instance 844 may allow resources provisioned in control plane VCN 816 included in service lease 819 to be deployed or otherwise used in data plane VCN 818 included in customer lease 821.

[0102] In other examples, an IaaS provider's customer may have a database residing in customer lease 821. In this example, control plane VCN 816 may include data plane mirror application layer 840, which may include one or more application subnets 826. Data plane mirror application layer 840 may reside in data plane VCN 818, but may not reside in data plane VCN 818. That is, data plane mirror application layer 840 may have access to customer lease 821, but may not reside in data plane VCN 818 or be owned or operated by an IaaS provider's customer. Data plane mirror application layer 840 may be configured to invoke data plane VCN 818, but may not be configured to invoke any entity contained in control plane VCN 816. Customers may expect to deploy or otherwise use resources provisioned in the control plane VCN 816 in the data plane VCN 818, and the data plane mirroring application layer 840 can facilitate the customer's desired deployment or other use of resources.

[0103] In some embodiments, an IaaS provider's customer can apply filters to data plane VCN 818. In this embodiment, the customer can determine what data plane VCN 818 can access, and the customer can restrict access from data plane VCN 818 to the public Internet 854. The IaaS provider may not be able to apply filters or otherwise control data plane VCN 818's access to any external networks or databases. Applying filters and controls to data plane VCN 818 contained in customer lease 821 can help isolate data plane VCN 818 from other customers and the public Internet 854.

[0104] In some embodiments, cloud service 856 may be invoked by service gateway 836 to access services that may not exist on public internet 854, control plane VCN 816, or data plane VCN 818. The connection between cloud service 856 and control plane VCN 816 or data plane VCN 818 may not be real-time or continuous. Cloud service 856 may reside on different networks owned or operated by an IaaS provider. Cloud service 856 may be configured to receive calls from service gateway 836 and may be configured not to receive calls from public internet 854. Some cloud services 856 may be isolated from other cloud services 856, and control plane VCN 816 may be isolated from cloud services 856 that may not be in the same region as control plane VCN 816. For example, control plane VCN 816 may be located in "Region 1," and cloud service "Deployment 7" may be located in both "Region 1" and "Region 2." If the service gateway 836, contained in the control plane VCN 816 located in region 1, makes a call to deployment 7, then that call can be transmitted to deployment 7 in region 1. In this example, the control plane VCN 816 or deployment 7 in region 1 may not be communicatively coupled to or otherwise communicate with deployment 7 in region 2.

[0105] Figure 9 This is a block diagram 900 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 902 (e.g., Figure 7 The service provider (702) can communicatively couple to the secure host lease (904) (e.g., Figure 7 Secure hosting lease 704), the secure hosting lease 904 may include a Virtual Cloud Network (VCN) 906 (e.g., Figure 7 VCN706) and Secure Host Subnet 908 (e.g., Figure 7 The secure host subnet 708). VCN 906 can include LPG 910 (e.g., Figure 7The LPG 710), which can be communicatively coupled to the SSH VCN 912 via the LPG 910 included in the SSH VCN 912 (e.g., Figure 7 SSH VCN 712). SSH VCN 912 can include SSH subnet 914 (e.g., Figure 7 SSH subnet 714), and SSH VCN 912 can be communicatively coupled to control plane VCN 916 via LPG 910 contained in control plane VCN 916 (e.g., Figure 7 The control plane VCN 716) and coupled to the data plane VCN 918 via the LPG 910 contained in the data plane VCN 918 (e.g., Figure 7 Data plane 718). Control plane VCN 916 and data plane VCN 918 may be included in service lease 919 (e.g., Figure 7 (Service rental 719).

[0106] The control plane VCN 916 may include one or more load balancer (LB) subnets 922 (e.g., Figure 7 The control plane DMZ layer 920 of (one or more) LB subnets 722) (e.g., Figure 7 The control plane DMZ layer 720 may include one or more application subnets 926 (e.g., similar to...). Figure 7 The control plane application layer 924 of (one or more) application subnets 726 (e.g., Figure 7 The control plane application layer 724), may include (one or more) DB subnets 930, and the control plane data layer 928 (e.g., Figure 7 The control plane data layer 728). One or more LB subnets 922 contained in the control plane DMZ layer 920 can be communicatively coupled to one or more application subnets 926 contained in the control plane application layer 924 and an Internet gateway 934 that can be contained in the control plane VCN 916 (e.g., Figure 7 Internet gateway 734), and application subnet(s) 926 can communicatively couple to DB subnet(s) 930 contained in control plane data layer 928 and service gateway 936 (e.g., Figure 7 The service gateway) and Network Address Translation (NAT) gateway 938 (e.g., Figure 7 (NAT gateway 738). The control plane VCN 916 may include the service gateway 936 and the NAT gateway 938.

[0107] The data plane VCN 918 may include the data plane application layer 946 (e.g., Figure 7Data plane application layer 746), data plane DMZ layer 948 (e.g., Figure 7 Data plane DMZ layer 748), and data plane data layer 950 (e.g., Figure 7 The data plane data layer 750. The data plane DMZ layer 948 may include one or more trusted application subnets 960 and one or more untrusted application subnets 962 communicatively coupled to the data plane application layer 946, and one or more LB subnets 922 of the Internet gateway 934 contained in the data plane VCN 918. One or more trusted application subnets 960 may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918, the NAT gateway 938 contained in the data plane VCN 918, and one or more DB subnets 930 contained in the data plane data layer 950. One or more untrusted application subnets 962 may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918 and one or more DB subnets 930 contained in the data plane data layer 950. The data plane data layer 950 may include one or more DB subnets 930 communicatively coupled to the service gateway 936 contained in the data plane VCN 918.

[0108] One or more untrusted application subnets 962 may include one or more primary VNICs 964(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 966(1)-(N). Each tenant VM 966(1)-(N) may be communicatively coupled to a corresponding application subnet 967(1)-(N) that may be contained in a corresponding container egress VCN 968(1)-(N), which may be contained in a corresponding customer lease 970(1)-(N). A corresponding secondary VNIC 972(1)-(N) may facilitate communication between one or more untrusted application subnets 962 contained in a data plane VCN 918 and the application subnets contained in the container egress VCN 968(1)-(N). Each container egress VCN 968(1)-(N) may include a NAT gateway 938 that can be communicatively coupled to the public Internet 954 (e.g., Figure 7 The public internet (754).

[0109] An Internet gateway 934, contained in the control plane VCN 916 and the data plane VCN 918, can be communicatively coupled to a metadata management service 952 (e.g., Figure 7A metadata management system 952 (metadata management service 952) can be communicatively coupled to the public internet 954. The public internet 954 can be communicatively coupled to a NAT gateway 938 contained in a control plane VCN 916 and a data plane VCN 918. A service gateway 936 contained in a control plane VCN 916 and a data plane VCN 918 can be communicatively coupled to a cloud service 956.

[0110] In some embodiments, the data plane VCN 918 can be integrated with the customer lease 970. Such integration may be useful or desired by the IaaS provider's customers in certain situations, such as when support may be expected during code execution. Customers may provide code that could be destructive, might communicate with other customer resources, or might otherwise cause undesirable effects. In response, the IaaS provider can determine whether to run the code provided by the customer to the IaaS provider.

[0111] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality attached to the data plane application layer 946. The code running this functionality may execute in VMs 966(1)-(N) and may not be configured to run anywhere else on the data plane VCN 918. Each VM 966(1)-(N) may be connected to a customer lease 970. The corresponding container 971(1)-(N) contained in VMs 966(1)-(N) may be configured to run the code. In this case, dual isolation may exist (e.g., container 971(1)-(N) runs the code, where container 971(1)-(N) may be contained in at least one or more untrusted application subnets 962 containing VMs 966(1)-(N)), which can help prevent incorrect or otherwise unintended code from corrupting the IaaS provider's network or the networks of different customers. Container 971(1)-(N) may be communicatively coupled to Customer Lease 970 and may be configured to transmit or receive data from Customer Lease 970. Container 971(1)-(N) may not be configured to transmit or receive data from any other entity in Data Plane VCN 918. After the code execution is complete, the IaaS provider may terminate or otherwise dispose of Container 971(1)-(N).

[0112] In some embodiments, one or more trusted application subnets 960 may run code that can be owned or operated by an IaaS provider. In this embodiment, one or more trusted application subnets 960 may be communicatively coupled to one or more database subnets 930 and configured to perform CRUD operations in one or more database subnets 930. One or more untrusted application subnets 962 may be communicatively coupled to one or more database subnets 930, but in this embodiment, one or more untrusted application subnets may be configured to perform read operations in one or more database subnets 930. Containers 971(1)-(N) that may be contained in each customer's VM 966(1)-(N) and may run code from the customer may not be communicatively coupled to one or more database subnets 930.

[0113] In other embodiments, the control plane VCN 916 and the data plane VCN 918 may be coupled without direct communication. In this embodiment, there may be no direct communication between the control plane VCN 916 and the data plane VCN 918. However, communication can occur indirectly through at least one method. The LPG 910 may be established by an IaaS provider, which can facilitate communication between the control plane VCN 916 and the data plane VCN 918. In another example, either the control plane VCN 916 or the data plane VCN 918 may invoke the cloud service 956 via the service gateway 936. For example, an invocation of the cloud service 956 from the control plane VCN 916 may include a request for a service that can communicate with the data plane VCN 918.

[0114] Figure 10 This is a block diagram 1000 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 1002 (e.g., Figure 7 The service provider 702 can communicatively couple to the secure host lease 1004 (e.g., Figure 7 Secure hosting lease 704), the secure hosting lease 1004 may include a virtual cloud network (VCN) 1006 (e.g., Figure 7 VCN 706) and Secure Host Subnet 1008 (e.g., Figure 7 The secure host subnet 708). VCN 1006 may include LPG1010 (e.g., Figure 7 The LPG 710), the LPG 1010 can be accessed via SSH VCN 1012 (e.g., LPG 710), Figure 7 The LPG 1010 in SSH VCN 1012 is communicatively coupled to SSH VCN 1012. SSH VCN 1012 may include SSH subnet 1014 (e.g., Figure 7 SSH subnet 714), and SSH VCN 1012 can be communicatively coupled to control plane VCN 1016 via LPG1010 included in control plane VCN 1016 (e.g., Figure 7 The control plane VCN 716) and coupled to the data plane VCN 1018 via the LPG 1010 contained in the data plane VCN 1018 (e.g., Figure 7 Data plane 718). Control plane VCN 1016 and data plane VCN 1018 may be included in service lease 1019 (e.g., Figure 7 (Service rental 719).

[0115] The control plane VCN 1016 may include one or more LB subnets 1022 (e.g., Figure 7 The control plane DMZ layer 1020 of (one or more) LB subnets 722) (e.g., Figure 7 The control plane DMZ layer 720 may include one or more application subnets 1026 (e.g., Figure 7 The control plane application layer 1024 of (one or more) application subnets 726 (e.g., Figure 7 The control plane application layer 724) may include (one or more) DB subnets 1030 (e.g., Figure 9 The control plane data layer 1028 of (one or more) DB subnets 930 (e.g., Figure 7 The control plane data layer 728). One or more LB subnets 1022 contained in the control plane DMZ layer 1020 can be communicatively coupled to one or more application subnets 1026 contained in the control plane application layer 1024 and an Internet gateway 1034 that can be contained in the control plane VCN 1016 (e.g., Figure 7 Internet gateway 734), and application subnet(s) 1026 can communicatively couple to DB subnet(s) 1030 contained in control plane data layer 1028 and service gateway 1036 (e.g., Figure 7 The service gateway) and Network Address Translation (NAT) gateway 1038 (e.g., Figure 7 (NAT gateway 738). The control plane VCN 1016 may include the service gateway 1036 and the NAT gateway 1038.

[0116] Data plane VCN 1018 may include data plane application layer 1046 (e.g., Figure 7 Data plane application layer 746), data plane DMZ layer 1048 (e.g., Figure 7Data plane DMZ layer 748), and data plane data layer 1050 (e.g., Figure 7 The data plane data layer 750). The data plane DMZ layer 1048 may include one or more trusted application subnets 1060 that can be communicatively coupled to the data plane application layer 1046 (e.g., Figure 9 (one or more) trusted application subnets 960 and (one or more) untrusted application subnets 1062 (e.g., Figure 9 The data plane VCN 1018 may include one or more untrusted application subnets 962 and one or more LB subnets 1022 of Internet gateway 1034. One or more trusted application subnets 1060 may communicatively couple to service gateway 1036, NAT gateway 1038, and DB subnets 1030 in data plane VCN 1018. One or more untrusted application subnets 1062 may communicatively couple to service gateway 1036 and DB subnets 1030 in data plane VCN 1018. Data plane VCN 1050 may include one or more DB subnets 1030 that may communicatively couple to service gateway 1036 in data plane VCN 1018.

[0117] One or more untrusted application subnets 1062 may include a primary VNIC 1064(1)-(N) communicatively coupled to tenant virtual machines (VMs) 1066(1)-(N) residing within one or more untrusted application subnets 1062. Each tenant VM 1066(1)-(N) may run code in a corresponding container 1067(1)-(N) and is communicatively coupled to an application subnet 1026 that may be contained in a data plane application layer 1046 contained in a container egress VCN 1068. A corresponding secondary VNIC 1072(1)-(N) may facilitate communication between one or more untrusted application subnets 1062 contained in a data plane VCN 1018 and the application subnet contained in a container egress VCN 1068. The container egress VCN may include a public internet 1054 (e.g., Figure 7 The public internet (754) uses NAT gateway 1038.

[0118] Internet gateway 1034, contained in control plane VCN 1016 and data plane VCN 1018, can be communicatively coupled to metadata management service 1052 (e.g., Figure 7A metadata management system 752 (metadata management service 1052) can be communicatively coupled to the public internet 1054. The public internet 1054 can be communicatively coupled to a NAT gateway 1038 contained in a control plane VCN 1016 and a data plane VCN 1018. A service gateway 1036 contained in a control plane VCN 1016 and a data plane VCN 1018 can be communicatively coupled to a cloud service 1056.

[0119] In some examples, Figure 10 The architecture shown in block diagram 1000 can be considered as... Figure 9 This is an exception to the pattern shown in the architecture of block diagram 900, and this pattern may be what the IaaS provider's customers expect if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer can access in real time the corresponding container 1067(1)-(N) contained in each customer's VM 1066(1)-(N). Container 1067(1)-(N) can be configured to invoke the corresponding auxiliary VNIC 1072(1)-(N) contained in one or more application subnets 1026 of the data plane application layer 1046, which may be contained in the container egress VCN 1068. The auxiliary VNIC 1072(1)-(N) can transmit the call to the NAT gateway 1038, which can then transmit the call to the public internet 1054. In this example, containers 1067(1)-(N), which can be accessed by clients in real time, can be isolated from the control plane VCN 1016 and from other entities contained in the data plane VCN 1018. Containers 1067(1)-(N) can also be isolated from resources from other clients.

[0120] In other examples, a client may use container 1067(1)-(N) to invoke cloud service 1056. In this example, the client may run code within container 1067(1)-(N) requesting a service from cloud service 1056. Container 1067(1)-(N) may transmit the request to auxiliary VNIC 1072(1)-(N), which may transmit the request to a NAT gateway, which may then transmit the request to public internet 1054. Public internet 1054 may then transmit the request via internet gateway 1034 to one or more LB subnets 1022 contained in control plane VCN 1016. In response to determining that the request is valid, one or more LB subnets may transmit the request to one or more application subnets 1026, which may then transmit the request to cloud service 1056 via service gateway 1036.

[0121] It should be recognized that the IaaS architectures 700, 800, 900, and 1000 depicted in the figures may have other components besides those depicted. Furthermore, the embodiments shown in the figures are merely some examples of cloud infrastructure systems that can be incorporated into embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have different configurations or component arrangements.

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

[0123] Figure 11 An example computer system 1100 in which various embodiments can be implemented is illustrated. System 1100 can be used to implement any of the computer systems described above. As shown, computer system 1100 includes a processing unit 1104 that communicates with a plurality 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. Storage subsystem 1118 includes a tangible computer-readable storage medium 1122 and system memory 1110.

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

[0125] A processing unit 1104, which may be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 1100. One or more processors may be included in the processing unit 1104. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 1104 may be implemented as one or more independent processing units 1132 and / or 1134, wherein each processing unit includes a single-core or multi-core processor. In other embodiments, the processing unit 1104 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0126] In various embodiments, processing unit 1104 can execute various programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in processor(s) 1104 and / or storage subsystem 1118. With appropriate programming, processor(s) 1104 can provide the various functions described above. Computer system 1100 may additionally include processing acceleration unit 1106, which may include digital signal processor (DSP), dedicated processor, etc.

[0127] I / O subsystem 1108 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into a display, scroll wheels, click wheels, dials, buttons, switches, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices, such as the Microsoft Kinect® motion sensor, which enables users to control and interact with input devices such as the Microsoft Xbox® 360 game controller via a natural user interface using gestures and voice commands. User interface input devices may also include eye posture recognition devices, such as the Google Glass® blink detector, which detects eye activity from the user (e.g., “blinking” when taking a photo and / or making menu selections) and translates the eye posture into input in an input device (e.g., Google Glass®). Furthermore, user interface input devices may include voice recognition sensing devices that enable users to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0128] User interface input devices may also include, but are not limited to, 3D mice, joysticks or pointing sticks, game panels and drawing tablets, as well as audio / video devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Furthermore, user interface input devices may include, for example, medical imaging input devices such as computed tomography (CT), magnetic resonance imaging (MRI), positron emission tomography (PET), and medical ultrasound equipment. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, etc.

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

[0130] Computer system 1100 may include a storage subsystem 1118 containing software elements, shown as currently located in system memory 1110. System memory 1110 may store program instructions that can be loaded and executed on processing unit 1104, as well as data generated during the execution of these programs.

[0131] Depending on the configuration and type of computer system 1100, system memory 1110 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that can be immediately accessed by processing unit 1104 and / or are currently being operated and executed by processing unit 1104. In some embodiments, system memory 1110 may include various 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 contains basic routines that facilitate the transfer of information between elements of computer system 1100 during startup, may typically be stored in ROM. For example, but not as a limitation, system memory 1110 also includes application programs 1112, program data 1114, and an operating system 1116, which may include client applications, web browsers, middleware applications, relational database management systems (RDBMS), etc. For example, operating system 1116 may include various versions of Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google Chrome® operating system, etc.) and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS and Palm® OS.

[0132] Storage subsystem 1118 may also provide a tangible computer-readable storage medium for storing basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provides the above-described functionality when executed by a processor may be stored in storage subsystem 1118. These software modules or instructions may be executed by processing unit 1104. Storage subsystem 1118 may also provide a repository for storing data used according to this disclosure.

[0133] Storage subsystem 1100 may also include a computer-readable storage medium reader 1120 that can be further connected to computer-readable storage medium 1122. Together with and optionally in conjunction with system memory 1110, computer-readable storage medium 1122 can comprehensively represent a remote, local, fixed, and / or removable storage device plus storage medium for temporarily and / or more persistently containing, storing, transmitting, and retrieving computer-readable information.

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

[0135] For example, computer-readable storage medium 1122 may include a hard disk drive that reads or writes to a non-removable non-volatile magnetic medium, a disk drive that reads or writes to a removable non-volatile magnetic disk, and an optical disc drive that reads or writes to a removable non-volatile optical disc (such as a CD-ROM, DVD, and Blu-ray® disc or other optical media). 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 audio tapes, and so on. Computer-readable storage medium 1122 may also include solid-state drives (SSDs) based on non-volatile memory (such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, etc.), volatile memory-based SSDs (such as solid-state RAM, dynamic RAM, static RAM), DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs using a combination of DRAM-based 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 computer system 1100.

[0136] The communication subsystem 1124 provides an interface to other computer systems and networks. The communication subsystem 1124 serves as an interface for receiving data from other systems and sending data from computer system 1100 to other systems. For example, the communication subsystem 1124 enables 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 (e.g., advanced data network technologies using cellular telephone technology, such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof), GPS receiver components, and / or other components for accessing wireless voice and / or data networks. In some embodiments, as an addition to or alternative to the wireless interface, the communication subsystem 1124 may provide a wired network connection (e.g., Ethernet).

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

[0138] 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 Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0139] Furthermore, the communication subsystem 1124 can also be configured to receive data in the form of a continuous data stream, which may include an event stream 1128 and / or event updates 1130 that are essentially continuous or unbounded real-time events without a clearly defined termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, and so on.

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

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

[0142] Due to the ever-evolving nature of computers and networks, the description of the computer system 1100 depicted in the figures is merely a concrete example. Many other configurations with more or fewer components than the system depicted in the figures are possible. For example, custom hardware may be used and / or specific elements may be implemented using hardware, firmware, software (including applets), or a combination thereof. Additionally, connections to other computing devices, such as network input / output devices, may also be employed. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other ways and / or methods for implementing the various embodiments.

[0143] While specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within certain specific data processing environments, but can be freely operated within multiple data processing environments. Furthermore, although the embodiments have been described using a specific series of transactions and steps, those skilled in the art will understand that the scope of this disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above embodiments can be used individually or in combination.

[0144] 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 may be implemented using only hardware, or only software, or a combination thereof. The various processes described herein can be implemented in any combination on the same processor or on different processors. Accordingly, where a component or module is described as being configured to perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits to perform operations, by programming programmable electronic circuits (such as microprocessors), or any combination thereof. Processes may communicate using a variety of technologies, including but not limited to conventional technologies for inter-process communication, and different pairs of processes may use different technologies, or the same pair of processes may use different technologies at different times.

[0145] Accordingly, the specification and drawings are intended to be illustrative rather than restrictive. However, it will be apparent that additions, omissions, deletions, and other modifications and alterations may be made thereto without departing from the broader spirit and scope set forth in the claims. Thus, while specific disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0146] In the context of describing the disclosed embodiments (especially in the context of the following claims), the term “the” and similar designations are to be construed as covering both the singular and plural, unless otherwise indicated herein or clearly contradicted by the context. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including but not limited to”). The term “connected” should be construed as being partially or wholly contained in, attached to, or joined together, even if something exists in between. Unless otherwise indicated herein, the enumeration of value ranges herein is intended only as a shorthand method for individually referencing each individual value falling within that range, and each individual value is incorporated into the specification as if it were individually enumerated herein. Unless otherwise indicated herein or clearly contradicted by the context, all methods described herein can be performed in any suitable order. The use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended only to better illustrate the embodiments and does not constitute a limitation on the scope of this disclosure, unless otherwise stated. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of this disclosure.

[0147] Disjunctive language, such as the phrase “at least one of X, Y, or Z”, unless otherwise explicitly stated, is intended to be understood in the context generally used to represent items, terms, etc., and may be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive language is generally not intended to, and should not, imply that some embodiments require the presence of at least one of X, at least one of Y, or at least one of Z, each individually.

[0148] This document describes preferred embodiments of the present disclosure, including the best modes known for carrying out the present disclosure. Variations of those preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to suitably employ such variations and may practice the present disclosure in ways other than those specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents to the subject matter recited in the appended claims, where permitted by applicable law. Furthermore, unless otherwise indicated herein, the present disclosure includes any combination of the foregoing elements in all its possible variations.

[0149] All references cited in this article, including publications, patent applications and patents, are incorporated into this article by reference to the same extent as if each reference individually and specifically indicated to be incorporated by reference and elaborated in full in this article.

[0150] In the foregoing specification, various aspects of this disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that this disclosure is not limited thereto. The various features and aspects of the foregoing disclosure may be used individually or in combination. Furthermore, embodiments may be used in any number of settings and applications other than those described herein without departing from the broader spirit and scope of this specification. Accordingly, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

Claims

1. A method comprising: For a first resource residing in one of multiple service leases provided by a cloud service provider (CSP), obtain information about a first identity associated with the first resource and information about identifying a second resource, wherein the first resource is a sub-resource of the second resource; Use the first identity to obtain the first token of the first resource, and the first token enables the first resource to assert the first identity; To acquire a second identity associated with a second resource for a first resource, wherein the second resource is created in a customer lease provided by the CSP; Use the second identity to obtain the second token of the first resource, and the second token enables the first resource to assert the second identity; as well as The first resource uses the second token to access another resource residing in the customer's lease.

2. The method of claim 1, wherein service leasing refers to a provisioning platform for supplying, configuring and managing multiple cloud resources associated with multiple cloud services provided by a CSP.

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

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

5. The method as described in any of the preceding claims, wherein the first identity represents a resource subject identity associated with the first resource that enables the first resource to be authorized to access a plurality of cloud resources provided by the CSP.

6. The method as described in any of the preceding claims, wherein the first token represents a resource principal session token associated with the first resource, wherein the resource principal session token represents security credentials and temporary session tokens associated with the first resource that enable the first resource to authenticate itself to multiple cloud resources provided by the CSP.

7. The method of any 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 of any of the preceding claims, wherein a second identity of the second resource is obtained using information identifying the second resource, and wherein the second identity represents a resource subject 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 as described in any of the preceding claims, wherein the second identity of the second resource is obtained from a customer control plane associated with the second resource.

10. The method of claim 1, wherein the second token represents a resource principal session token associated with the second resource, the resource principal session token representing a security credential and temporary session token associated with the second resource that enables the second resource to authenticate itself to one or more resources provided by the CSP.

11. A system comprising: Memory; as well as One or more processors, the one or more processors being configured to perform a process, the process including: For a first resource residing in one of multiple service leases provided by a cloud service provider (CSP), obtain information about a first identity associated with the first resource and information about identifying a second resource, wherein the first resource is a sub-resource of the second resource; Use the first identity to obtain the first token of the first resource, and the first token enables the first resource to assert the first identity; To acquire a second identity associated with a second resource for a first resource, wherein the second resource is created in a customer lease provided by the CSP; Using the second identity to obtain a second token for the first resource, the second token enables the first resource to assert the second identity; and The first resource uses the second token to access another resource residing in the customer's lease.

12. The system of claim 11, wherein service leasing refers to a provisioning platform for supplying, configuring and managing multiple cloud resources associated with multiple cloud services provided by a CSP.

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

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

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

16. The system of claim 11, wherein the information identifying the second resource represents a Uniform Resource Locator (URL) of the resource endpoint associated with the second resource.

17. A non-transitory computer-readable medium storing instructions executable by a computer system, the instructions, when executed by one or more processors of the computer system, causing the one or more processors to perform operations, the operations including: For a first resource residing in one of multiple service leases provided by a cloud service provider (CSP), obtain information about a first identity associated with the first resource and information about identifying a second resource, wherein the first resource is a sub-resource of the second resource; Use the first identity to obtain the first token of the first resource, and the first token enables the first resource to assert the first identity; To acquire a second identity associated with a second resource for a first resource, wherein the second resource is created in a customer lease provided by the CSP; Use the second identity to obtain the second token of the first resource, and the second token enables the first resource to assert the second identity; as well as The first resource uses the second token to access another resource residing in the customer's lease.

18. The non-transitory computer-readable medium of claim 17, wherein the first identity represents a resource subject identity associated with the first resource that enables the first resource to be authorized to access a plurality of cloud resources provided by the CSP.

19. The non-transitory computer-readable medium of claim 17, wherein service leasing refers to a provisioning platform for supplying, configuring, and managing multiple cloud resources associated with multiple cloud services provided by a CSP.

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

21. A computer program product comprising computer program instructions, which, when executed by a processor, cause the processor to: For a first resource residing in one of multiple service leases provided by a cloud service provider (CSP), obtain information about a first identity associated with the first resource and information about identifying a second resource, wherein the first resource is a sub-resource of the second resource; Use the first identity to obtain the first token of the first resource, and the first token enables the first resource to assert the first identity; To acquire a second identity associated with a second resource for a first resource, wherein the second resource is created in a customer lease provided by the CSP; Use the second identity to obtain the second token of the first resource, and the second token enables the first resource to assert the second identity; as well as The first resource uses the second token to access another resource residing in the customer's lease.

Images