Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
  • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
  • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
  • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
  • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
  • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
  • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration

Definitions

• the tenancy that is created for the customer provides a root level compartment that holds all the cloud resources for the customer.
• resources may include, for example, one or more compute instances provisioned for the customer to provide one or more services for the customer.
• the compute instance is typically created and provided by a separate service infrastructure that is configured to provision and manage cloud resources related to the particular service.
• a method comprises receiving, by a first control plane for a first service, a request to create an attachment between a first compute instance of the first service and a second compute instance of a second service, where the first compute instance is controlled by the first control plane, the second compute instance is controlled by a second control plane, the first compute instance is within a customer tenancy, the second compute instance is within the customer tenancy, and the first compute instance is isolated from the second compute instance within the customer tenancy; executing, by the first control plane, a set of processing operations to create the attachment between the first compute instance and the second compute instance; and after executing the set of processing operations and due to the attachment, gaining control of the second compute instance and enabling communication between the first compute instance and the second compute instance.
• a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed, cause one or more processors of a computer system to perform a method comprising: receiving a request to create an attachment between a first compute instance of a first service and a second compute instance of a second service, where the first compute instance is controlled by a first control plane of the computer system, the second compute instance is controlled by a second control plane, the first compute instance is within a customer tenancy, the second compute instance is within the customer tenancy, and the first compute instance is isolated from the second compute instance within the customer tenancy; executing a set of processing operations to create the attachment between the first compute instance and the second compute instance; and after executing the set of processing operations and due to the attachment, gaining control of the second compute instance and enabling communication between the first compute instance and the second compute instance.
• FIG.1 is a simplified block diagram of a distributed environment according to some embodiments.
• a customer and its users only have access to resources that are placed within that customer's tenancy.
• These resources may include, for example, one or more compute instances provisioned for the customer to provide one or more services for the customer.
• the compute instance is typically created and provided by a separate service infrastructure that is configured to provision and manage cloud resources related to the particular service. For example, if the customer subscribes to a Service A and a Service B, a Service A infrastructure associated with its own tenancy (referred to as a service tenancy) is configured to create and provision a compute instance A that provides Service A for the customer.
• a computer system may use the networking resources to communicate with one or more other computer systems over one or more communication networks.
• the communication networks may include, for example, the Internet, an intranet, an extranet, a Local Area Network (LAN), a Wide Area Network (WAN), and other networks facilitating communications, and combinations thereof.
• the communications may occur over wired or wireless links using one or more wired or wireless communication protocols.
• the communication network may include a physical substrate network provided by an IaaS provider.
• the various components depicted in FIG. 1 may be hosted by infrastructure provided by a cloud service provider (CSP), such as an Infrastructure-as-a- Service (IaaS) provider.
• CSP cloud service provider
• IaaS Infrastructure-as-a- Service
• the Service-B control plane 122 may include a front end 123 component for receiving commands and otherwise communicating with the user 105, for example, via the console 106.
• the Service-B infrastructure 120 can also include a workflow component 124 that is responsible for performing processing corresponding to user requests received by the front end 123.
• the workflow component 124 may be responsible for configuring and executing one or more workflow processes for performing processing corresponding to user requests received by control plane 122.
• the Service A tenancy 115, Service B tenancy 125, and customer tenancy 130 are three separate tenancies.
• Service-A Infrastructure 110 cannot access or control cloud resources provisioned by Service-B Infrastructure 120.
• Service-A Infrastructure 110 cannot access Service-B compute instance 132.
• an infrastructure and a generalized method are described for attaching (also referred to as "wiring") two (or more) cloud resources (e.g., two compute instances) in spite of the compute resources being provisioned by two different services from different cloud tenancies.
• An automated process is described that is executed for wiring the compute instances. The automated process can be generally applied to attach any two compute instances providing two different services and provisioned from two different service tenancies.
• a user 105 may, via console 106, send a request to Service-A Infrastructure 110 to attach Service-A compute instance 131 and Service-B compute instance 132.
• a workflow is then executed for detaching the two compute instances, wherein the workflow involves processing performed by Service-A control plane 112, Service-B control plane 122, and by identity management and authorization service 140. Details related to the processing performed as part of this workflow are depicted in FIG.3, and described below. [0056] Embodiments described herein thus enable a user 105 to, on demand, request that two compute instances become attached and be able to communicate with each other, or become detached, again on demand. As illustrated in FIG. 1, the attachment is symbolically shown using attachment link 133, which represents a communicative link between the Service-A compute instance 131 and the Service-B compute instance 132.
• FIG.2 depicts a simplified swimchart 200 depicting a process for attaching two compute instances within a customer tenancy, according to certain embodiments.
• the processing depicted in FIG.2 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or combinations thereof.
• the Service-A control plane 112 can continue to control and manage the Service-A compute instance 131.
• the user 105 can (e.g., via the console 106) send an instruction to the Service-B control plane 122 to create a second compute instance for Service-B.
• the Service-B control plane 122 can create and configure a Service-B compute instance 132 (e.g., a substantiation of the second service) within the user’s customer tenancy 130.
• the Service-B control plane 122 can continue to control and manage the Service-B compute instance 132.
• processing may be initiated at S202, when the user 105 using a user device (e.g., console 106) sends a request to Service-A control plane 112 to attach the Service-A compute instance 131 and the Service-B compute instance 132.
• a user device e.g., console 106
• the control plane receiving the attachment request from a user is referred to as the "dominant" control plane
• the other control plane is referred to as the "passive" control plane.
• the dominant control plane initiates the attachment process, and includes necessary functionality and APIs for performing the attachment. For example, in FIG. 2, since Service-A control plane 112 receives the attachment request in S202, it is the dominant control plane while Service-B control plane 122 is the passive control plane.
• the user 105 via the user device can select the Service-A from a list displayed at a user interface.
• the request to attach may have to be sent to a particular one of the two service control planes.
• the attachment request may have to be sent to Service-A control plane 112 and not to Service-B control plane 122.
• only one of the control planes e.g., the Service-A control plane 112 may be capable of being the dominant control plane (e.g., based on available processing capabilities and APIs).
• the user device e.g., console 106
• the dominant control plane will have control and ownership of the passive control plane’s compute instance (within the customer tenancy).
• certain operations e.g., deleting a compute instance
• the passive control plane receives and obeys attachment messages and instructions from the dominant control plane, and allows the dominant control plane to take control of the passive control plane’s compute instance.
• the dominant control plane may then initiate processing to determine if the attachment request can be performed. For example, processing may be performed to determine if the user requesting the attachment is authorized to make such a request.
• the identity management and authorization service 140 may perform processing for the authorization.
• the dominant control plane in this example, the Service-A control plane 112 may send the identity management and authorization service 140 information related to the request received in S202. The identity management and authorization service 140 may then initiate an authorization process.
• the Service-A control plane workflow 114 (i.e., the dominant control plane) sends an attachment request to the Service-B control plane 122 (i.e., the passive control plane).
• the attachment request informs the Service-B control plane 122 that a compute instance owned by the Service-B control plane 122 is being attached to another compute instance owned by the dominant control plane (i.e., the Service-A control plane 122).
• the attachment request message includes a payload of any suitable information associated with the attachment.
• the attachment request can include identity/authorization information indicating that the Service-A control plane 112 is authorized to initiate creation of the attachment.
• an OBO token received by Service-A control plane 112 in S204 may be included in the request sent in S210.
• the Service-B control plane 122 i.e., the passive control plane
• the Service-B control plane 122 performs processing in response to receiving the attachment request. This can include storing (also referred to as “posting”) the attachment request details received from the Service-A control plane 112 (i.e., from the dominant control plane) in a record to persist the attachment information, and modifying ownership and allowed operations associated with the Service-B compute instance 132 (i.e., with the passive compute instance).
• the attachment and the Service-A Control Plane’s temporary ownership of the Service- B compute instance 132 remain valid until the attachment is deleted through a subsequent detach API call.
• the Service-B compute instance 132 cannot be deleted while the attachment exists.
• the compute instances have to be detached first, and then the Service-B compute instance 132 can be deleted. If the user device (e.g., console 106) attempts to delete the Service-B compute instance 132 via the Service-B Control Plane 122 that no longer has ownership of the Service-B compute instance 132, the deletion attempt will be denied due to the existing attachment.
• the Service-A control plane workflow 114 (i.e., the dominant control plane) sends an attachment request to the Service-B control plane 122 (i.e., the passive control plane).
• the attachment request informs the Service-B control plane 122 that a compute instance owned by the Service-B control plane 122 is being attached to another compute instance owned by the dominant control plane (i.e., the Service-A control plane 122).
• the attachment request message includes a payload of any suitable information associated with the attachment.
• the attachment request can include identity/authorization information indicating that the Service-A control plane 112 is authorized to initiate creation of the attachment.
• an OBO token received by Service-A control plane 112 in S404 may be included in the request sent in S410.
• the Service-A Control Plane 112 may send instructions to the Service-B control plane 122 (i.e., the passive control plane) to configure and/or update the Service-B compute instance 132 within the customer tenancy 130.
• the Service-A Control Plane 112 may install functionality (e.g., skills for a chatbot compute instance) for the Service-B compute instance 132 that enable communications between Service-B compute instance 132 and Service-A compute instance 131.
• functionality e.g., skills for a chatbot compute instance
• FIG.5 depicts a simplified swimchart 500 depicting a process for attaching two compute instances within a customer tenancy, where the dominant instance does not yet exist and is created as a part of the process, according to certain embodiments.
• the processing depicted in FIG.5 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or combinations thereof.
• the software may be stored on a non-transitory storage medium (e.g., on a memory device).
• a non-transitory storage medium e.g., on a memory device.
• the method presented in FIG.5 and described below is intended to be illustrative and non-limiting. Although FIG. 5 depicts the various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, the processing may be performed in some different order or some steps may also be performed in parallel.
• the swimchart 500 illustrates a process for attaching two compute instances. It is assumed for the process depicted in FIG.5 that the passive instance to be attached already exists prior to receiving the attachment request, and that the dominant instance to be attached does not yet exist prior to receiving the attachment request.
• the operation for deleting the passive compute instance may no longer be included in the new list of customer-permitted operations.
• the operation to delete the attachment may only be allowed for the owner, and not the customer.
• the Service-B control plane 122 i.e., the passive control plane performs processing in response to receiving the attachment request.
• the Service-B control plane 122 may verify that the Service-A control plane 112 is authorized to initiate creation of the attachment. For example, the Service-B control plane 122 can verify the authenticity of an OBO token and/or permissions associated with the OBO token.
• the Service-B control plane 122 may modify and configure the Service-B compute instance 132 within the customer tenancy 130 to show that an attachment exists.
• the Service-A Control Plane 112 may send instructions to the Service-B control plane 122 (i.e., the passive control plane) to configure and/or update the Service-B compute instance 132 within the customer tenancy 130.
• the Service-A Control Plane 112 may install functionality (e.g., skills for a chatbot compute instance) for the Service-B compute instance 132 that enable communications between Service-B compute instance 132 and Service-A compute instance 131.
• functionality e.g., skills for a chatbot compute instance
• the Service-A Control Plane 112 (i.e., the dominant control plane) performs processing to attach the compute instances in response to receiving the attachment response from the Service-B control plane 122 (i.e., from the passive control plane).
• the Service-A Control Plane 112 may store any suitable information in a record to persist the attachment information at the dominant control plane. This can include storing a compartment ID (e.g., within the customer tenancy 130) of the Service-B compute instance 132 as indicated by the Service-B control plane 122.
• the Service-A Control Plane 112 can identify what allowed operations were agreed to and/or provided by the Service-B control plane 122.
• the Service-A Control Plane 112 can perform identity wiring so that the Service-A compute instance 131 and the Service-B compute instance 132 can communicate with each other. In some embodiments, as part of the processing performed in S518, the Service-A Control Plane 112 can configure the Service-A compute instance 131 and/or the Service-B compute instance 132 to show the attachment. [0146] At this point, both control planes have agreed to the attachment and performed processing to complete the attachment, such as storing information associated with the attachment and modifying certain permissions, ownership, and configurations.
• the Service-B control plane 122 (i.e., the passive control plane) has given control and ownership of the Service- B compute instance 132 (i.e., the passive compute instance) to the Service-A Control Plane 112 (i.e., the dominant control plane).
• the Service-A Control Plane 112 (the dominant control plane) now has control and ownership of both the Service-A compute instance 131 (i.e., the dominant compute instance) and the Service-B compute instance 132 (i.e., the passive compute instance).
• the Service-A compute instance 131 and the attached Service-B compute instance 132 both continue to reside within the customer tenancy 130. [0147]
• S520 which can be the same as or similar to step S220 in FIG.
• the Service-A Control Plane Workflow 114 can send a completion message back to the Service-A Control Plane front end 113 indicating that the attachment was successfully established (or alternatively, if there was a failure). Then, at S522, which can be the same as or similar to step S222 in FIG. 2, the Service-A Control Plane front end 113 can send a completion message back to the user 105 (e.g., via the user device such as console 106) indicating that the attachment was successfully established (or indicating a failure). [0148] As a result of the processing depicted in FIG.
• FIG.6 depicts a simplified swimchart 600 depicting a process for attaching two compute instances within a customer tenancy, where both of the two compute instances do not yet exist and are created as a part of the process, according to certain embodiments.
• the processing depicted in FIG.6 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or combinations thereof.
• the software may be stored on a non- transitory storage medium (e.g., on a memory device).
• a non- transitory storage medium e.g., on a memory device.
• the method presented in FIG.6 and described below is intended to be illustrative and non-limiting. Although FIG.6 depicts the various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, the processing may be performed in some different order or some steps may also be performed in parallel. [0150]
• the swimchart 600 illustrates a process for attaching two compute instances. It is assumed for the process depicted in FIG.6 that the dominant instance to be attached does not exist prior to receiving the attachment request, and that the passive instance to be attached also does not yet exist prior to receiving the attachment request.
• processing may be initiated at S602, which can be the same as or similar to step S202 in FIG.2, when the user 105 using a user device (e.g., console 106) sends a request to Service-A control plane 112 to attach a Service-A compute instance 131 and a Service-B compute instance 132 within the user’s customer tenancy 130.
• a user device e.g., console 106
• the dominant control plane may then initiate processing to determine if the attachment request can be performed. For example, processing may be performed to determine if the user requesting the attachment is authorized to make such a request.
• the identity management and authorization service 140 may perform processing for the authorization. Accordingly, at S604, which can be the same as or similar to step S204 in FIG.2, the dominant control plane (in this example, the Service-A control plane 112) may send the identity management and authorization service 140 information related to the request received in S602. The identity management and authorization service 140 may then initiate an authorization process.
• the identity management and authorization service 140 may send a response back to the dominant control plane (i.e., Service-A control plane 112) providing authorization for the attachment processing to proceed.
• the response sent by the identity management and authorization service 140 to the Service-A control plane 112 may include an On-Behalf-Of (OBO) token.
• OBO On-Behalf-Of
• the Service-A control plane workflow 114 determines that a Service-A compute instance 131 (e.g., a substantiation of the first service) and a Service-B compute instance 132 (e.g., a substantiation of the second service) both do not exist within the user’s customer tenancy 130. Accordingly, it is determined that a Service-A compute instance 131 and a Service-B compute instance 132 are to be created before the attachment can be created.
• the Service-A control plane workflow 114 creates and configures a Service- A compute instance 131 (e.g., a substantiation of the first service) within the user’s customer tenancy 130.
• the Service-A control plane 112 can continue to control and manage the Service-A compute instance 131.
• the Service-A control plane workflow 114 sends a request to the Service-B control plane 122 (i.e., the passive control plane) to create a Service-B compute instance 132 (e.g., a substantiation of the second service) within the user’s customer tenancy 130.
• the creation request includes a payload of any suitable information associated with the creation.
• the creation request can include identity/authorization information indicating that the Service-A control plane 112 is authorized to initiate creation of the compute instance.
• an OBO token received by Service-A control plane 112 in S604 may be included in the request sent in S609-C.
• the response message can inform the Service-A Control Plane 112 of an instance identifier (e.g., OCID) for the Service-B compute instance 132 as well as any other suitable information.
• an instance identifier e.g., OCID
• the Service-A Control Plane 112 can continue with the process for attaching two compute instances.
• the Service-A control plane workflow 114 i.e., the dominant control plane
• sends an attachment request to the Service-B control plane 122 i.e., the passive control plane.
• the attachment request informs the Service-B control plane 122 that a compute instance owned by the Service-B control plane 122 is being attached to another compute instance owned by the dominant control plane (i.e., the Service-A control plane 122).
• the attachment request message includes a payload of any suitable information associated with the attachment.
• the attachment request can include identity/authorization information indicating that the Service-A control plane 112 is authorized to initiate creation of the attachment.
• an OBO token received by Service-A control plane 112 in S604 may be included in the request sent in S610.
• the attachment request can indicate the instances that are to be attached (e.g., the Service-A compute instance 131 and the Service-B compute instance 132).
• the request may identify a list of one or more operations that are permitted or not permitted on the passive compute instance by the customer due to the attachment.
• a list of permitted operations is provided for each of the customer and the passive service control plane. Any operation not specifically specified in the list is not allowed while the attachment is present.
• the operation for deleting the passive compute instance e.g., Service-B compute instance 132
• the operation to delete the attachment may only be allowed for the owner, and not the customer.
• the Service-B control plane 122 performs processing in response to receiving the attachment request. This can include storing (also referred to as “posting”) the attachment request details received from the Service-A control plane 112 (i.e., from the dominant control plane) in a record to persist the attachment information, and modifying ownership and allowed operations associated with the Service-B compute instance 132 (i.e., with the passive compute instance).
• the Service-B control plane 122 may verify that the Service-A control plane 112 is authorized to initiate creation of the attachment. For example, the Service-B control plane 122 can verify the authenticity of an OBO token and/or permissions associated with the OBO token.
• the Service-B control plane 122 may modify and configure the Service-B compute instance 132 within the customer tenancy 130 to show that an attachment exists.
• the Service-B control plane 122 sends an attachment response to the Service-A Control Plane 112 indicating that the attachment has been processed at the Service-B control plane 122.
• the attachment response message can inform the Service-A Control Plane 112 that the attachment details have been acknowledged and implemented in accordance with the attachment request message sent at step S610.
• the Service-A Control Plane 112 may send instructions to the Service-B control plane 122 (i.e., the passive control plane) to configure and/or update the Service-B compute instance 132 within the customer tenancy 130.
• the Service-A Control Plane 112 may install functionality (e.g., skills for a chatbot compute instance) for the Service-B compute instance 132 that enable communications between Service-B compute instance 132 and Service-A compute instance 131.
• functionality e.g., skills for a chatbot compute instance
• the Service-A Control Plane 112 (i.e., the dominant control plane) performs processing to attach the compute instances in response to receiving the attachment response from the Service-B control plane 122 (i.e., from the passive control plane).
• the Service-A Control Plane 112 may store any suitable information in a record to persist the attachment information at the dominant control plane. This can include storing a compartment ID (e.g., within the customer tenancy 130) of the Service-B compute instance 132 as indicated by the Service-B control plane 122.
• the Service-A Control Plane 112 can identify what allowed operations were agreed to and/or provided by the Service-B control plane 122.
• the Service-A Control Plane 112 can perform identity wiring so that the Service-A compute instance 131 and the Service-B compute instance 132 can communicate with each other. In some embodiments, as part of the processing performed in S618, the Service-A Control Plane 112 can configure the Service-A compute instance 131 and/or the Service-B compute instance 132 to show the attachment. [0166] At this point, both control planes have agreed to the attachment and performed processing to complete the attachment, such as storing information associated with the attachment and modifying certain permissions, ownership, and configurations.
• the Service-B control plane 122 (i.e., the passive control plane) has given control and ownership of the Service- B compute instance 132 (i.e., the passive compute instance) to the Service-A Control Plane 112 (i.e., the dominant control plane).
• the Service-A Control Plane 112 (the dominant control plane) now has control and ownership of both the Service-A compute instance 131 (i.e., the dominant compute instance) and the Service-B compute instance 132 (i.e., the passive compute instance).
• the Service-A compute instance 131 and the attached Service-B compute instance 132 both continue to reside within the customer tenancy 130. [0167]
• S620 which can be the same as or similar to step S220 in FIG.
• the Service-A Control Plane Workflow 114 can send a completion message back to the Service-A Control Plane front end 113 indicating that the attachment was successfully established (or alternatively, if there was a failure). Then, at S622, which can be the same as or similar to step S222 in FIG. 2, the Service-A Control Plane front end 113 can send a completion message back to the user 105 (e.g., via the user device such as console 106) indicating that the attachment was successfully established (or indicating a failure). [0168] As a result of the processing depicted in FIG.
• an embedded compute instance may be automatically attached without any user instructions or user involvement.
• the process illustrated in FIG.2 can take place without step S202.
• the Service-B compute instance 132 can be automatically attached to the Service-A compute instance 131 automatically and without a specific user request.
• Service-A compute instance 131 is assumed to be the dominant compute instance and the Service-B compute instance 132, which is attached to the Service-A compute instance 131, is the passive compute instance. Accordingly, the Service-A control plane 112 is the dominant control plane and the Service-B control plane 122 is the passive control plane.
• a user 105 may wish to perform an operation on the passive instance (e.g., Service-B compute instance 132) that is within the customer tenancy 130. As an example, the user 105 may wish to delete the passive instance (e.g., Service-B compute instance 132) within the customer tenancy 130.
• the user device may submit a request to perform the operation (e.g., deletion) on the passive instance (e.g., Service-B compute instance 132).
• this request is received by the service control plane that owns the passive instance (e.g., Service-B compute instance 132).
• the owner of the passive instance e.g., Service-B compute instance 132
• may be the dominant control plane e.g., Service-A control plane 112).
• the processing FIG.7 is initiated when, at step S705, the Dominant control plane (e.g., Service-A control plane 112) receives the request to perform the operation on the passive instance (e.g., Service-B compute instance 132) within the customer tenancy 130.
• the request is a deletion request to delete the passive instance (e.g., Service-B compute instance 132) within the customer tenancy 130.
• the Dominant control plane e.g., Service-A control plane 112 will then invoke the IDMAS 140 to perform a number of checks to determine whether the operation is permitted.
• the Dominant control plane e.g., Service-A control plane 112 calls the IDMAS 140, and the IDMAS 140 determines whether the requested operation (e.g., deleting the Passive instance) is authorized based on policies and permissions associated with or configured for the customer compartment.
• the customer tenancy compartment identifier associated with the passive compute instance e.g., Service-B compute instance 132 is used to identify the specific customer tenancy compartment and the one or more policies associated with that compartment. The policies are then evaluated to determine if the requested operation is authorized by the compartment policies.
• the processing performed by the IDMAS 140 in S710 may involve first identifying the specific compartment in the hierarchy that contains the passive instance (e.g., Service-B compute instance 132) and identifying any policies associated with that compartment. Then, starting from the specific compartment containing the Passive instance (e.g., Service-B compute instance 132), the hierarchy tree is walked up to the root compartment node. All the policies associated with the compartment that are include in the walk up to the root compartment are determined.
• the passive instance e.g., Service-B compute instance 132
• the hierarchy tree is walked up to the root compartment node. All the policies associated with the compartment that are include in the walk up to the root compartment are determined.
• the allowed customer operations can be stored at the Dominant control plane (e.g., Service-A control plane 112) and/or the passive control plane (e.g., Service-B control plane 122) as associated with the attachment.
• the allowed customer operations list can be referred to as a dual authorization list, because if an operation is included in the list, then it is a restricted operation that requires dual authorization. If an operation is not included in the list, then dual authorization is not required, it is not a restricted operation, and the initial authorization (e.g., at step S710) is considered sufficient.
• Step S725 the Dominant control plane (e.g., Service-A control plane 112) calls the IDMAS 140, and the IDMAS 140 determines whether the requested operation (e.g., deleting the Passive instance) is permitted or authorized based upon policies associated with the dominant tenancy (e.g., Service-A tenancy 115) or based upon attachment-related metadata stored for the dominant tenancy or control plane that identifies operations that are permitted on Passive instance (e.g., Service-B compute instance 132).
• the Dominant control plane e.g., Service-A control plane 112
• the IDMAS 140 determines whether the requested operation (e.g., deleting the Passive instance) is permitted or authorized based upon policies associated with the dominant tenancy (e.g., Service-A tenancy 115) or based upon attachment-related metadata stored for the dominant tenancy or control plane that identifies operations that are permitted on Passive instance (e.g., Service-B compute instance 132).
• both the Dominant control plane e.g., Service-A control plane 112
• the passive control plane e.g., Service-B control plane 122
• This stored information or record may include a list of operations that can be performed on the passive compute instance by the customer, and a list of operations that can be performed on the passive compute instance by the owner (e.g., the dominant control plane) while the attachment exists. If an operation is not included in this list, then that operation is not allowed and cannot be performed by the requesting user.
• the IDMAS 140 can thereby perform a second authorization to determine whether the requested operation (e.g., deleting the Passive instance) is authorized or permitted based upon policies associated with the dominant tenancy (e.g., Service-A tenancy 115).
• the IDMAS 140 can then send a response to the Dominant control plane (e.g., Service-A control plane 112) with the results of the second authorization.
• the Dominant control plane e.g., Service-A control plane 112
• the Dominant control plane e.g., Service-A control plane 112
• the requested operation e.g., deleting the Passive instance
• processing continues with S730, where the requested operation is allowed to be performed on the Passive instance (e.g., Service-B compute instance 132), and processing then ends. For example, if the requested operation is to delete the Passive instance, then Passive instance is deleted.
• a first policy may allow an operation (e.g., the customer compartment policy in step S710), but then a second policy is to be checked when an attachment exists, and the second policy may not allow the operation (e.g., the owner compartment policy in step S725).
• the owner compartment policy can be designed to include a limited set operations, such that certain operation requests will fail (e.g., when checking the owner compartment policy in step S725). For example, it may be desired to disallow the deletion operation, and the request to delete the Passive instance (e.g., Service-B compute instance 132) will fail at step S725.
• an infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potentially on-demand pool of configurable and/or shared computing resources), also known as a core network.
• VPCs virtual private clouds
• the data plane DMZ tier 848 can include LB subnet(s) 822 that can be communicatively coupled to the app subnet(s) 826 of the data plane app tier 846 and the Internet gateway 834 of the data plane VCN 818.
• the app subnet(s) 826 can be communicatively coupled to the service gateway 836 of the data plane VCN 818 and the NAT gateway 838 of the data plane VCN 818.
• the data plane data tier 850 can also include the DB subnet(s) 830 that can be communicatively coupled to the app subnet(s) 826 of the data plane app tier 846.
• users of the system, or customers can make requests, for example create, read, update, or delete (CRUD) operations, through public Internet 854 that can communicate the requests to the metadata management service 852.
• the metadata management service 852 can communicate the request to the control plane VCN 816 through the Internet gateway 834.
• the request can be received by the LB subnet(s) 822 contained in the control plane DMZ tier 820.
• the LB subnet(s) 822 may determine that the request is valid, and in response to this determination, the LB subnet(s) 822 can transmit the request to app subnet(s) 826 contained in the control plane app tier 824.
• the SSH VCN 912 can include an SSH subnet 914 (e.g. the SSH subnet 814 of FIG.8), and the SSH VCN 912 can be communicatively coupled to a control plane VCN 916 (e.g. the control plane VCN 816 of FIG.8) via an LPG 910 contained in the control plane VCN 916.
• the control plane VCN 916 can be contained in a service tenancy 919 (e.g. the service tenancy 819 of FIG. 8), and the data plane VCN 918 (e.g. the data plane VCN 818 of FIG.8) can be contained in a customer tenancy 921 that may be owned or operated by users, or customers, of the system.
• the LB subnet(s) 922 contained in the control plane DMZ tier 920 can be communicatively coupled to the app subnet(s) 926 contained in the control plane app tier 924 and an Internet gateway 934 (e.g. the Internet gateway 834 of FIG. 8) that can be contained in the control plane VCN 916, and the app subnet(s) 926 can be communicatively coupled to the DB subnet(s) 930 contained in the control plane data tier 928 and a service gateway 936 (e.g. the service gateway of FIG.8) and a network address translation (NAT) gateway 938 (e.g. the NAT gateway 838 of FIG. 8).
• the control plane VCN 916 can include the service gateway 936 and the NAT gateway 938.
• the control plane VCN 916 can include a data plane mirror app tier 940 (e.g. the data plane mirror app tier 840 of FIG.8) that can include app subnet(s) 926.
• the app subnet(s) 926 contained in the data plane mirror app tier 940 can include a virtual network interface controller (VNIC) 942 (e.g. the VNIC of 842) that can execute a compute instance 944 (e.g. similar to the compute instance 844 of FIG.8).
• the compute instance 944 can facilitate communication between the app subnet(s) 926 of the data plane mirror app tier 940 and the app subnet(s) 926 that can be contained in a data plane app tier 946 (e.g.
• the Internet gateway 934 contained in the control plane VCN 916 can be communicatively coupled to a metadata management service 952 (e.g. the metadata management service 852 of FIG.8) that can be communicatively coupled to public Internet 954 (e.g. public Internet 854 of FIG. 8).
• Public Internet 954 can be communicatively coupled to the NAT gateway 938 contained in the control plane VCN 916.
• the service gateway 936 contained in the control plane VCN 916 can be communicatively couple to cloud services 956 (e.g. cloud services 856 of FIG.8).
• the data plane mirror app tier 940 may be configured to make calls to the data plane VCN 918 but may not be configured to make calls to any entity contained in the control plane VCN 916.
• the customer may desire to deploy or otherwise use resources in the data plane VCN 918 that are provisioned in the control plane VCN 916, and the data plane mirror app tier 940 can facilitate the desired deployment, or other usage of resources, of the customer.
• the customer of the IaaS provider can apply filters to the data plane VCN 918.
• the customer can determine what the data plane VCN 918 can access, and the customer may restrict access to public Internet 954 from the data plane VCN 918.
• the IaaS provider may not be able to apply filters or otherwise control access of the data plane VCN 918 to any outside networks or databases. Applying filters and controls by the customer onto the data plane VCN 918, contained in the customer tenancy 921, can help isolate the data plane VCN 918 from other customers and from public Internet 954.
• cloud services 956 can be called by the service gateway 936 to access services that may not exist on public Internet 954, on the control plane VCN 916, or on the data plane VCN 918.
• the connection between cloud services 956 and the control plane VCN 916 or the data plane VCN 918 may not be live or continuous. Cloud services 956 may exist on a different network owned or operated by the IaaS provider.
• Cloud services 956 may be configured to receive calls from the service gateway 936 and may be configured to not receive calls from public Internet 954. Some cloud services 956 may be isolated from other cloud services 956, and the control plane VCN 916 may be isolated from cloud services 956 that may not be in the same region as the control plane VCN 916. For example, the control plane VCN 916 may be located in “Region 1,” and cloud service “Deployment 8,” may be located in Region 1 and in “Region 2.” If a call to Deployment 8 is made by the service gateway 936 contained in the control plane VCN 916 located in Region 1, the call may be transmitted to Deployment 8 in Region 1.
• FIG.10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment.
• Service operators 1002 e.g. service operators 802 of FIG.8 can be communicatively coupled to a secure host tenancy 1004 (e.g. the secure host tenancy 804 of FIG. 8) that can include a virtual cloud network (VCN) 1006 (e.g. the VCN 806 of FIG.8) and a secure host subnet 1008 (e.g. the secure host subnet 808 of FIG.8).
• VCN virtual cloud network
• This integration can be useful or desirable for customers of the IaaS provider in some cases such as a case that may desire support when executing code.
• the customer may provide code to run that may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects.
• the IaaS provider may determine whether to run code given to the IaaS provider by the customer. [0227]
• the customer of the IaaS provider may grant temporary network access to the IaaS provider and request a function to be attached to the data plane tier app 1046. Code to run the function may be executed in the VMs 1066(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 1018.
• a secure host tenancy 1104 e.g. the secure host tenancy 804 of FIG. 8
• a secure host subnet 1108 e.g. the secure host subnet 808 of FIG.8
• the VCN 1106 can include an LPG 1110 (e.g. the LPG 810 of FIG. 8) that can be communicatively coupled to an SSH VCN 1112 (e.g. the SSH VCN 812 of FIG.8) via an LPG 1110 contained in the SSH VCN 1112.
• the SSH VCN 1112 can include an SSH subnet 1114 (e.g.
• the SSH subnet 814 of FIG.8), and the SSH VCN 1112 can be communicatively coupled to a control plane VCN 1116 (e.g. the control plane VCN 816 of FIG. 8) via an LPG 1110 contained in the control plane VCN 1116 and to a data plane VCN 1118 (e.g. the data plane 818 of FIG.8) via an LPG 1110 contained in the data plane VCN 1118.
• the control plane VCN 1116 and the data plane VCN 1118 can be contained in a service tenancy 1119 (e.g. the service tenancy 819 of FIG.8).
• the control plane VCN 1116 can include a control plane DMZ tier 1120 (e.g.
• User interface input devices may also include, without limitation, three dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, and audio/visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode reader 3D scanners, 3D printers, laser rangefinders, and eye gaze tracking devices. Additionally, user interface input devices may include, for example, medical imaging input devices such as computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasonography devices. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments and the like.
• Computer-readable storage media 1222 may include, but is not limited to, Zip® drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tape, and the like.
• Computer-readable storage media 1222 may also include, solid-state drives (SSD) based on non-volatile memory such as flash-memory based SSDs, enterprise flash drives, solid state ROM, and the like, SSDs based on volatile memory such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory based SSDs.
• SSD solid-state drives
• volatile memory such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory based SSDs.
• Computer system 1200 can be one of various types, including a handheld portable device (e.g., an iPhone® cellular phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.
• a handheld portable device e.g., an iPhone® cellular phone, an iPad® computing tablet, a PDA
• a wearable device e.g., a Google Glass® head mounted display
• PC personal computer system
• workstation e.g., a workstation
• mainframe e.g., a mainframe
• a kiosk e.g., a server rack
• server rack e.g., a server rack

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Computer And Data Communications (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=85322082

Family Applications (1)

Country Status (3)

Families Citing this family (2)

Family Cites Families (5)

• 2022
  • 2022-04-12 EP EP22720856.8A patent/EP4392860A1/en active Pending
  • 2022-04-12 JP JP2024513031A patent/JP7822465B2/ja active Active
  • 2022-04-12 WO PCT/US2022/024481 patent/WO2023027775A1/en not_active Ceased

Also Published As

Similar Documents

Legal Events