Techniques for detecting drift in deployment orchestrators

Abstract

Techniques for implementing an infrastructure orchestration service are described. A security plan can be received that includes a list of resources and operations based at least in part on a deployment profile. Upon receiving approval of the security plan, an operation corresponding to at least one resource in the list of resources can be prepared for execution. The operation can be compared to the security plan. If the operation is part of the security plan, the operation can be executed. If the operation is not part of the security plan, the deployment can be stopped and a notification can be transmitted that the deployment does not comply with the security plan.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of and priority under 35 U.S.C. §119(e) to U.S. application No. 62 / 963,413, filed on January 20, 2020, entitled “TECHNIQUES FOR DETECTING DRIFT IN A DEPLOYMENT ORCHESTRATOR,” U.S. application No. 17 / 027,527, filed on September 21, 2020, entitled “TECHNIQUES FOR DETECTING DRIFT IN ADEPLOYMENT ORCHESTRATOR,” and U.S. application No. 17 / 027,507, filed on September 21, 2020, entitled “TECHNIQUES FOR MANAGING DRIFT IN A DEPLOYMENT ORCHESTRATOR,” the contents of which are incorporated herein by reference in their entirety for all purposes. Background Art

[0003] Today, cloud infrastructure services utilize many individual services to provision and deploy code and configuration across the cloud infrastructure service's many regions. These tools require significant manual effort to use, especially considering that provisioning is typically declarative while deployment requires code. Furthermore, cloud infrastructure services will need to continue to grow as the number of service teams and regions grows. Some cloud infrastructure services' strategy of deploying to a large number of smaller regions involves per-region expenditures, which may not scale well. Summary of the Invention

[0004] Techniques for implementing infrastructure orchestration services are described. In some examples, a security plan can be received that includes a list of resources and operations based at least in part on a deployment profile. Upon receiving approval of the security plan, an operation corresponding to at least one of the list of resources can be prepared for execution. The operation can be compared to the security plan. If it is determined that the operation is part of the security plan, the operation can be executed. If it is determined that the operation is not part of the security plan, the deployment can be stopped and a notification can be transmitted that the deployment does not comply with the security plan. In some examples, if drift has occurred, the operation may not be part of the security plan.

[0005] In other examples, a computer-readable storage medium may include instructions that, when executed by a processor, cause the processor to perform various operations described herein. A security plan may be received, the security plan including a list of resources and operations based on a deployment profile. Approval of the security plan may be received. Preparations may be made to perform an operation associated with at least one of the list of resources based on the deployment profile. The operation may be compared to the security plan. If it is determined that the operation is part of the security plan, the operation may be performed. If it is determined that the operation is not part of the security plan, the deployment may be stopped and a notification may be transmitted that the deployment does not comply with the security plan.

[0006] In another example, a system may include a processor and a memory capable of storing instructions that, when executed by the processor, may configure the system to perform the operations described herein. A security plan may be received, the security plan including a list of resources and operations based at least in part on a deployment profile. Approval of the security plan may be received. Based on the approval, preparations may be made to perform an operation corresponding to at least one of the list of resources. The operation may be compared to the security plan. If it is determined that the operation is part of the security plan, the operation may be performed. If it is determined that the operation is not part of the security plan, the deployment may be stopped and a notification may be transmitted that the deployment does not comply with the security plan.

[0007] In other examples, a method may include receiving, by at least one of a plurality of computer processors, a security plan that includes a list of resources and corresponding operations based at least in part on a deployment profile. The method may further include, based on receiving an indication of approval of the security plan: preparing, by at least one of the plurality of computer processors, to perform an operation corresponding to at least one of the list of resources based on the deployment profile. The method may further include comparing the operation to the security plan. The method may further include, based on determining that the operation is part of the security plan, executing, by at least one of the plurality of computer processors, the operation. The method may further include, based on determining that the operation is not part of the security plan: stopping, by at least one of the plurality of computer processors, the deployment; and transmitting, by at least one of the plurality of computer processors, a notification that the deployment does not comply with the security plan.

[0008] In other examples, a computer-readable storage medium may include instructions that, when executed by a processor, cause the processor to perform various operations described herein. The operations may include receiving a security plan that includes a list of resources and corresponding operations based at least in part on a deployment profile. The operations may also include, upon receiving an indication of approval of the security plan: preparing to perform an operation corresponding to at least one of the list of resources based on the deployment profile; and comparing the operation to the security plan. The operations may also include, upon determining that the operation is part of the security plan, executing the operation. The operations may also include, upon determining that the operation is not part of the security plan: stopping the deployment; and transmitting a notification that the deployment does not comply with the security plan.

[0009] In other examples, a system may include a processor and a memory that may store instructions that, when executed by the processor, may configure the system to perform the operations described herein. The operations may include receiving a security plan that includes a list of resources and corresponding operations based at least in part on a deployment profile. The operations may also include: based on receiving an indication of approval of the security plan: preparing to perform an operation corresponding to at least one of the list of resources based on the deployment profile. The operations may also include comparing the operation to the security plan. The operations may also include, based on determining that the operation is part of the security plan, performing the operation. The operations may also include, based on determining that the operation is not part of the security plan: stopping the deployment; and transmitting a notification that the deployment does not comply with the security plan.

[0010] An apparatus comprising means for performing the steps according to any of the methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To easily identify the discussion of any particular element or act, the most significant digit(s) in a reference number refers to the figure number in which the element is first introduced.

[0012] Figure 1 is a block diagram of an architecture for implementing at least some elements of cloud infrastructure orchestration services, according to at least one embodiment.

[0013] Figure 2 is a block diagram of an architecture for implementing at least some elements of cloud infrastructure orchestration services, according to at least one embodiment.

[0014] Figure 3 is a flow diagram illustrating an example flock in accordance with at least one embodiment.

[0015] Figure 4 is a flow diagram illustrating an example cluster in accordance with at least one embodiment.

[0016] Figure 5 is a block diagram of a cloud infrastructure orchestration service according to at least one embodiment.

[0017] Figure 6 is a flow chart describing a process for using a security plan in a cloud infrastructure orchestration service, according to at least one embodiment.

[0018] Figure 7 is a flow chart describing a process for generating a security plan in a cloud infrastructure orchestration service, according to at least one embodiment.

[0019] Figure 8 is a swim lane diagram describing how to generate and use a security plan, according to at least one embodiment.

[0020] Figure 9 is a block diagram of a disconnected region according to at least one embodiment.

[0021] Figure 10 is a flow chart describing a process for using a security plan in a disconnected area, according to at least one embodiment.

[0022] Figure 11 is a block diagram of a distributed system according to at least one embodiment.

[0023] Figure 12 is a block diagram of one or more components of a system environment according to at least one embodiment through which services provided by one or more components of an embodiment system may be provided as cloud services.

[0024] Figure 13 is a block diagram of an example computer system in which various embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION

[0025] In some examples, 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 some examples, IaaS is one of three main categories (or subcategories) of cloud computing services. Most people consider the other main categories to be Software as a Service (SaaS) and Platform as a Service (PaaS), and sometimes SaaS can be considered a broader category that encompasses both PaaS and IaaS, with some even considering IaaS to be a subcategory of PaaS.

[0026] In the IaaS model, a cloud computing provider may host infrastructure components (eg, servers, storage devices, network nodes (eg, hardware), deployment software, platform virtualization (eg, hypervisor layer), etc.).

[0027] In some cases, IaaS providers may also offer various services to accompany those infrastructure components (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) Therefore, since these services can be policy-driven, IaaS users can be able to implement policies that drive load balancing to maintain application availability and performance.

[0028] In some cases, 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) in each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software into that VM. The customer can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application issues, monitoring performance, managing disaster recovery, and more.

[0029] In most cases, the cloud computing model will require the involvement of a cloud provider. A cloud provider can be, but is not necessarily, a third-party provider that specializes in providing (e.g., selling) IaaS services. An entity may also choose to deploy a private cloud and become its own infrastructure service provider.

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

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

[0032] In some cases, there are two distinct problems with IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before anything is running. Second, once everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both of these challenges can be addressed by enabling the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., which components are required and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which other resources, and how they each work together) can be described declaratively. In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

[0033] In some examples, the infrastructure can have many interconnected elements. For example, there can be one or more virtual private clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shared computing resources), also referred to as a core network. In some examples, there can also be one or more security group rules that are provided to define how to set up security for the network, as well as one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, etc., can also be provided. As more and more infrastructure elements are desired and / or added, the infrastructure can evolve gradually.

[0034] As mentioned above, one way to provision infrastructure is to describe it declaratively. As such, a configuration file can be a declarative document that simply describes each of the aforementioned infrastructure components and how they interact. The configuration file can describe the resources and associated fields required to create an element, and then can describe other elements that reference previously described elements. In some examples, a provisioning tool can then generate workflows for creating and managing the elements described in the configuration file.

[0035] In some cases, the workflow of the provisioning tool can be configured to execute various commands. One function that can be performed is view reconciliation, in which the provisioning tool can compare a view of the current infrastructure (e.g., the expected state of the infrastructure) with how the infrastructure is actually operating. In some cases, performing the view reconciliation function can include querying various resource providers or infrastructure resources to identify which resources are actually running. Another function that the provisioning tool can perform is plan generation, in which the provisioning tool can compare the infrastructure components that are actually running with what the provisioning tool wants the state to look like (e.g., the desired configuration). In other words, the plan generation function can determine what changes need to be made to bring the resources up to the latest expectations. In some cases, a third function is an execution (e.g., apply) function, in which the provisioning tool can execute the plan generated by the plan generation function.

[0036] Generally speaking, the provisioning tool can be configured to take a configuration file, parse the declarative information included therein, and programmatically / automatically determine the order in which resources need to be provisioned to execute the plan. For example, if a VPC needs to be started before security group rules and VMs are started, the provisioning tool will be able to make that determination and implement the startup in that order without requiring user intervention and / or having to include that information in the configuration file.

[0037] In some cases, continuous deployment techniques can be employed to enable deployment of infrastructure code across a variety of virtual computing environments. In addition, the described techniques can enable infrastructure management in these environments. In some examples, a service team can write code that is intended to be deployed to one or more (but often many) different production environments (e.g., across a variety of geographical locations, sometimes across the entire world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning can be done manually, a provisioning tool can be used to provision resources, and / or a deployment tool can be used to deploy the code once the infrastructure has been provisioned.

[0038] As mentioned above, two different tools are typically used to handle the provisioning of infrastructure resources and the deployment of the code that controls them, with orchestration between these two tools performed manually. However, at scale, manual implementations often lead to discrepancies. Therefore, automated tools that can both provision and deploy virtual infrastructure enable the implementation of virtual cloud environments with more efficient and reliable technology.

[0039] In some examples, when using two tools, problems arise when users manually make changes to the code between the provisioning and deployment phases. As described herein, techniques for provisioning and deploying using a single tool can alleviate this situation by automating the process, eliminating the need for manual code changes. It is possible that a slight change to the way a user codes can cause significant problems during the deployment phase. In some examples, the first time an operator performs an action in a new area (e.g., a typo in the code), the object coded using the typo may remain that way forever. If an application is deployed using that typo, and the application is not sensitive to that typo (e.g., it still works), it is possible that at some later time, additional code changes will become sensitive to that typo and cause the entire system to crash. Therefore, the techniques provided herein can eliminate the gap between provisioning and deployment that often leads to problems.

[0040] Generally speaking, modeling deployments is declarative, such that configuration files can be used to declare infrastructure resources. For example, create, read, update, delete (CRUD) instructions are typically used to generate deployment files using general Representational State Transfer (REST) ​​concepts (e.g., REST application programming interfaces (APIs)). However, deployments themselves generally do not follow the same concepts. Furthermore, while infrastructure provisioning tools tend to be very powerful and / or expressive, tools for deployment tend to be more restrictive about the operations they can perform (e.g., they are imperative rather than declarative). Therefore, there has long been a need for a tool that can handle both functional requirements (e.g., provisioning and deployment of infrastructure elements) in cloud environments.

[0041] In some examples, this document describes techniques for implementing a cloud infrastructure orchestration service (CIOS). As briefly described above, such techniques can be configured to manage the provisioning and deployment of infrastructure assets within a cloud environment. In some cases, a CIOS can include two types of services: central and regional components (e.g., a CIOS hub and a CIOS region).

[0042] The following terms will be used throughout this document:

[0043] Infrastructure components - the long-lived infrastructure that supports running code.

[0044] Examples: Deploying applications, load balancers, Domain Name System (DNS) entries, object storage buckets, etc.

[0045] Artifacts - Configuration information (hereafter referred to as "configurations") that is deployed to a deployment application or Kubernetes engine cluster, or applied to infrastructure components. These can be read-only resources.

[0046] Deployment tasks - short-lived tasks often associated with deploying or testing code. Additionally, deployment tasks are modeled as resources whose lifetime does not exceed the release that created them.

[0047] о Examples: "Deploy $artifact to $environment", "Observe $alarm for 10 minutes", "Execute $testSuite", or "Wait for $manualApproval"

[0048] o For example, CIOS can model a deployment orchestrator deployment as the creation of resources that transition to a usable state upon completion.

[0049] Because the CIOS maintains the state of its associated declarative provisioners, the CIOS can control the lifecycle of these short-lived resources as it relates to releases.

[0050] Resources - CRUDable resources.

[0051] CIOS models each of the constructs listed above as a resource. This modeling is discussed in detail in the next section.

[0052] Flock - CIOS's only control plane resource. Primarily used to model ownership of infrastructure components and to point to infrastructure components.

[0053] Cluster configuration - describes the collection of all infrastructure components, artifacts, and deployment tasks associated with a single service.

[0054] Each swarm has only one swarm configuration. The swarm configuration is checked into source control.

[0055] Cluster configurations are declarative. They expect CIOS to provide realm, region, AD, and artifact version as input.

[0056] o Clusters are fine-grained - a cluster consists of a single service and supporting infrastructure.

[0057] State - A point-in-time snapshot of the state of each resource in the swarm.

[0058] Release - A tuple of a specific version of the swarm configuration and a specific version of each artifact it references.

[0059] o Think of a release as describing a state that may not yet exist.

[0060] Release Plan - The set of steps that CIOS takes to transition all regions from their current state to the state described by the release.

[0061] о Release plans have a finite number of steps and clearly defined start and end times.

[0062] Apply - This is a noun. A single attempt to execute a release plan. Execution changes the current state of the group.

[0063] CIOS can be described as the orchestration layer that applies configurations to downstream systems (e.g., globally). It is designed to allow infrastructure provisioning and code deployment on a global scale without requiring manual effort from service teams (e.g., beyond initial approval in some cases). High-level responsibilities of CIOS include, but are not limited to:

[0064] Provide teams with a view into the current state of resources managed by CIOS, including any ongoing change activities.

[0065] ·Help the team plan and release new changes.

[0066] ·Coordinate activities across various downstream systems within the region to execute approved release plans without manual intervention.

[0067] ·Coordinate activities across regions / areas to execute approved release plans globally.

[0068] In some examples, a CIOS handles the bootstrapping process by enabling teams to provide configuration information to the CIOS via code check-ins. Furthermore, a CIOS can automate more tasks, making it less onerous than previous implementations. In some cases, a CIOS handles pre-deployment by providing teams with the ability to automatically deploy and test code. In some cases, a CIOS can handle the writing of change management (CM) policies by automatically generating plans for rolling out new artifacts (e.g., globally) as teams build them. This can be done by checking the current state of each region and the current CIOS configuration (which can itself be an artifact). Furthermore, teams can review these plans and iterate on them by changing the CIOS configuration and requesting the CIOS re-plan. Once the team is satisfied with the plan, they can create a "release" that references the plan. The plan can then be marked as approved or rejected. While teams can still write CMs, they are simply pointers to the CIOS plan. Therefore, teams can spend less time reasoning about the plan. Plans are more accurate because they are machine-generated. Plans are often too detailed for human consumption; however, they can be displayed via a sophisticated user interface (UI).

[0069] In some examples, the CIOS can handle the execution of CM by automating the execution of deployment plans. Once a release plan is created and approved, engineers will no longer be involved in CM unless the CIOS initiates a rollback. In some cases, this may require the team to automate tasks that are currently manual. In some examples, when the CIOS detects that the health of a service has degraded while executing, the CIOS can handle rolling back change management (CM) by automatically generating a plan to return the cluster to its original (e.g., pre-release) state. In some examples, the CIOS can handle deployment emergencies / tactical changes by receiving a release plan scoped to a subset of resources and / or regions managed by the CIOS and then executing that plan.

[0070] In addition, CIOS can support the primitives necessary to define fully automated global deployments. For example, CIOS can measure service health by monitoring alerts and executing integration tests. CIOS can help teams quickly define rollback behavior in the event of service degradation and then automatically execute it. CIOS can automatically generate and display release plans and can track approvals. In some cases, the language used by teams to describe the desired deployment behavior can be declarative. CIOS can combine the functionality of code deployment and infrastructure configuration (e.g., provisioning) in a single system. CIOS also supports flexible sequencing of components across regions and within regions. Teams can express sequencing via check-in configurations. Teams can programmatically call CIOS's planning and release APIs.

[0071] Figure 1 An architecture 100 is depicted for illustrating techniques for implementing at least a CIOS center 102. In some examples, the CIOS center 102 can be a service that handles "cluster" level operations. The CIOS center 102 has several responsibilities, including but not limited to:

[0072] Serves as an authentication gateway for group metadata change and publish operations.

[0073] Stores the authoritative mapping of cluster metadata to the deployment artifacts and CIOS repositories for the cluster.

[0074] Coordinate global releases across phases and goals.

[0075] Synchronize to enforce policies such as "no more than one in-progress publication can be published to the group at a time."

[0076] Detect changes to group configuration (configuration) and artifacts and trigger release builds upon such changes.

[0077] In some examples, the source code version control management service (SCVMS) 104 can be configured to store the authoritative group configuration, and the CIOS center 102 can subscribe to the artifact notification service (ANS) 106 so that the CIOS center 102 can be notified of new artifact builds. The CIOS center 102 can then map the incoming changes to the affected groups and initiate a release plan where desired. In addition, in some examples, the artifact push service (APS) can be called by the CIOS center 102 before publishing to the target to ensure that any artifacts required for a successful release are present in the target's area before publishing.

[0078] In some examples, a customer (e.g., an engineer) 108 can call CIOS Hub 102 to CRUD groups and / or releases and view the status of ongoing CIOS activities. Group Management Service 110 can include one or more APIs to manipulate groups, Review / Plan / Approve Service 112 can include CRUD APIs to create and approve plans, and view a central copy of the status of all CIOS-managed resources, Change Monitoring Service 114 can monitor SCVMS 104 for changes to group configurations and can receive notifications from ANS 106 about changes to other artifacts, and State Ingestor Service 116 can create a copy of the region state in CIOS Hub Database (DB) 118 so that Review / Plan / Approve 112 can expose it. In some examples, CIOS Hub DB 118 can be a DB for groups, plans, and states. Group information can be authoritative; everything else can be a stale copy of data from CIOS regions 120.

[0079] In some examples, an engineer 108 can make an API call to the cluster management service 110 (e.g., via the ingress proxy queue 122) to create a list of clusters. The protocol for making such an API call can be Hypertext Transfer Protocol Secure (HTTPS), among others. The associated access control list (ACL) for this operation can include a local area network (LAN) 124 or other private connection. For example, the CIOS can manage / control network connectivity, instead of using the public internet to connect the customer's local data center or network to the CIOS (e.g., a dedicated, leased, and / or private connection). Furthermore, authentication and authorization (e.g., of the engineer 108) can be performed by a reservation system portal (e.g., a reservation service) that allows users to manage machine infrastructure. In some cases, the CIOS hub 102 can use Java Database Connectivity (JDBC), among others, to store cluster metadata, plans, and status in a hub DB 118. In some examples, the ANS 106 can be configured to notify the change monitoring service 114 when new artifacts have been published. The ANS 106 can use HTTPS, and both authentication and authorization can be handled by the mutual transport layer security service. In addition, in some cases, the change monitoring service 114 can poll the SCVMS 104 for group configuration changes. This polling can be performed using Secure Shell (SSH) or other protocols. Authentication for the change monitoring service 114 can be handled by the CIOS system account, and authorization can be handled by the SCVMS 104.

[0080] In some examples, engineers 108 can use the review / plan / approve service 112 to perform one or more of the following operations. Engineers 108 can plan and / or approve by calling CIOS hub 102 to generate and approve a plan. Engineers 108 can view the status of ongoing CIOS activities globally by calling CIOS hub 102. In addition, engineers 108 can call CIOS hub 102 to view a copy of the global CIOS management resource status. These API calls (etc.) can be executed via the HTTPS protocol or similar protocols. In addition, relevant ACLs can be controlled by LAN 124, and authentication and authorization can be handled by the subscription service. In some examples, the review / plan / approve service 112 can request a plan and push plan approvals to all areas of the CIOS region 120 (e.g., using HTTPS, etc.). Relevant ACLs can be controlled using security lists managed by the wide area network (WAN) gateway 126. Authentication can be handled by mutual transport layer security and authorization can be handled by various identity policies. Additionally, the state ingestor service 116 can monitor the operational state or state changes of the CIOS regions 120 so that the CIOS can provide a central view of them upon request (e.g., also using HTTPS, etc.) The ACLs used for this can also be handled by the WAN gateway 126, and both authentication and authorization can be handled by the mutual transport layer security service.

[0081] Figure 2 An architecture 200 is depicted illustrating techniques for implementing at least a CIOS region 202. In some examples, a CIOS region 202 is where much of the work of declarative provisioning and planning, as well as approved release applications, can occur. In some cases, each instance of a CIOS region 202 can have a region frontend that can handle "execution target" level operations. It can be configured to do the following:

[0082] Handles all CIOS authentication for incoming operations from CIOS Center 102.

[0083] Enforce the rule that only one "execution" (plan / import resource / apply plan) can be in progress at a time for a given execution target.

[0084] A binary artifact store that manages declarative provisioning artifacts used for input and output during a declarative infrastructure provisioning execution. Examples of inputs are declarative infrastructure provisioning configuration files and input state files. A typical output is a final state file.

[0085] Request work from the CIOS executor and poll the results of any given execution.

[0086] In some cases, the CIOS frontend can rely on the CIOS executor, which can handle the actual execution. In some examples, the CIOS executor runs at the "execution" level and can:

[0087] Tracks the pool of available worker nodes

[0088] Query incoming work requests and assign them to eligible workers when available

[0089] Tracking worker status and performing updates to report to clients

[0090] Dead nodes are detected via the lease protocol, and depending on the task status, tasks assigned to the dead node may fail.

[0091] Provide facilities to cancel / kill / pause / resume execution, and those can be mapped onto facilities to pass cancel / kill / resume information to worker nodes.

[0092] In some cases, CIOS executors can depend on CIOS workers, which can assign tasks to workers and provide facilities for workers to update their progress. The worker service operates at the granularity of "tasks". Each worker is an agent that executes the tasks assigned to it and reports the task status and output. Each worker can:

[0093] Polls the executor worker API for assigned work items and takes action to make the assigned state match its local state:

[0094] оStart a container to poll for tasks that do not exist locally

[0095] Kill the container, which is used to run the container locally without a corresponding task item.

[0096] Reporting on the status of work

[0097] Stage inputs and outputs for job container execution

[0098] Launch and monitor declarative infrastructure provisioning containers to do the actual work of executing releases against execution targets.

[0099] CIOS workers can rely on the CIOS executor to poll work from the CIOS executor's worker endpoint and report results to it. Workers can rely on the executor for all coordination. In addition, CIOS workers can also rely on CIOS regions 202, where worker services read input from and write output to one or more APIs associated with the region front-end service. Examples of inputs are configuration and startup state files and import maps. Examples of outputs are declarative provisioning processes, output declarative provisioning state files, and import result states.

[0100] In some examples, CIOS region 202 may be a regional service for managing regional instances / deployments of CIOS. CIOS region 202 is responsible for authoritatively storing and managing plans and statistics related to a specific region. Region DB 204 may be a CIOS DB for status and plans in a specific region. This is Figure 1 The CIOS region 202 may be an authoritative copy of a subset of the central DB 118 of the CIOS. The scheduler 206 may be responsible for managing worker queue capacity, assigning tasks to workers, and tracking task status. In some cases, the task DB 208 is another CIOS DB for task status. The data in this DB is primarily used for operational purposes. Additionally, the workers 210 may be a queue of Java Virtual Machines (JVMs) that manage declarative provisioned images. They receive instructions from the scheduler 206 and pass results to both the scheduler 206 and the CIOS region 202. The CIOS container 212 may run declarative provisioning operations in its own private dock 214 container. This container does not need to contain secrets. Additionally, in some examples, the signing agent 216 may be configured to prevent secrets from being leaked via the declarative provisioning tool in order to avoid placing secrets into the declarative provisioning image. Alternatively, the CIOS may perform request signing or initiate mutual transport layer security (mTLS) services in the agent. This also makes it easier to use FIPS-compliant cryptographic libraries.

[0101] In some examples, the CIOS hub 102 can call the CIOS region 202 to create plans, push approvals, view job status (service principal), and extract declarative provider status (service principal). The ingress agent 218 can be configured with ACLs and various identity policies can be used for authentication and authorization. In some cases, the CIOS region 202 can run a declarative provider by asking the scheduler 206 to do so. The worker 210 can ask the scheduler 206 what it should run and can report the status to the scheduler 206 when it is completed. In some cases, mTLS can handle authentication and authorization for both the CIOS region 202 and the worker 210. In addition, when the worker 210 needs to run a declarative provider, it does this in a dock container by interacting with the local dock 214. Authentication at this stage can be handled by a local unix socket. The last step can use the dock protocol; however, HTTPS can be used for the previous ones.

[0102] In some examples, the CIOS container 212 enables the declarative provider to interact with the signing agent 216 (via an API), while the declarative provider believes it is calling various CIOS services. The signing agent 216 listens on an ephemeral port for each call instance of the declarative provider, known only to that declarative provider. The signing agent 216 can initiate request signing or mTLS and can pass the declarative provider's call to other CIOS services within the service enclave. In some cases, the signing agent 216 can also communicate with one or more public CIOS services 220. For example, the signing agent 216 will use the internal endpoints of public services when possible. For services without internal endpoints, it must use the egress agent 222 to reach the external endpoint. This use of the signing agent 216 cannot be used for cross-region communication; for example, the egress agent whitelist in each region may apply only to the public IP range of that region. In some examples, the worker 210 can then persist the state and logs from the declarative provider in the CIOS region 202 so that they can be leaked to the CIOS hub 102.

[0103] With CIOS, there are several phases of a typical customer experience: onboarding, pre-release, global release, and tactical release. For the pre-release phase, here's an example of what happens between building new artifacts and publishing them for a release (e.g., R1). This should replace some or most of the current change management process. As relevant artifacts are built, CIOS can automatically generate releases using the "latest version of everything in the cluster." A release is a specific version of the cluster configuration with specific inputs (e.g., artifact version, realm, region, and AD). A release contains a rollout plan for each region and metadata describing the region ordering. Each region plan is a set of actions that the declarative provisioner will take to implement the cluster configuration in that region. Teams with pre-release environments can use CIOS to automatically release and test software in those environments. Teams can configure CIOS to automatically test rollback plans. Teams will be able to review and approve releases through the CIOS UI. Teams can approve some, but not all, region plans in a release. If the "latest version of everything" doesn't produce a suitable plan, teams can request CIOS to generate plans for a curated artifact version.

[0104] For the global release phase, here's an example of how a team might execute tomorrow's release from today's "normal CM." Once the release is approved, CIOS pushes each approved regional plan to the corresponding region. CIOS acts independently within each region to apply the approved plan. CIOS will only execute the set of actions explicitly described in that region's plan. It's not "independent thinking," and it can fail. The CIOS UI shows the team the progress of the execution. When manual approval is required, the CIOS UI prompts the team. If the execution fails due to a CIOS or downstream service outage, CIOS can notify the team and prompt them to perform subsequent steps (e.g., abort, retry). CIOS does perform retries, but some downstream system outages may exceed its willingness to retry. If the execution fails due to service health degradation or test failures, CIOS will assist the team in rolling back the cluster to its starting state. CIOS will notify (e.g., page) the team when it initiates an automatic rollback. The team must approve the rollback plan, and then CIOS will execute it.

[0105] For the tactical release phase, here's an example of how a team might execute tomorrow's release of "urgent CM." When generating a plan, a team can request that CIOS target specific resources in several ways: by topology (e.g., domain, region, AD, etc.), by resource type (e.g., "metrics configuration only" or "deployment orchestration service deployment only," etc.), or a combination of the above (e.g., in a decoupled fashion). Teams approve tactical releases just like global releases. CIOS orchestrates them in a similar manner. If a team needs to deploy a tactical release while there is an active global release, CIOS will stop executing the global release in the target region and then start executing the tactical release.

[0106] In some examples, the state of a declarative provider (e.g., traditionally a file) is the authoritative record of the set of resources managed by the declarative provider. It contains a mapping between the logical identifier of each resource from the configuration and the actual identifier of the resource. When a declarative provider creates a resource, certain types of failures can prevent the actual identifier from being recorded in the state. When this happens, the actual identifier no longer belongs to the declarative provider. These can be referred to as "orphan resources."

[0107] For most resources, orphans represent waste—the declarative provisioner started an instance that it forgot about (for example), but will start another instance the next time it runs. For resources with unique constraints or client-supplied identifiers, orphans prevent the declarative provisioner from making progress. For example, if the declarative provisioner created the user "nglass" and a failure orphaned it, the next run of the declarative provisioner will try to create "nglass" and fail because a user with that username already exists. In some cases, orphans are only a problem when adding new resources to the state. In some cases, the refresh behavior of the declarative provisioner can naturally recover from failures to record updates and deletions.

[0108] A CIOS needs to be robust in the face of outages in downstream services or in the CIOS itself. Because a CIOS can make full use of declarative provisioners to apply changes, this means that running declarative provisioners and maintaining the state of declarative provisioners should be robust. Declarative provisioners perform "small-scale" retries - enough to survive outages lasting a few minutes. For example, a cloud provider will retry for up to 30 minutes. An outage in downstream systems that lasts more than 30 minutes will cause the declarative provisioner to fail. When a declarative provisioner fails, it records all the changes it successfully made in the state and then exits. In order to retry, the CIOS must re-execute the declarative provisioners. Re-executing declarative provisioners also allows the CIOS to retry if the CIOS itself fails. In some cases, the CIOS can run the following operations in a loop:

[0109] • Refresh - The declarative provider calls the GET API to retrieve a new snapshot of each resource described in its state.

[0110] • Plans - Declarative providers generate plans (specific sets of API calls) that will achieve the desired state given the most recently refreshed current state.

[0111] • Apply - A declarative provider executes the set of steps in a plan.

[0112] When executing a declarative provisioner, CIOS can always run all three steps. The refresh operation helps recover from any updates or deletes that were not recorded. CIOS checks the results of the planned operations and compares them to the approved release plan. If the newly generated plan contains operations that are not in the approved release plan, CIOS will fail and can notify the service team.

[0113] Figure 3 A directed acyclic graph (DAG) 300 is depicted for illustrating an example cluster 302. For a single cluster configuration in CIOS, the progress of code / configuration from check-in to production can be described all the way from the first test deployment to the last production deployment. Internally, CIOS refers to each element in the progress as an execution target (ET), which is used throughout our internal API but does not leak into the cluster configuration. CIOS executes ETs based on the DAG 200 defined in the cluster configuration. Each ET (e.g., ET-1, ET-2, ET-3, ET-4, ET-5, ET-6, and ET-7) is roughly a copy of the service described by the cluster configuration.

[0114] Figure 4 Depicted is a DAG 400 and example swarm 402 for illustration. In a swarm configuration, CIOS is very opinionated about how teams express this progress - they must model it using cloud infrastructure tenancies and regions. Teams should not use domains to model progress. CIOS allows teams to use multiple tenancies within a domain and multiple regions within a tenancy. However, CIOS does not allow teams to use the same region twice within a lease (but they can use the same region twice within a domain - in different leases). DAG 400 illustrates Figure 3 The release of DAG 300 in

[15] is represented by lease and region. This example is for an overlay service, where the pre-prod ET is located in the prod region. The service enclave service will have unstable and stable leases in release one. In DAG 400, IAD is the regional airport code for Washington, D.C. Dulles Airport, YYZ is the regional airport code for Toronto, Ontario, PHX, LHR, and FRA are the regional airport codes for Phoenix, London, and Frankfurt, respectively, and LUF and LFI are for two different Air Force bases.

[0115] In one embodiment, the CIOS and / or other techniques described herein are improvements to each of Terraform (a declarative provisioning tool), Tanden (a code generation tool), and Oracle Deployment Orchestrator (ODO). Furthermore, in some examples, the CIOS and / or other techniques described herein can be implemented using at least a portion of the Terraform, Tanden, and ODO tools.

[0116] In some examples, a security plan can be generated to safely handle drift. A configuration file can include information instructing the CIOS on how to make changes to a region (e.g., a geographic region where the cloud infrastructure will (or has) been deployed). The CIOS can verify that what has been reviewed by the client as a set of changes (e.g., the delta between the current state of the cloud infrastructure and the expected new state after the change) is actually modified in that region. When the client interacts with the CIOS to trigger a global plan, the security plan determines what changes the CIOS will make based on the current world (e.g., the current state) to reach the world file described in the configuration (e.g., the target state). As described herein, "world" can refer to the expected state of the cloud infrastructure, including all settings and configurations of the cloud setup. In some cases, drift refers to the idea that one or more device configurations / settings may have changed (e.g., a virtual machine may have been shut down, etc.) between the time the plan is generated and the time the deployment of the region is initiated. Such a change is drift. The CIOS can develop a security plan and ship it to various regions around the world (e.g., to different CIOS regions). The plan task can be repeated any time the CIOS is about to implement a change. For example, the current state can be projected and compared to the target state, and a difference (e.g., delta, difference, etc.) between the two can be generated. If the difference is a subset of the security plan, then no drift has occurred and the security plan can still be implemented. Otherwise, a problem with the security plan has been detected and needs to be changed before deployment. In addition, in some examples, the CIOS can compare different security plans (e.g., to handle phase changes). For example, for a phased deployment (e.g., deploying resources to phase one before other phases), the security plan can be reviewed and approved, and the deployment can then proceed. Then, later, for phase two deployment, a new security plan can be generated and compared to the first security plan. If the new security plan is a subset of the first security plan, the new security plan can be automatically approved without even sending anything to the client that generated the configuration file. It will be appreciated that this can speed up the deployment process because no delays are introduced while waiting for approval of the new security plan, while also maintaining the integrity of the deployment because no drift has occurred in these cases. Alternatively, if there is something novel in the new security plan (e.g., something that was not present in the first security plan), this novel aspect can be presented to the user (e.g., client) via a user interface (UI). The user can then approve or reject the novel aspect (e.g., enable or disallow the deployment change).

[0117] Techniques for implementing infrastructure orchestration services are described. In some examples, a security plan can be received that includes a list of resources and operations based at least in part on a deployment profile. Upon receiving approval of the security plan, an operation corresponding to at least one of the list of resources can be prepared for execution. The operation can be compared to the security plan. If the operation is determined to be part of the security plan, the operation can be executed. If the operation is determined not to be part of the security plan, the deployment can be stopped and a notification can be transmitted that the deployment does not comply with the security plan. In some examples, if drift occurs, the operation may not be part of the security plan.

[0118] In other examples, a computer-readable storage medium may include instructions that, when executed by a processor, cause the processor to perform various operations described herein. A security plan may be received, the security plan including a list of resources and operations based on a deployment profile. Approval of the security plan may be received. Preparations may be made to perform an operation corresponding to at least one of the list of resources based on the deployment profile. The operation may be compared to the security plan. If it is determined that the operation is part of the security plan, the operation may be performed. If it is determined that the operation is not part of the security plan, the deployment may be stopped and a notification may be transmitted that the deployment does not comply with the security plan.

[0119] In another example, a system may include a processor and a memory that may store instructions that, when executed by the processor, may configure the system to perform the operations described herein. A security plan may be received that may include a list of resources and operations based at least in part on a deployment profile. Approval of the security plan may be received. Based on the approval, preparations may be made to perform an operation corresponding to at least one of the list of resources. The operation may be compared to the security plan. If it is determined that the operation is part of the security plan, the operation may be performed. If it is determined that the operation is not part of the security plan, the deployment may be stopped and a notification may be transmitted that the deployment does not comply with the security plan.

[0120] In other examples, a method may include receiving, by at least one of a plurality of computer processors, a security plan that includes a list of resources and corresponding operations based at least in part on a deployment profile. The method may further include, based on receiving an indication of approval of the security plan: preparing, by at least one of the plurality of computer processors, to perform an operation corresponding to at least one of the list of resources based on the deployment profile. The method may further include comparing the operation to the security plan. The method may further include, based on determining that the operation is part of the security plan, executing, by at least one of the plurality of computer processors, the operation. The method may further include, based on determining that the operation is not part of the security plan: stopping, by at least one of the plurality of computer processors, the deployment; and transmitting, by at least one of the plurality of computer processors, a notification that the deployment does not comply with the security plan.

[0121] In other examples, a computer-readable storage medium may include instructions that, when executed by a processor, may cause the processor to perform various operations described herein. The operations may include receiving a security plan that includes a list of resources and corresponding operations based at least in part on a deployment profile. The operations may also include, based on receiving an indication of approval of the security plan: preparing to perform an operation corresponding to at least one of the list of resources according to the deployment profile; and comparing the operation to the security plan. The operations may also include, based on determining that the operation is part of the security plan, performing the operation. The operations may also include, based on determining that the operation is not part of the security plan: stopping the deployment; and transmitting a notification that the deployment does not comply with the security plan.

[0122] In other examples, a system may include a processor and a memory that may store instructions that, when executed by the processor, may configure the system to perform the operations described herein. The operations may include receiving a security plan that includes a list of resources and corresponding operations based at least in part on a deployment profile. The operations may also include: based on receiving an indication of approval of the security plan: preparing to perform an operation corresponding to at least one of the list of resources according to the deployment profile. The operations may also include comparing the operation to the security plan. The operations may also include, based on determining that the operation is part of the security plan, performing the operation. The operations may also include, based on determining that the operation is not part of the security plan: stopping the deployment; and transmitting a notification that the deployment does not comply with the security plan.

[0123] Figure 55 is a block diagram 500 of a CIOS that can generate and use security plans according to at least one embodiment. In some examples, a security plan can be a collection of operations that have been approved by a user and can be executed by the CIOS. Block diagram 500 illustrates an example CIOS architecture that can include a central control plane 502 and regional data planes 504. The central control plane 502 can include a CIOS hub 506 (e.g., similar to a CIOS hub). Figure 1 The CIOS center 102 may include a control plane 508, a change management module 510, a review / plan / approve module 512, and a status ingestor 514. The control plane 508 and the review / plan / approve module 512 may be communicatively coupled to a local area network (LAN) gateway 516 that users 518 may use to communicate with the CIOS center 506. The review / plan / approve module 512 and the status ingestor 514 may be communicatively coupled to a wide area network (WAN) 520 (e.g., the Internet), which may be communicatively coupled to CIOS zones 522 (e.g., similar to the CIOS zones 522) contained in the regional data plane 504. Figure 1 CIOS area 120 or Figure 2 CIOS area 202).

[0124] CIOS zone 522 can be communicatively coupled to scheduler node 524 and worker node 526. Worker 526 can be communicatively coupled to scheduler 524, which can be communicatively coupled to task database (DB) 528. Worker 526 can be communicatively coupled to dock 530, which can include CIOS container 532. CIOS container 532 can be communicatively coupled to signing agent 534, which can be communicatively coupled to cloud service 536.

[0125] The CIOS region 522 can receive tasks from the CIOS hub 506 and transmit the tasks to a scheduler 524. Tasks can include performing CRUD operations at (one or more) execution targets or any other suitable tasks for deploying infrastructure resources in the region. The scheduler 524 can record the tasks in a task DB 528 and transmit the tasks to workers 526, which can be included in a worker queue. The worker queue can include many workers 526, and the scheduler 524 can select the worker 526 with the least workload or the most available computing resources to assign the task to. The scheduler 524 can assign one task to a worker 526 at a time. The worker 526 can execute the task, and when executing the task, the worker can call a CIOS container 532 included in the dock 530. The CIOS container 532 can execute tasks including infrastructure provisioning and / or deployment instructions (e.g., Terraform instructions). The instructions can direct API calls to cloud services 536, which can include services available in the region that may not be available via a public network (e.g., the internet). To make an API call to cloud service 536 , CIOS container 532 may transmit a request to make the API call to signing agent 534 , which may determine whether the request is valid. In response to determining that the request is valid, signing agent 534 may make the API call to cloud service 536 .

[0126] In some examples, a user 518 can create a configuration file that can include operations to be performed in the regional data plane 504. The user 518 can transmit the configuration file to the CIOS hub 506, which can be a computing device included in the central control plane 502, via the LAN gateway 516. The configuration file can be received by the CIOS hub 506 at the control plane 508 or at the review / plan / approval module 512. The change management module 510 can compile the configuration file into a region-agnostic (RA) configuration file that can be used at the regional data plane 504. The review / plan / approval module 512 or the state ingestor 514 can transmit the RA configuration file to the CIOS zone 522, which can be a computing device included in the regional data plane 504, via the WAN gateway 520.

[0127] The CIOS region 522 can receive the RA profile from the CIOS hub 506 and transmit the RA profile to the scheduler 524, which can create a task and transmit the task to the task DB 528. The task can include compiling a set of operations to be performed at the execution target and can include comparing the current state of the resources at the execution target with the desired state of the resources at the execution target. The task can be transmitted to the worker 526, which can execute the task. When executing the task, the worker 526 can help create a security plan, which is an approved set of operations. The operation can include deploying resources at the execution target or any other suitable operation to be performed at the execution target. The worker 526 can transmit the security plan to the CIOS region 522, which can transmit the security plan to the CIOS hub 506 via the WAN gateway 520.

[0128] The CIOS center 506 can receive the security plan from the CIOS region 522 and compare the change set included in the security plan with the operations at the execution target. The change management module 510 can perform this comparison and make one of two determinations: whether the operation is a subset of the change set in the security plan or whether the operation is not a subset of the change set in the security plan. While only these two determinations are described in detail, other determinations can also be made (e.g., the percentage difference between the change set and the security plan, etc.). In response to determining that the operation is a subset of the change set included in the security plan, the operation can be executed, which may include deploying resources at the execution target. In response to determining that the operation is not a subset of the change set included in the security plan, a notification can be sent to the user 518. This notification can be transmitted to the user 518 via the LAN gateway 516 and can include information alerting the user 518 that drift may have occurred or that the operations that can be scheduled for execution at the execution target may not be included in the security plan. In response to viewing the notification, the user 518 can approve or deny the operations that are not included in the security plan. If the user 518 approves the operations, the operations are executed and the resources can be deployed at the execution target. If user 518 rejects the operation, then the operation may not be performed, and user 518 may decide to create a new configuration file or may decide to abandon the operation. Thus, a security plan can be understood as a data structure that controls the operation of the processor(s) performing the deployment process by allowing the operation to be performed if the operation is a subset of the set of changes included in the security plan or suspending the execution of the operation if the operation is not a subset of the changes included in the security plan.

[0129] In another example, user 518 can create a set of configuration files that can include the desired state of resources for executing a set of goals at a set of zones. The configuration files can be transmitted to CIOS hub 506, which can compile the configuration files into a set of RA configuration files, including one RA configuration file for each zone. The RA configuration files can be transmitted to the corresponding zones via WAN gateway 520 and can be received by CIOS zones 522 included in the corresponding zones.

[0130] In the corresponding zone, the CIOS zone 522 can receive the corresponding RA profile from the CIOS center 506, and the CIOS zone 522 can transmit the corresponding RA profile to the scheduler 524, which can create a task and transmit the task to the task DB 528. The task may include compiling a set of operations to be performed at the execution target in the corresponding zone, and may include comparing the current state of the resources at the execution target with the expected state of the resources at the execution target. The task can be transmitted to the worker 526, which can execute the task. When executing the task, the worker 526 can help create a security plan, which is an approved set of operations. The operation may include deploying resources at the execution target or any other suitable operation to be performed at the execution target. The worker 526 can transmit the security plan to the CIOS zone 522, which can transmit the security plan to the CIOS center 506 via the WAN gateway 520.

[0131] The CIOS center 506 can receive a set of security plans from the regions and compile the security plans into a master security plan (e.g., a security plan of security plans), also referred to as a compiled security plan. Each security plan included in the compiled security plan can include similar changes. Differences in changes between the security plans included in the compiled security plans can indicate that drift has occurred in at least one region. The CIOS center 506 can compare the changes included in each security plan included in the compiled security plan with the operations at the execution targets included in the corresponding region. The change management module 510 can perform this comparison and make one of two determinations: whether the operation is a subset of the set of changes in the compiled security plan, or whether the operation is not a subset of the set of changes in the compiled security plan. In response to determining that the operation is a subset of the set of changes included in the compiled security plan, the operation can be performed, which can include deploying resources at the execution targets included in the corresponding region. In response to determining that the operation is not a subset of the set of changes included in the compiled security plan, a notification can be sent to the user 518. This notification can be transmitted to user 518 via LAN gateway 516 and can include information warning user 518 that drift may have occurred in at least one zone or that an operation that can be scheduled for execution in at least one execution target may not be included in the compiled security plan. In response to viewing the notification, user 518 can approve or deny the operation that is not included in the security plan. If user 518 approves the operation, the operation is executed and resources can be deployed at the execution targets included in the corresponding zone. If user 518 denies the operation, the operation may not be executed and user 518 may decide to create a new profile or abandon the operation.

[0132] Figure 6 and 7 Example flow charts illustrating processes 600 and 700 for implementing techniques for CIOS according to certain embodiments of the present disclosure are illustrated. These processes are illustrated as logical flow charts, each operation of which can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation can represent a computer-executable instruction stored on one or more computer-readable storage media, which performs the described operation when executed by one or more processors. In general, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a specific function or implement a specific data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement these processes.

[0133] In addition, processes 600 and 700 can be executed under the control of one or more computing devices or computer systems configured with executable instructions and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, implemented by hardware, or a combination thereof. As described above, the code can be stored on a computer-readable storage medium, for example, in the form of a computer program comprising multiple instructions that can be executed by one or more processors. In some embodiments, processes 600 and 700 can be executed in parallel by multiple processors. The computer-readable storage medium can be non-transitory.

[0134] Figure 6 is a flow chart describing a process 600 for using a security plan in a cloud infrastructure orchestration service, according to at least one embodiment. The process 600 may begin at block 602, where a CIOS center (e.g., Figure 5 The CIOS center 506) from the CIOS area containing the area of ​​the execution target (e.g., Figure 5 The CIOS hub receives a security plan from a CIOS region 522 corresponding to the CIOS region. The security plan may include a list of resources and operations based on the deployment profile. The operations may include instructions for deploying resources at the execution target. In some examples, the CIOS hub may receive a set of security plans from a set of CIOS regions corresponding to a set of regions. The security plans may be compiled by the CIOS hub into a compiled security plan that may include resources and operations based on the deployment profile corresponding to the execution targets, each execution target being contained in a different region.

[0135] At block 604, the CIOS hub prepares to execute at least one operation corresponding to at least one resource included in a deployment profile. In response to receiving a security plan from a CIOS region, the CIOS hub may prepare to execute at least one operation in at least one execution target, for example, by compiling a local plan that may include the at least one operation. The operation may involve deploying at least one resource at the execution target. In some examples, the CIOS hub may prepare to execute a set of operations corresponding to a set of resources included in a set of deployment profiles. In this example, the CIOS hub may receive a set of security plans from a set of CIOS regions corresponding to a set of regions.

[0136] At block 606, the CIOS hub compares the operation to the security plan. A change management module (e.g., Figure 5The change management module 510 of the CIOS center may perform a comparison. The comparison may involve determining whether the operation is a subset of the security plan. If the security plan includes the operation, then the operation may be considered a subset of the security plan. In some examples, the operation may not change the current state of the execution target. In this case, the CIOS center may not perform the operation, but the operation may be considered a subset of the security plan.

[0137] At block 608, the operation is performed. In response to the change management module determining that the operation is a subset of the security plan, the CIOS center may transmit a command to perform the operation. The command may be transmitted by the CIOS center to the CIOS regions in the corresponding region and may involve deploying the resources contained in the deployment profile at the execution target. In an example where it is desired to deploy resources at more than one execution target, the CIOS center may receive more than one security plan. In this case, the CIOS center may prepare to perform the operation, and the change management module may compare the operation with the security plan to determine whether the operation is a subset of the security plan. In response to the change management module determining that the operation is a subset of the security plan, the CIOS center may transmit a command to each region to perform the operation. The command may be transmitted by the CIOS center to the CIOS regions in each region and may involve deploying the resources contained in the deployment profile at each execution target.

[0138] At block 610, the operation is not performed and deployment is stopped. In response to the change management module determining that the operation is not a subset of the security plan, the CIOS center may not transmit a command to perform the operation. Instead, the CIOS center may stop deployment. In cases where it is desired to deploy resources at more than one execution target, the CIOS center may receive more than one security plan. In this case, the CIOS center may prepare to perform the operation, and the change management module may compare the operation to the security plan to determine whether the operation is a subset of the security plan. In response to the change management module determining that the operation is not a subset of the security plan, the CIOS center may not transmit a command to perform the operation. Instead, the CIOS center may stop deployment. In other examples, the CIOS center may stop operations that are not a subset of the security plan and may transmit commands to perform operations that are a subset of the security plan.

[0139] At block 612, the CIOS hub sends a message to the user (e.g., Figure 5518) transmits a notification to the user that the deployment does not comply with the security plan. In response to determining that the operation is not a subset of the security plan (as done at box 610), the CIOS center can create and transmit a notification to the user that the deployment no longer complies with the security plan. Even if the operation is not a subset of the security plan, the notification can present the user with the option of continuing with the deployment. The user can choose to continue with the deployment, or can choose to abandon the deployment. If the user chooses to abandon the deployment, the user can create another profile to try a different deployment. In the event that it is desired to deploy resources at more than one execution target, the notification transmitted to the user may include the deployment that does not comply with the security plan. The CIOS center can transmit a command to perform the operation that has been determined to be a subset of the operation.

[0140] Figure 7 is a flow chart describing a process 700 for generating a security plan in a cloud infrastructure orchestration service according to at least one embodiment. At block 702, a CIOS zone (e.g., Figure 5 CIOS area 522) from the CIOS center (e.g., Figure 5 The CIOS center 506 receives a configuration file for deploying infrastructure resources. The configuration file may include operations that include instructions for deploying resources at execution targets included in the region.

[0141] At block 704, the CIOS region identifies a new current state of the cloud infrastructure in the region. A configuration file may define a desired state of the cloud infrastructure in the region, and in response to receiving the configuration file, the CIOS region may identify the current state of the resources in the region. In some examples, the current state may be similar to or identical to the desired state. In other examples, the current state may not include any resources, and the desired state may include most of the resources desired to be deployed at the execution target.

[0142] At block 706, the CIOS region generates a security plan for deploying infrastructure resources based on the comparison between the current state and the desired state. The security plan may include actions that can be performed at the execution target. The actions may involve deploying infrastructure resources at the execution target. In some examples where the current state is similar or identical to the desired state, the security plan compiled by the CIOS region may be empty or may not include any actions.

[0143] At block 708, the CIOS regional transmits the security plan for deploying infrastructure resources to the CIOS central. In response to creating the security plan, the CIOS regional may transmit the security plan to the CIOS central for comparison. As in block 608 of process 600, the CIOS central may determine that the operation to be performed at the execution target is a subset of the security plan. In response to this determination, the CIOS regional may execute the operation and may deploy the resources included in the configuration file at the execution target.

[0144] Figure 8 An example swim lane diagram illustrating a process 800 for implementing CIOS technology according to certain embodiments of the present disclosure is illustrated. This process is illustrated as a logical flow chart, each operation of which can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation can represent a computer-executable instruction stored on one or more computer-readable storage media, which performs the described operation when executed by one or more processors. In general, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a specific function or implement a specific data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0145] In addition, process 800 can be executed under the control of one or more computing devices or computer systems configured with executable instructions and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, implemented by hardware, or a combination thereof. As described above, the code can be stored on a computer-readable storage medium, for example, in the form of a computer program comprising multiple instructions that can be executed by one or more processors. In some embodiments, process 800 can be executed in parallel by multiple processors. The computer-readable storage medium can be non-transitory.

[0146] Figure 8 800 is a swim lane diagram for describing how to generate and use a security plan according to at least one embodiment. As shown, the diagram includes three swim lanes: user swim lane 802, center swim lane 804, and region swim lane 806. User swim lane 802 may include user (e.g., Figure 5 The center lane 804 may include operations performed by the CIOS center (e.g., Figure 5 The zone lanes 806 may include operations performed by CIOS zones (e.g., Figure 5 The CIOS area 522) performs operations.

[0147] Process 800 may begin at block 808, where a user creates a configuration file. The user may desire to deploy infrastructure resources at execution targets included in a zone. In response to this desire, the user may create a configuration file, which may define the desired state of the execution targets. At block 810, the user sends the configuration to the CIOS hub. In response to creating the configuration file, the user may transmit the configuration file to the CIOS hub to initiate deployment.

[0148] At block 812, the CIOS hub receives a configuration file from the user. In response to receiving the configuration file from the user, the CIOS hub may initiate deployment. At block 814, the CIOS hub compiles a region-agnostic (RA) configuration file. In response to initiating deployment, the CIOS hub may compile an RA configuration file, which may be a configuration file that is independent of the region in which the RA configuration file is sent. At block 816, the CIOS hub transmits the RA configuration file to the CIOS region. In response to creating the RA configuration file, the CIOS hub may transmit the RA configuration file to the CIOS region in the region where the resource is desired to be deployed.

[0149] At block 818, the CIOS region in the region where the resource is desired to be deployed receives the RA profile. The RA profile may include operations to be performed to deploy the infrastructure resource at the execution target. The CIOS region may transmit the RA profile to a worker node (e.g., Figure 5 At block 820, the CIOS region creates a security plan based on the new current state. The worker may compare the new current state of the infrastructure resources in the region with the desired state of the infrastructure resources defined in the RA configuration file. The CIOS region may create the security plan based at least in part on the comparison performed by the worker. The security plan may include approved changes to the resources at the execution target.

[0150] At block 822, the CIOS region transmits the security plan to the CIOS center. In response to creating the security plan, the CIOS region may transmit the security plan to the CIOS center to determine whether the operation can be deployed at the execution target. At block 824, the CIOS center receives the security plan from the CIOS region. In some examples where resources are expected to be deployed in more than one region, the CIOS center may receive more than one security plan. In this case, the CIOS center may compile a security plan for the security plan, hereinafter referred to as a compiled security plan. At block 826, the CIOS center compares the deployed operation with the security plan. The deployed operation may include instructions for deploying infrastructure resources at the execution target. In the case of a compiled security plan, the CIOS center may compare the operation with the compiled security plan. At block 828, the CIOS center determines whether the operation is a subset of the security plan. In the case of a compiled security plan, the CIOS center may determine whether the operation is a subset of the compiled security plan.

[0151] At block 830, in response to the CIOS center determining that the operation is a subset of the security plan, the CIOS center transmits a command to the CIOS region to execute the operation. In this case, infrastructure resources may be deployed at the execution target, while in the case of a compiled security plan, resources may be deployed at more than one execution target. In other examples, the operation may not change the state of the execution target, and in this case, the CIOS center may not take any action. At block 832, in response to the CIOS center determining that the operation is not a subset of the security plan, the CIOS center stops the deployment. In this case, the CIOS center transmits a notification to the user, which may inform the user that drift has occurred and that the operation does not comply with the security plan. This notification may allow the user to allow the operation to be executed. If the user chooses not to allow the operation to be executed, the user may abandon the deployment or may create a new configuration file and transmit the new configuration file to the CIOS center to initiate a second deployment. In the case of a compiled security plan, if the operation is not a subset of the compiled security plan, the CIOS center may transmit a notification to the user.

[0152] Figure 9 is a block diagram of a disconnected region 900 according to at least one embodiment. The disconnected region 900 may be communicatively coupled to a connected CIOS hub 902 (e.g., Figure 5 However, the connection between the disconnected region 900 and the connected CIOS center 902 may not be real-time and may be delayed. The disconnected region 900 may include a CIOS center 904 (e.g., Figure 5 CIOS center 506), scheduler node 906 (e.g., Figure 5 Scheduler 524), worker node 908 (e.g., Figure 5 Worker 526), ​​which may include CIOS container 912 (e.g., Figure 5 CIOS container 532) of the docking station 910 (e.g., Figure 5 530), and the signing agent 914 (e.g., Figure 5 In some examples, the disconnected region 900 may be able to receive information / instructions from the connected CIOS hub 902; however, the connected CIOS hub 902 may be disconnected from communications from the disconnected region 900. In other words, communication may be one-way, and once the connected CIOS hub 902 sends information, there is no way to confirm what action the disconnected region 900 performed.

[0153] The CIOS hub 904 can receive tasks from the connected CIOS hub 902 and can transfer the tasks to a scheduler 906. The tasks may include performing CRUD operations at (one or more) execution targets or any other suitable tasks for deploying infrastructure resources in the region. The scheduler 906 can transfer the tasks to a worker 908 that may be included in a worker queue. The worker queue may include many workers 908, and the scheduler 906 may select the worker 908 with the least workload or the most available computing resources to assign the task to it. The scheduler 906 may assign one task to a worker 908 at a time. The worker 908 may execute the task, and when executing the task, the worker may call a CIOS container 912 included in the dock 910. The CIOS container 912 may execute the task including Terraform instructions. The instructions may direct API calls to cloud services 916, which may include services available to the disconnected region 900 that may not be available via a public network (e.g., the Internet). To make an API call to cloud service 916, CIOS container 912 may transmit a request to make the API call to signing agent 914, which may determine whether the request is valid. In response to determining that the request is valid, signing agent 914 may make the API call to cloud service 916.

[0154] The connected CIOS center 902 can transmit the first security plan and the configuration file to the CIOS center 904 for deploying infrastructure resources at the execution target in the disconnected area 900. The CIOS center 904 can transmit the configuration file to the scheduler 906, and the scheduler 906 can assign a task to the worker 908 to create a second security plan based on the configuration file. The first security plan can be created from a different configuration file that is similar to or the same as the configuration file. In response to creating the second security plan, the worker 908 can transmit the second security plan to the CIOS center 904, and the CIOS center 904 can compare the first security plan with the second security plan. The CIOS center 904 can determine, in response to the comparison, that the second security plan is a subset of the first security plan. In this case, the second security plan can be automatically approved, and the infrastructure resources based on the configuration file can be deployed at the execution target in the disconnected area 900. The CIOS center 904 can determine that the second security plan is not a subset of the first security plan. In this case, the deployment can be stopped, and a user (e.g., Figure 5 A notification is transmitted to the user 518 of the disconnected region 900, notifying the user that drift may have occurred and that the deployment does not comply with the second safety plan. Additionally, in this example, if the second safety plan is not a subset of the first safety plan, the connected CIOS center 902 can send an instruction to the disconnected region 900 to stop any deployment originally planned.

[0155] Figure 10 An example flow chart illustrating a process 1000 for implementing techniques for CIOS according to certain embodiments of the present disclosure is illustrated. This process is illustrated as a logical flow chart, each operation of which can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation can represent a computer-executable instruction stored on one or more computer-readable storage media, which performs the operation when executed by one or more processors. In general, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a specific function or implement a specific data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0156] In addition, process 1000 can be executed under the control of one or more computing devices or computer systems configured with executable instructions, and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, implemented by hardware, or a combination thereof. As described above, the code can be stored on a computer-readable storage medium, for example, in the form of a computer program comprising multiple instructions that can be executed by one or more processors. In some embodiments, process 1000 can be executed in parallel by multiple processors. The computer-readable storage medium can be non-transitory.

[0157] Figure 10 is a flow chart describing a process 1000 for using a security plan in a disconnected area according to at least one embodiment. At block 1002, a configuration file for deploying infrastructure resources to a first execution target and a second execution target is received. The configuration file may include a user (e.g., Figure 5 The user 518) may desire infrastructure resources deployed at a first execution target and a second execution target. In some examples, a configuration file may include resources for deployment at the first execution target, while a second configuration file may include resources for deployment at the second execution target.

[0158] At block 1004, a first security plan is generated based on the configuration file. The security plan may include a list of approved changes that the user desires to be performed at the first execution target. The first security plan may be generated by a CIOS center (e.g., Figure 5 The first execution target may be included in the connection area. The first security plan may be created based on a comparison of the current state of the resources at the first execution target with the desired state of the resources at the first execution target that may be defined in the configuration file.

[0159] At block 1006, approval of the first security plan is received. A user may be given the option to approve the first security plan, or the first security plan may be automatically approved based on the operation to be performed at the first execution target. In response to the approval in block 1006, infrastructure resources may be deployed at the execution target based on the configuration file.

[0160] At block 1008, a second security plan is generated for the second execution target based on the configuration file. The second security plan may be comprised of a plurality of security plans that may be included in the disconnection zone (e.g., Figure 9The CIOS center generates a security plan for the second execution target in the disconnected region 900. Furthermore, the second execution target may be included in the disconnected region. In some examples, a second security plan may be created for the second execution target based on the second configuration file. In some examples, the first execution target and the second execution target may be similar or identical, and the first security plan and the second security plan may be similar or identical.

[0161] At block 1010, the CIOS center determines whether the second security plan is a subset of the first security plan. The CIOS center may be included in the disconnected region and may compare the changes approved in the second security plan with the changes approved in the first security plan. The CIOS center may determine that the second security plan is a subset of the first security plan or that the second security plan is not a subset of the first security plan.

[0162] At block 1012, the second security plan is automatically approved based on the approval of the first security plan, based on a determination by the CIOS center that the second security plan is a subset of the first security plan. In this case, the CIOS center can automatically approve the second security plan without user input because the first security plan has already been approved and because the first security plan may have been successfully executed. In some examples, the current state of the second execution target may be similar to or identical to the desired state of the second execution target defined in the configuration file. In this example, the second security plan may not include changes executed at the second execution target. In this case, the second security plan can be automatically approved by the CIOS center because the empty second security plan is a subset of the first security plan.

[0163] At block 1014, based on the CIOS center's determination that the second security plan is not a subset of the first security plan, the CIOS center stops deployment at the second execution target and notifies the user that the second security plan is non-compliant. The CIOS center may stop deployment of infrastructure resources at the second execution target and may transmit a notification to the user informing the user that drift may have occurred and that the second security plan is not a subset of the first security plan. The notification may be presented to the user in a user interface that may present at least one difference between the first security plan and the second security plan. The notification may allow the user to (i) choose to deploy resources despite the CIOS center's determination that the second security plan is non-compliant, (ii) abandon deployment at the second execution target, (iii) submit a new configuration file to initiate a new deployment at the second execution target, or a combination thereof.

[0164] At block 1016, in response to the CIOS center's approval of the second security plan, the CIOS center transmits the second security plan to the second execution target for deployment of infrastructure resources. The CIOS center and the second execution target may be included in a disconnected region. The second security plan may include instructions for deploying resources at the second execution target. In some examples, the second security plan may not include instructions for deploying resources because the current state of the second execution target may be similar to or identical to the desired state of the execution target defined by the configuration file. In this case, the CIOS center may not take any action.

[0165] Descriptive System

[0166] Figure 11-13 Illustrated are aspects of an example environment for implementing aspects of the disclosure according to various embodiments. Figure 11 A simplified diagram of a distributed system 1100 for implementing an embodiment of the present disclosure is depicted. In the illustrated embodiment, the distributed system 1100 includes one or more client computing devices 1102, 1104, 1106, and 1108 configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), and the like, over a network(s) 1110. A server 1112 can be communicatively coupled to the remote client computing devices 1102, 1104, 1106, and 1108 via the network 1110.

[0167] In various embodiments, server 1112 may be adapted to run one or more services or software applications, such as services and applications that provide identity management services. In certain embodiments, server 1112 may also provide other services, or software applications may include both non-virtualized and virtualized environments. In some embodiments, these services may be provided to users of client computing devices 1102, 1104, 1106, and / or 1108 as web-based or cloud services or under a software-as-a-service (SaaS) model. Users operating client computing devices 1102, 1104, 1106, and / or 1108 may then utilize one or more client applications to interact with server 1112 to utilize the services provided by these components.

[0168] exist Figure 11In the depicted configuration, software components 1118, 1120, and 1122 of system 1100 are shown as being implemented on server 1112. In other embodiments, one or more components of system 1100 and / or the services provided by these components may also be implemented by one or more of client computing devices 1102, 1104, 1106, and / or 1108. A user operating a client computing device may then utilize one or more client applications to utilize the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations are possible that may differ from distributed system 1100. Thus, Figure 11 The embodiment shown in FIG. 1 is an example of a distributed system for implementing the embodiment system and is not restrictive.

[0169] Client computing devices 1102, 1104, 1106, and / or 1108 may include various types of computing systems. For example, a client computing device may include a portable handheld device (e.g., Cellular phones, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head-mounted display) that runs a computer such as Microsoft Windows The client computing device may support various applications, such as various Internet-related applications, email, short message service (SMS) applications, and may use various other communication protocols. The client computing device may also include a general-purpose personal computer, for example, running various versions of Microsoft Apple The client computing device can be a personal computer and / or laptop computer running any of a variety of commercial or a workstation computer running a UNIX-like operating system (including but not limited to various GNU / Linux operating systems such as Google Chrome OS). Client computing devices may also include electronic devices capable of providing communication with one or more networks 1110, such as thin client computers, Internet-enabled gaming systems (e.g., with or without Microsoft Gesture Input Devices gaming console) and / or personal messaging device.

[0170] Although Figure 11The distributed system 1100 in FIG. 1 is shown as having four client computing devices, but any number of client computing devices can be supported. Other devices (such as devices with sensors, etc.) can interact with the server 1112 .

[0171] The network(s) 1110 in the distributed system 1100 may be any type of network(s) familiar to those skilled in the art that can support data communications using any of a variety of available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internetwork Packet Exchange), AppleTalk, etc. By way of example only, the network(s) 1110 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network, the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., in any of the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 protocol suites), and / or any other wireless protocol operating under) and / or any combination of these and / or other networks.

[0172] The server 1112 may be composed of one or more general-purpose computers, dedicated server computers (including, for example, PC (personal computer) servers, The server 1112 may be a server, a mid-range server, a mainframe computer, a rack-mounted server, etc.), a server farm, a server cluster, or any other suitable arrangement and / or combination. The server 1112 may include one or more virtual machines running a virtual operating system, or other computing architecture involving virtualization. One or more flexible logical storage device pools may be virtualized to maintain virtual storage devices for the server. The virtual network may be controlled by the server 1112 using software-defined networking. In various embodiments, the server 1112 may be suitable for running one or more services or software applications described in the foregoing disclosure. For example, the server 1112 may correspond to a server for performing processing according to an embodiment of the present disclosure as described above.

[0173] The server 1112 may run an operating system including any of the operating systems discussed above, as well as any commercially available server operating system. The server 1112 may also run any of a variety of additional server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Servers, database servers, etc. Exemplary database servers include, but are not limited to, database servers commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0174] In some implementations, the server 1112 may include one or more applications to analyze and integrate data feeds and / or event updates received from users of the client computing devices 1102, 1104, 1106, and 1108. As examples, the data feeds and / or event updates may include, but are not limited to, feed, Updates or real-time updates received from one or more third-party information sources and continuous data streams, which may include real-time events related to sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. Server 1112 may also include one or more applications that display data feeds and / or real-time events via one or more display devices of client computing devices 1102, 1104, 1106, and 1108.

[0175] Distributed system 1100 may also include one or more databases 1114 and 1116. These databases may provide a mechanism for storing information (such as user identity information and other information used by embodiments of the present disclosure). Databases 1114 and 1116 may reside in various locations. For example, one or more of databases 1114 and 1116 may reside on a non-transient storage medium local to server 1112 (and / or residing in server 1112). Alternatively, databases 1114 and 1116 may be remote from server 1112 and communicate with server 1112 via a network-based or dedicated connection. In one embodiment, databases 1114 and 1116 may reside in a storage area network (SAN). Similarly, any necessary files for performing the functions attributed to server 1112 may be appropriately stored locally on server 1112 and / or remotely. In one embodiment, databases 1114 and 1116 may include a relational database suitable for storing, updating, and retrieving data in response to SQL-formatted commands, such as a database provided by Oracle.

[0176] Figure 12 1 illustrates an example computer system 1200 that can be used to implement embodiments of the present disclosure. In some embodiments, computer system 1200 can be used to implement any of the various servers and computer systems described above. Figure 12As shown in FIG, computer system 1200 includes various subsystems, including a processing subsystem 1204 that communicates with a number of peripheral subsystems via a bus subsystem 1202. These peripheral subsystems may include a processing acceleration unit 1206, an I / O subsystem 1208, a storage subsystem 1218, and a communication subsystem 1224. The storage subsystem 1218 may include tangible computer-readable storage media 1222 and a system memory 1210.

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

[0178] The processing subsystem 1204 controls the operation of the computer system 1200 and may include one or more processing units 1232, 1234, etc. The processing units may include one or more processors, including single-core or multi-core processors, one or more cores of a processor, or a combination thereof. In some embodiments, the processing subsystem 1204 may include one or more specialized coprocessors, such as a graphics processor, a digital signal processor (DSP), etc. In some embodiments, some or all of the processing units of the processing subsystem 1204 may be implemented using custom circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0179] In some embodiments, the processing unit in the processing subsystem 1204 can execute instructions stored in the system memory 1210 or on the computer-readable storage medium 1222. In various embodiments, the processing unit can execute various program or code instructions 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 the system memory 1210 and / or on the computer-readable storage medium 1222, including potentially on one or more storage devices. Through appropriate programming, the processing subsystem 1204 can provide the various functions described above for dynamically modifying documents (e.g., web pages) in response to usage patterns.

[0180] In certain embodiments, a processing acceleration unit 1206 may be provided for performing custom processing or for offloading some of the processing performed by the processing subsystem 1204 , thereby speeding up the overall processing performed by the computer system 1200 .

[0181] The I / O subsystem 1208 may include devices and mechanisms for inputting information into the computer system 1200 and / or for outputting information from or via the computer system 1200. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computer system 1200. User interface input devices may include, for example, a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen incorporated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices, such as Microsoft Windows, that enable a user to control and interact with input devices. Motion sensor, Microsoft 360 game controllers, devices that provide an interface for receiving input using gestures and voice commands. User interface input devices may also include eye gesture recognition devices, such as detecting user eye activity (e.g., "blinking" when taking a picture and / or making a menu selection) and converting eye gestures into input devices (e.g., Google ) In addition, the user interface input device may include an input device that enables the user to communicate with the voice recognition system (e.g., Navigator) interactive voice recognition sensing device.

[0182] Other examples of user interface input devices include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game controllers and graphics tablets, and audio / video equipment, such as loudspeakers, digital cameras, digital cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser rangefinders, and eye tracking devices. In addition, user interface input devices can include, for example, medical imaging input devices, such as computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound equipment. User interface input devices can also include, for example, audio input devices, such as MIDI keyboards, digital musical instruments, etc.

[0183] User interface output devices may include a display subsystem, indicator lights, or non-visual displays (such as audio output devices). The display subsystem may be a cathode ray tube (CRT), a flat panel device such as one utilizing a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, or the like. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1200 to a user or other computers. 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.

[0184] The storage subsystem 1218 provides a repository or data repository for storing information used by the computer system 1200. The storage subsystem 1218 provides a tangible, non-transitory, computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. The software (programs, code modules, instructions) that provide the above functionality when executed by the processing subsystem 1204 can be stored in the storage subsystem 1218. The software can be executed by one or more processing units of the processing subsystem 1204. The storage subsystem 1218 can also provide a repository for storing data used in accordance with the present disclosure.

[0185] The storage subsystem 1218 may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. Figure 12 As shown in , the storage subsystem 1218 includes system memory 1210 and computer-readable storage media 1222. The system memory 1210 may include multiple memories, including volatile main random access memory (RAM) for storing instructions and data during program execution and non-volatile read-only memory (ROM) or flash memory in which fixed instructions are stored. In some implementations, a basic input / output system (BIOS), which contains basic routines that help transfer information between elements within the computer system 1200 (such as during startup), may be stored in ROM. RAM may contain data and / or program modules currently being operated on and executed by the processing subsystem 1204. In some implementations, the system memory 1210 may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0186] By way of example and not limitation, Figure 12As depicted in FIG, system memory 1210 may store application programs 1212, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 1214, and an operating system 1216. For example, operating system 1216 may include various versions of Microsoft Apple and / or Linux operating systems, various commercially available or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or mobile operating systems (such as iOS, Phone, OS, 10OS and OS operating system).

[0187] Computer-readable storage media 1222 may store programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by processing subsystem 1204, enable the processor to provide the functionality described above may be stored in storage subsystem 1218. For example, computer-readable storage media 1222 may include non-volatile memory, such as a hard drive, a magnetic disk drive, an optical disk drive (such as a CD ROM, DVD, disk or other optical media). Computer readable storage media 1222 may include but is not limited to Drive, flash memory card, universal serial bus (USB) flash drive, secure digital (SD) card, DVD disk, digital video tape, etc. The computer readable storage medium 1222 may also include a solid-state drive (SSD) based on non-volatile memory (such as a flash memory-based SSD, an enterprise flash drive, a solid-state ROM, etc.), an SSD based on volatile memory (such as solid-state RAM, dynamic RAM, static RAM), a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using DRAM and a flash memory-based SSD. The computer readable medium 1222 can provide storage for computer readable instructions, data structures, program modules, and other data for the computer system 1200.

[0188] In certain embodiments, storage subsystem 1200 may also include a computer-readable storage media reader 1220, which may be further connected to a computer-readable storage medium 1222. Together with and optionally in conjunction with system memory 1210, computer-readable storage media 1222 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for storing computer-readable information.

[0189] In certain embodiments, the computer system 1200 can provide support for executing one or more virtual machines. The computer system 1200 can execute programs such as a hypervisor to facilitate the configuration and management of virtual machines. Each virtual machine can be allocated memory, computer (e.g., processor, core), I / O, and networking resources. Each virtual machine can run its own operating system, which can be the same or different from the operating systems executed by other virtual machines executed by the computer system 1200. Thus, the computer system 1200 can potentially run multiple operating systems simultaneously. Each virtual machine generally operates independently of the other virtual machines.

[0190] The communication subsystem 1224 provides an interface to other computer systems and networks. The communication subsystem 1224 serves as an interface for receiving data from other systems and transmitting data from the computer system 1200 to other systems. For example, the communication subsystem 1224 can enable the computer system 1200 to establish a communication channel to one or more client devices via the Internet, for receiving information from the client devices and sending information to the client devices. In addition, the communication subsystem 1224 can be used to transmit notifications of successful logins or password re-entry notifications from the privileged account administrator to the requesting user.

[0191] The communication subsystem 1224 can support wired and / or wireless communication protocols. For example, in some embodiments, the communication subsystem 1224 can include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular telephone technology, advanced data network technology (such as 3G, 4G or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 family of standards, or other mobile communication technologies, or any combination thereof)), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communication subsystem 1224 can provide wired network connectivity (e.g., Ethernet) as a supplement or alternative to a wireless interface.

[0192] The communication subsystem 1224 can receive and transmit data in various forms. For example, in some embodiments, the communication subsystem 1224 can receive input communications in the form of structured and / or unstructured data feeds 1226, event streams 1228, event updates 1230, etc. For example, the communication subsystem 1224 can be configured to receive (or send) in real time data feeds 1226 from users of social media networks and / or other communication services (such as feed, updates, web feeds such as Rich Site Summary (RSS) feeds), and / or real-time updates from one or more third-party information sources.

[0193] In some embodiments, the communication subsystem 1224 can be configured to receive data in the form of a continuous data stream, which can include an event stream 1228 of real-time events and / or event updates 1230, which can be continuous or unbounded in nature, without a clear end. Examples of applications that generate continuous data can include, for example, sensor data applications, financial codes, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0194] The communication subsystem 1224 may also be configured to output structured and / or unstructured data feeds 1226 , event streams 1228 , event updates 1230 , etc. to one or more databases, which may be in computer communication with one or more streaming data source computers coupled to the computer system 1200 .

[0195] Computer system 1200 can be of various types, including a handheld portable device (e.g., Cellular phones, computing tablets, PDAs), wearable devices (e.g., Google head-mounted display), personal computer, workstation, mainframe, kiosk, server rack, or any other data processing system.

[0196] Due to the ever-changing nature of computers and networks, Figure 12 The description of the computer system 1200 depicted in FIG is intended only as a specific example. Figure 12 Many other configurations are also possible with more or fewer components than the system depicted in FIG. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will recognize other ways and / or methods to implement the various embodiments.

[0197] The systems depicted in some figures can be provided in various configurations. In some embodiments, the system can be configured as a distributed system, where one or more components of the system are distributed across one or more networks in one or more cloud infrastructure systems.

[0198] A cloud infrastructure system is a collection of one or more server computing devices, network devices, and / or storage devices. These resources can be partitioned by a cloud service provider and allocated in some manner to its customers. For example, a cloud service provider (such as Oracle Corporation of Redwood Shores, California) can offer various types of cloud services, including but not limited to one or more services offered under the Software as a Service (SaaS) category, services offered under the Platform as a Service (PaaS) category, services offered under the Infrastructure as a Service (IaaS) category, or other categories of services including hybrid services. Examples of SaaS services include but are not limited to the ability to build and deliver a suite of on-demand applications (such as Oracle Fusion applications). SaaS services enable customers to utilize applications running on a cloud infrastructure system without requiring them to purchase the software for the applications. Examples of PaaS services include but are not limited to services that enable organizations (such as Oracle) to integrate existing applications on a shared public architecture, as well as the ability to build new applications that take advantage of the shared services provided by the platform (such as Oracle Java Cloud Service (JCS) and Oracle Database Cloud Service (DBCS). IaaS services can help manage and control underlying computing resources, such as storage, networking, and other basic computing resources, allowing customers to take advantage of the services provided by SaaS and PaaS platforms.

[0199] Figure 13 1300 is a simplified block diagram of one or more components of a system environment 1300 according to an embodiment of the present disclosure, through which services provided by one or more components of the embodiment system can be provided as cloud services. In the illustrated embodiment, the system environment 1300 includes one or more client computing devices 1304, 1306, and 1308, which can be used by users to interact with a cloud infrastructure system 1302 that provides cloud services. The client computing devices can be configured to operate client applications, such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application, that can be used by users of the client computing devices to interact with the cloud infrastructure system 1302 to use the services provided by the cloud infrastructure system 1302.

[0200] It should be appreciated that the cloud infrastructure system 1302 depicted in the figure may have other components in addition to those depicted. In addition, the embodiment shown in the figure is merely one example of a cloud infrastructure system that may be incorporated with embodiments of the present disclosure. In some other embodiments, the cloud infrastructure system 1302 may have more or fewer components than shown in the figure.

[0201] Client computing devices 1304 , 1306 , and 1308 may be similar devices to those described above for client computing devices 1102 , 1104 , 1106 , and 1108 .

[0202] Although an example system environment 1300 with three client computing devices is shown, any number of client computing devices can be supported. Other devices such as devices with sensors, etc. can interact with the cloud infrastructure system 1302.

[0203] Network(s) 1310 can facilitate data communication and exchange between clients 1304, 1306, and 1308 and cloud infrastructure system 1302. Each network can be any type of network(s) familiar to those skilled in the art that can support data communication using any of a variety of commercially available protocols, including those described above for network(s) 1110.

[0204] Cloud infrastructure system 1302 may include one or more computers and / or servers, which may include those described above with respect to server 1112 .

[0205] In certain embodiments, the services provided by the cloud infrastructure system may include a large number of services available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, and the like. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a "service instance." In general, any service made available to a user from a cloud service provider's system via a communication network (such as the Internet) is referred to as a "cloud service." In a public cloud environment, the servers and systems that make up the cloud service provider's system are different from the consumer's own local servers and systems. For example, a cloud service provider's system can host applications, and users can order and use the applications on demand via a communication network such as the Internet.

[0206] In some examples, services in a computer network cloud infrastructure may include protected computer network access to storage, hosted databases, hosted web servers, software applications, or other services provided by the cloud provider to users, or as otherwise known in the art. For example, a service may include password-protected access to remote storage on the cloud via the Internet. As another example, a service may include a hosted relational database and scripting language middleware engine based on a web service for private use by networked developers. As another example, a service may include access to an email software application hosted on the cloud provider's website.

[0207] In certain embodiments, the cloud infrastructure system 1302 may include application suites, middleware, and database service offerings delivered to consumers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle Public Cloud provided by the assignee.

[0208] In various embodiments, the cloud infrastructure system 1302 can be adapted to automatically provision, manage, and track consumer subscriptions to services provided by the cloud infrastructure system 1302. The cloud infrastructure system 1302 can provide cloud services via different deployment models. For example, services can be provided under a public cloud model, where the cloud infrastructure system 1302 is owned by an organization that sells cloud services (e.g., owned by Oracle) and makes the services available to the general public or different industrial enterprises. As another example, services can be provided under a private cloud model, where the cloud infrastructure system 1302 operates only for a single organization and can provide services to one or more entities within the organization. Cloud services can also be provided under a community cloud model, where the cloud infrastructure system 1302 and the services provided by the cloud infrastructure system 1302 are shared by several organizations in a related community. Cloud services can also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0209] In some embodiments, the services provided by cloud infrastructure system 1302 may include one or more services provided under the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (IaaS) category, or other service categories including hybrid services. A consumer may subscribe to one or more services provided by cloud infrastructure system 1302 via a subscription order. Cloud infrastructure system 1302 then performs processing to provide the services in the consumer's subscription order.

[0210] In some embodiments, the services provided by the cloud infrastructure system 1302 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall into the SaaS category. For example, a SaaS platform may provide the ability to build and deliver on-demand application suites on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, consumers can utilize applications executed on the cloud infrastructure system. Consumers can obtain application services without the need for consumers to purchase licenses and support separately. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business agility to large organizations.

[0211] In some embodiments, platform services can be provided by the cloud infrastructure system 2702 via a PaaS platform. The PaaS platform can be configured to provide cloud services belonging to the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (such as Oracle) to integrate existing applications on a shared common architecture, and the ability to build new applications using the shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure for providing PaaS services. Consumers can obtain PaaS services provided by the cloud infrastructure system without the need for consumers to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), and others.

[0212] By utilizing the services provided by the PaaS platform, consumers can adopt programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware services), and Java cloud services. In one embodiment, the database cloud service may support a shared service deployment model that enables organizations to pool database resources and provide database as a service to consumers in the form of a database cloud. The middleware cloud service can provide consumers with a platform for developing and deploying various business applications, and the Java cloud service can provide consumers with a platform for deploying Java applications in the cloud infrastructure system.

[0213] A variety of infrastructure services can be provided by IaaS platforms in cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources (such as storage, network, and other basic computing resources) so that consumers can utilize the services provided by SaaS platforms and PaaS platforms.

[0214] In certain embodiments, cloud infrastructure system 1302 may also include infrastructure resources 1330 for providing resources used to provide various services to consumers of the cloud infrastructure system. In one embodiment, infrastructure resources 1330 may include a pre-integrated and optimized combination of hardware (such as servers, storage, and networking resources) that executes the services provided by the PaaS platform and the SaaS platform.

[0215] In some embodiments, resources in cloud infrastructure system 1302 can be shared by multiple users and dynamically reallocated as needed. Furthermore, resources can be allocated to users in different time zones. For example, cloud infrastructure system 1330 can enable a first set of users in a first time zone to utilize resources of the cloud infrastructure system for a specified number of hours, and then enable the reallocation of the same resources to another set of users in a different time zone, thereby maximizing resource utilization.

[0216] In certain embodiments, a plurality of internal shared services 1332 may be provided that are shared by different components or modules of the cloud infrastructure system 1302 and services provided by the cloud infrastructure system 1302. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services for enabling cloud support, email services, notification services, file transfer services, and the like.

[0217] In certain embodiments, the cloud infrastructure system 1302 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) within the cloud infrastructure system. In one embodiment, the cloud management functionality can include the ability to provision, manage, and track subscriptions received by the cloud infrastructure system 1302 or the like from consumers.

[0218] In one embodiment, as depicted in the figure, cloud management functionality may be provided by one or more modules such as order management module 1320, order orchestration module 1322, order provisioning module 1324, order management and monitoring module 1326, and identity management module 1328. These modules may include or may be provided using one or more computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0219] In example operation 1334, a customer using a client device (such as client device 1304, 1306, or 1308) may interact with cloud infrastructure system 1302 by requesting one or more services provided by cloud infrastructure system 1302 and placing an order for a subscription to the one or more services provided by cloud infrastructure system 1302. In certain embodiments, the customer may access a cloud user interface (UI), cloud UI 1312, cloud UI 1314, and / or cloud UI 1316, and place a subscription order via these UIs. Order information received by cloud infrastructure system 1302 in response to the customer placing the order may include information identifying the customer and the one or more services provided by cloud infrastructure system 1302 to which the customer intends to subscribe.

[0220] After the customer places an order, order information is received via the cloud UI, 1312 , 1314 , and / or 1316 .

[0221] At operation 1336, the order is stored in order database 1318. Order database 1318 may be one of several databases operated by cloud infrastructure system 1318 and in conjunction with other system elements.

[0222] At operation 1338, the order information is forwarded to the order management module 1320. In some examples, the order management module 1320 can be configured to perform billing and accounting functions related to the order, such as validating the order and, upon validation, booking the order.

[0223] At operation 1340, information about the order is transmitted to order orchestration module 1322. Order orchestration module 1322 can use the order information to coordinate the provisioning of services and resources for the customer's order. In some examples, order orchestration module 1322 can use the services of order provisioning module 1324 to coordinate the provisioning of resources to support the subscribed services.

[0224] In certain embodiments, order orchestration module 1322 enables management of the business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. At operation 1342, upon receiving an order for a new subscription, order orchestration module 1322 sends a request to order provisioning module 1324 to allocate resources and configure those resources required to fulfill the subscription's order. Order provisioning module 1324 enables allocation of resources for the services subscribed to by the customer. Order provisioning module 1324 provides a level of abstraction between the cloud services provided by cloud infrastructure system 1300 and the physical implementation layer used to provide the resources for provisioning the requested services. Thus, order orchestration module 1322 can be isolated from implementation details, such as whether services and resources are actually provisioned in real time or pre-provisioned and allocated / assigned only upon request.

[0225] At operation 1344, once the services and resources are provisioned, notification of the provided services may be sent to the customer on the client computing devices 1304, 1306, and / or 1308 via the order provisioning module 1324 of the cloud infrastructure system 1302. At operation 1346, the customer's subscription order may be managed and tracked by the order management and monitoring module 1326. In some cases, the order management and monitoring module 1326 may be configured to collect usage statistics for the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, system uptime, and system downtime.

[0226] In certain embodiments, the cloud infrastructure system 1300 may include an identity management module 1328. The identity management module 1328 may be configured to provide identity services in the cloud infrastructure system 1300, such as access management and authorization services in the cloud infrastructure system 1300. In some embodiments, the identity management module 1328 may control information about consumers who wish to utilize services provided by the cloud infrastructure system 1302. Such information may include information authenticating the identities of such consumers and information describing the actions those consumers are authorized to perform with respect to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 1328 may also include descriptive information about each consumer and management of how and by whom the descriptive information may be accessed and modified.

[0227] Although specific embodiments of the present disclosure have been described, various modifications, variations, alternative constructions, and equivalents are also included within the scope of the present disclosure. The embodiments of the present disclosure are not limited to operations within certain specific data processing environments, but can be freely operated within multiple data processing environments. In addition, although the embodiments of the present disclosure have been described using a specific series of transactions and steps, it should be clear to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. The various features and aspects of the above-described embodiments can be used alone or in combination.

[0228] In addition, although embodiments of the present disclosure have been described using specific combinations of hardware and software, it will be appreciated that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments of the present disclosure may be implemented using only hardware, or only software, or a combination thereof. The various processes described herein may 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 may be implemented, for example, by designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using various techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0229] The specification and drawings are therefore to be considered in an illustrative rather than a restrictive sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and changes may be made thereto without departing from the broader spirit and scope set forth in the claims. Therefore, while specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims. Modifications include any relevant combination of the disclosed features.

[0230] Some exemplary items of the present disclosure are described below.

[0231] Item 1: A method comprising:

[0232] receiving, by at least one computer processor of the plurality of computer processors, a security plan comprising a list of resources and corresponding operations based at least in part on a deployment configuration file; and

[0233] Upon receipt of an approval for the Security Plan:

[0234] preparing, by at least one computer processor of the plurality of computer processors, to perform an operation corresponding to at least one of the list of resources according to the deployment configuration file;

[0235] Compare operations to the security plan;

[0236] performing the operation by at least one computer processor of the plurality of computer processors based on determining that the operation is part of a security plan; and

[0237] Based on the determination that the action is not part of the security plan:

[0238] disabling, by at least one computer processor of the plurality of computer processors; and

[0239] A notification is transmitted by at least one of the plurality of computer processors that the deployment does not comply with the security plan.

[0240] Item 2. The method of Item 1, wherein the plurality of processors are associated with an execution target.

[0241] Item 3. The method of Item 2, wherein the execution target includes a geographic area.

[0242] Item 4. The method of Item 1, wherein the deployment configuration file is received from a central cloud infrastructure orchestration service.

[0243] Item 5. The method of Item 4, wherein the deployment configuration file is generated by a user of the central cloud infrastructure orchestration service.

[0244] Item 6. The method of Item 1, wherein the corresponding operation includes at least one of a create operation, an update operation, or a delete operation to be performed on or associated with at least one resource in the list of resources.

[0245] Item 7. The method of Item 1 further includes stopping deployment by at least one of the plurality of computer processors based on receiving a disapproval of the security plan or not receiving an approval of the security plan.

[0246] Item 8. The method of Item 1 further includes generating a local plan having local operations based on a deployment configuration file by at least one computer processor among the plurality of computer processors, and wherein comparing the operation with the security plan includes comparing one of the local operations with the security plan.

[0247] Item 9. A computer-readable storage medium comprising instructions written thereon, the instructions causing a computer processor to perform operations comprising:

[0248] receiving a security plan comprising a list of resources and corresponding operations based at least in part on a deployment configuration file; and

[0249] Upon receipt of an approval for the Security Plan:

[0250] Prepare to perform an operation corresponding to at least one resource in the list of resources according to the deployment configuration file;

[0251] Compare operations to the security plan;

[0252] Perform actions based on the determination that the actions are part of the security plan; and

[0253] Based on the determination that the action is not part of the security plan:

[0254] Stop deployment; and

[0255] Transports notification that a deployment does not comply with the security plan.

[0256] Item 10. The computer-readable storage medium of Item 9, wherein the deployment configuration file is generated by a central cloud infrastructure orchestration service.

[0257] Item 11. The computer-readable storage medium of Item 10, wherein the central cloud infrastructure orchestration service is configured to generate a list of security plans, wherein each security plan in the list of security plans corresponds to a specific execution goal or a specific deployment stage.

[0258] Item 12. The computer-readable storage medium of item 11, wherein the central cloud infrastructure orchestration service is further configured to generate the list of security plans concurrently with and prior to receiving an approval or disapproval of the list of security plans.

[0259] Item 13. The computer-readable storage medium of Item 12, wherein the central cloud infrastructure orchestration service is configured to generate a plurality of deployment profiles, each respective deployment profile in the plurality of deployment profiles being interpreted for each respective execution goal on the list of security plans.

[0260] Item 14. The computer-readable storage medium of Item 10, wherein the operation further comprises transmitting the security plan to a central cloud infrastructure orchestration service.

[0261] Item 15. The computer-readable storage medium of Item 14, wherein the central cloud infrastructure orchestration service is configured to:

[0262] rendering the security plan on a user interface of the user's computer; and

[0263] Receive approval or disapproval of security plans.

[0264] Item 16. A system comprising:

[0265] processor; and

[0266] A memory that stores instructions that, when executed by a processor, configure the system to:

[0267] receiving a security plan comprising a list of resources and corresponding operations based at least in part on a deployment configuration file; and

[0268] Upon receipt of an approval for the Security Plan:

[0269] Prepare to perform an operation corresponding to at least one resource in the list of resources according to the deployment configuration file;

[0270] Compare operations to the security plan;

[0271] Perform actions based on the determination that the actions are part of the security plan; and

[0272] Based on the determination that the action is not part of the security plan:

[0273] Stop deployment; and

[0274] Transports notification that a deployment does not comply with the security plan.

[0275] Item 17. The system of Item 16, wherein the operation is one of a plurality of operations corresponding to at least one of a list of resources according to a deployment profile, and wherein each of the plurality of operations is compared to at least the security plan until the deployment is completed or a stop of the deployment occurs.

[0276] Item 18. The system of Item 16, wherein the operation is not part of a security plan based at least in part on an operational change that occurs with one of the resources prior to performing the operation.

[0277] Item 19. The system of Item 16, wherein the deployment configuration file is generated by a central cloud infrastructure orchestration service.

[0278] Item 20. The system of Item 19, wherein the notification is transmitted to a user of the central cloud infrastructure orchestration service.

[0279] Item 21. An apparatus comprising means for performing the steps according to any one of items 1-8.

[0280] Item 22. A method comprising:

[0281] receiving, by at least one computer processor of the plurality of computer processors, a configuration file for deployment to a first execution target and a second execution target;

[0282] generating, by at least one computer processor of the plurality of computer processors, a first security plan for a first execution target based at least in part on the configuration file, the first security plan comprising a first list of resources and corresponding operations associated with deployment at the first execution target;

[0283] receiving, by at least one computer processor of the plurality of computer processors, approval of a first security plan;

[0284] generating, by at least one computer processor of the plurality of computer processors, a second security plan for a second execution target based at least in part on the configuration file, the second security plan including a second list of resources and corresponding operations associated with deployment at the second execution target;

[0285] determining, by at least one computer processor of the plurality of computer processors, whether the second safety plan is a subset of the first safety plan; and

[0286] Based on determining that the second safety plan is a subset of the first safety plan:

[0287] automatically approving, by at least one computer processor of the plurality of computer processors, a second security plan based at least in part on the approval of the first security plan; and

[0288] The automatically approved second security plan is transmitted to a second execution target by at least one computer processor of the plurality of computer processors.

[0289] Item 23. The method of Item 22, further comprising, based on determining that the second safety plan is not a subset of the first safety plan, preparing a user interface to present:

[0290] a notification indicating that the second security plan is not a subset of the first security plan; and

[0291] A second list of resources and corresponding operations associated with the second security plan.

[0292] Item 24. The method of Item 23, further comprising determining at least one difference between the second list of resources and corresponding operations of the second security plan and the first list of resources and corresponding operations of the first security plan.

[0293] Item 25. The method of Item 24, further comprising preparing a user interface for presenting at least one difference over all other visual representations of the second list of resources and corresponding operations of the second security plan.

[0294] Item 26. The method of Item 22, wherein determining whether the second security plan is a subset of the first security plan includes determining, by at least one computer processor of the plurality of computer processors, whether each resource and corresponding operation of the second list of resources and corresponding operations of the second security plan is listed in the first list of resources and corresponding operations of the first security plan.

[0295] Item 27. The method of Item 22, wherein the first execution target is a connection area of ​​the cloud infrastructure orchestration service.

[0296] Item 28. The method of Item 27, wherein the second execution target is a disconnected area of ​​the cloud infrastructure orchestration service.

[0297] Item 29. The method of Item 28, wherein the disconnected area includes an environment configured to receive instructions for deployment to the disconnected area, and wherein the disconnected area is further configured not to transmit any data outside of the disconnected area.

[0298] Item 30. The method of Item 28, wherein a second security plan is used for deployment at a second execution target.

[0299] Item 31. The method of Item 30, wherein the second security plan is also automatically approved based on determining, at least in part, that deployment of the first security plan at the first execution target is successful.

[0300] Item 32. A computer-readable storage medium comprising instructions written thereon, the instructions, when executed by a computer processor, causing the computer processor to execute instructions comprising:

[0301] receiving a configuration file for deployment to a first execution target and a second execution target;

[0302] generating a first security plan for a first execution target based at least in part on the configuration file, the first security plan comprising a first list of resources and corresponding operations associated with deployment at the first execution target;

[0303] receiving approval of the first safety plan;

[0304] generating a second security plan for a second execution target based at least in part on the configuration file, the second security plan including a second list of resources and corresponding operations associated with deployment at the second execution target;

[0305] determining whether the second security plan is a subset of the first security plan; and

[0306] Based on determining that the second safety plan is a subset of the first safety plan:

[0307] automatically approving the second security plan based at least in part on approval of the first security plan; and

[0308] The automatically approved second security plan is transmitted to the second execution target.

[0309] Item 33. The computer-readable storage medium of Item 32, wherein the instructions further comprise, based on determining that the second safety plan is not a subset of the first safety plan, preparing a user interface to present:

[0310] a notification indicating that the second security plan is not a subset of the first security plan; and

[0311] A second list of resources and corresponding operations associated with the second security plan.

[0312] Item 34. The computer-readable storage medium of Item 33, wherein the instructions further comprise determining at least one difference between a second list of resources and corresponding operations of the second security plan and a first list of resources and corresponding operations of the first security plan.

[0313] Item 35. The computer-readable storage medium of Item 34, wherein the instructions further comprise preparing a user interface for presenting at least one difference over all other visual representations of the second list of resources and corresponding operations of the second security plan.

[0314] Item 36. Computer-readable storage medium of Item 32, wherein the second execution target is a disconnected area of ​​the cloud infrastructure orchestration service, and wherein the disconnected area includes an environment configured to receive instructions for deployment to the disconnected area, and wherein the disconnected area is also configured not to transmit any data outside of the disconnected area.

[0315] Item 37. The computer-readable storage medium of Item 36, wherein the second security plan is for deployment at the second execution target, and wherein the second security plan is also automatically approved based on determining that deployment of the first security plan at the first execution target was successful at least in part.

[0316] Item 38. A system comprising:

[0317] processor; and

[0318] A memory that stores instructions that, when executed by a processor, configure the system to:

[0319] receiving a configuration file for deployment to a first execution target and a second execution target;

[0320] generating a first security plan for a first execution target based at least in part on the configuration file, the first security plan comprising a first list of resources and corresponding operations associated with deployment at the first execution target;

[0321] receiving approval of the first safety plan;

[0322] generating a second security plan for a second execution target based at least in part on the configuration file, the second security plan including a second list of resources and corresponding operations associated with deployment at the second execution target;

[0323] determining whether the second security plan is a subset of the first security plan; and

[0324] Based on determining that the second safety plan is a subset of the first safety plan:

[0325] automatically approving the second security plan based at least in part on approval of the first security plan; and

[0326] The automatically approved second security plan is transmitted to the second execution target.

[0327] Item 39. The system of Item 38, wherein the system is further configured to, based on determining that the second safety plan is not a subset of the first safety plan, prepare a user interface for:

[0328] presenting a notification indicating that the second security plan is not a subset of the first security plan; and

[0329] A second list of resources and corresponding operations associated with a second security plan is presented.

[0330] Item 40. The system of Item 39, wherein the system is further configured to:

[0331] determining at least one difference between the second list of resources and corresponding operations of the second security plan and the first list of resources and corresponding operations of the first security plan; and

[0332] A user interface is prepared for presenting at least one difference over all other visual representations of the second list of resources and corresponding operations of the second security plan.

[0333] Item 41. The system of Item 38, wherein the second execution target is a disconnected area of ​​the cloud infrastructure orchestration service, and wherein the disconnected area includes an environment configured to receive instructions for deployment to the disconnected area, and wherein the disconnected area is also configured not to transmit any data outside of the disconnected area, and wherein a second security plan is used for deployment at the second execution target, and wherein the second security plan is also automatically approved based on a determination that deployment of the first security plan at the first execution target is successful based at least in part on the success of the deployment.

[0334] Item 42. An apparatus comprising means for performing the steps according to any one of items 22-31.

Claims

1. A method comprising: receiving, by at least one computer processor of the plurality of computer processors, a configuration file for deployment of cloud infrastructure resources to both a first execution target and a second execution target, wherein the first execution target is a connected zone of a cloud infrastructure orchestration service, wherein the second execution target is a disconnected zone of the cloud infrastructure orchestration service, wherein the disconnected zone includes an environment configured to receive instructions for deployment to the disconnected zone, and wherein the disconnected zone is further configured not to transmit any data outside of the disconnected zone; generating, by at least one computer processor of the plurality of computer processors, a first security plan for a first execution target based at least in part on the configuration file, the first security plan comprising a first list of resources and corresponding operations associated with deployment at the first execution target; receiving, by at least one computer processor of the plurality of computer processors, approval of a first security plan; generating, by at least one computer processor of the plurality of computer processors, a second security plan for a second execution target based at least in part on the configuration file, the second security plan including a second list of resources and corresponding operations associated with deployment at the second execution target; determining, by at least one computer processor of the plurality of computer processors, whether the second safety plan is a subset of the first safety plan; as well as Based on determining that the second safety plan is a subset of the first safety plan: automatically approving, by at least one computer processor of the plurality of computer processors, a second security plan based at least in part on the approval of the first security plan; as well as The automatically approved second security plan is transmitted to a second execution target by at least one computer processor of the plurality of computer processors.

2. The method of claim 1 , further comprising, based on determining that the second security plan is not a subset of the first security plan, generating a user interface for presenting: a notification indicating that the second security plan is not a subset of the first security plan; and A second list of resources and corresponding operations associated with the second security plan.

3. The method of claim 2, further comprising determining at least one difference between the second list of resources and corresponding operations of the second security plan and the first list of resources and corresponding operations of the first security plan. 4 . The method of claim 3 , further comprising generating a user interface for presenting the at least one difference over all other visual representations of the second list of resources and corresponding operations of the second security plan.

5. A method as described in any one of claims 1 to 4, wherein determining whether the second security plan is a subset of the first security plan includes determining by at least one computer processor of the plurality of computer processors whether each resource and corresponding operation in the second list of resources and corresponding operations of the second security plan is listed in the first list of resources and corresponding operations of the first security plan. The method of claim 1 , wherein a second security plan is used for deployment at a second execution target.

7. The method of claim 6, wherein the second security plan is automatically approved further based on determining that the deployment at the first execution target is successful.

8. A computer-readable storage medium comprising instructions written thereon, which, when executed by a computer processor, cause the computer processor to perform instructions comprising: receiving a configuration file for deployment of cloud infrastructure resources to both a first execution target and a second execution target, wherein the first execution target is a connected zone of a cloud infrastructure orchestration service, wherein the second execution target is a disconnected zone of the cloud infrastructure orchestration service, wherein the disconnected zone comprises an environment configured to receive instructions for deployment to the disconnected zone, and wherein the disconnected zone is further configured not to transmit any data outside of the disconnected zone; generating a first security plan for a first execution target based at least in part on the configuration file, the first security plan comprising a first list of resources and corresponding operations associated with deployment at the first execution target; receiving approval of the first safety plan; generating a second security plan for a second execution target based at least in part on the configuration file, the second security plan comprising a second list of resources and corresponding operations associated with deployment at the second execution target; determining whether the second safety plan is a subset of the first safety plan; as well as Based on determining that the second safety plan is a subset of the first safety plan: automatically approving the second security plan based at least in part on approval of the first security plan; as well as The automatically approved second security plan is transmitted to the second execution target.

9. The computer-readable storage medium of claim 8, wherein the instructions further comprise, based on determining that the second security plan is not a subset of the first security plan, preparing a user interface for presenting: a notification indicating that the second security plan is not a subset of the first security plan; and A second list of resources and corresponding operations associated with the second security plan.

10. The computer-readable storage medium of claim 9, wherein the instructions further comprise determining at least one difference between a second list of resources and corresponding operations of the second security plan and a first list of resources and corresponding operations of the first security plan.

11. The computer-readable storage medium of claim 10, wherein the instructions further comprise preparing a user interface for presenting the at least one difference over all other visual representations of the second list of resources and corresponding operations of the second security plan.

12. The computer-readable storage medium of claim 8, wherein the second security plan is for deployment at the second execution target, and wherein the second security plan is automatically approved based further on determining that deployment at the first execution target was successful based at least in part on the first security plan.

13. A system comprising: processor; as well as a memory storing instructions that, when executed by a processor, configure the system to: receiving a configuration file for deployment of cloud infrastructure resources to both a first execution target and a second execution target, wherein the first execution target is a connected zone of a cloud infrastructure orchestration service, wherein the second execution target is a disconnected zone of the cloud infrastructure orchestration service, wherein the disconnected zone comprises an environment configured to receive instructions for deployment to the disconnected zone, and wherein the disconnected zone is further configured not to transmit any data outside of the disconnected zone; generating a first security plan for a first execution target based at least in part on the configuration file, the first security plan comprising a first list of resources and corresponding operations associated with deployment at the first execution target; receiving approval of the first safety plan; generating a second security plan for a second execution target based at least in part on the configuration file, the second security plan comprising a second list of resources and corresponding operations associated with deployment at the second execution target; determining whether the second safety plan is a subset of the first safety plan; as well as Based on determining that the second safety plan is a subset of the first safety plan: automatically approving the second security plan based at least in part on approval of the first security plan; as well as The automatically approved second security plan is transmitted to the second execution target.

14. The system of claim 13, wherein the system is further configured to, based on determining that the second security plan is not a subset of the first security plan, prepare a user interface for: presenting a notification indicating that the second security plan is not a subset of the first security plan; and A second list of resources and corresponding operations associated with a second security plan is presented.

15. The system of claim 14, wherein the system is further configured to: determining at least one difference between the second list of resources and corresponding operations of the second security plan and the first list of resources and corresponding operations of the first security plan; and A user interface is prepared for presenting the at least one difference over all other visual representations of the second list of resources and corresponding operations of the second security plan.

16. The system of any one of claims 13 to 15, wherein the second security plan is for deployment at the second execution target, and wherein the second security plan is automatically approved based further on determining that deployment at the first execution target was successful based at least in part on the first security plan.

17. An apparatus comprising means for performing the steps according to any one of claims 1 to 7.

Images