CN114902252A

CN114902252A - Techniques for detecting drift in a deployment orchestrator

Info

Publication number: CN114902252A
Application number: CN202080090570.8A
Authority: CN
Inventors: E·T·巴萨鲁; N·M·格拉斯
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2020-01-20
Filing date: 2020-11-25
Publication date: 2022-08-12
Also published as: WO2021150306A1; EP4094208A1; JP2023511111A

Abstract

Techniques for implementing infrastructure orchestration services are described. A security plan can be received that includes a list of resources and operations based at least in part on the deployment configuration file. 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 a safety plan. If the operation is part of a security plan, the operation can be performed. If the operation is not part of the security plan, the deployment can be stopped and a notification that the deployment is not in compliance with the security plan can be transmitted.

Description

Techniques for detecting drift in a deployment orchestrator

Cross reference to related applications

The benefits and priority of U.S. application No.62/963,413 entitled "TECHNIQES FOR DETECTING DRIFT IN A DEPLOYMENT ORCHESTRATOR" filed on 35U.S. C.119(e) on 1, 20, 2020, U.S. application No.17/027,527 entitled "TECHNIQES FOR DETECTING DRIFT IN ADEPLOYMENT ORCHESTRATOR" filed on 9, 21, 2020, and U.S. application No.17/027,507 entitled "TECHNIQES FOR MANAGING DRIFT IN A DEPLOYMENT ORCHESTRATOR" filed on 9, 21, 2020, the contents of which are hereby incorporated by reference in their entirety FOR all purposes.

Background

Today, cloud infrastructure services leverage many individual services to provision and deploy code and configurations (respectively) across many areas of the cloud infrastructure service. These tools require a significant amount of manual work to use, especially to the extent that deployment of code is necessary given that provisioning is generally declarative. Furthermore, as the number of service teams and areas grow, cloud infrastructure services will need to continue to grow. The strategy of deployment of some cloud infrastructure services to a large number of smaller areas involves expenditures per area, which may not scale well.

Disclosure of Invention

Techniques for implementing infrastructure orchestration (organization) services are described. In some examples, a security plan may 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 resource lists may be prepared for execution. The operation may be compared to a safety plan. If the operation is determined to be part of a security plan, the operation may be performed. If it is determined that the operation is not part of a security plan, the deployment may be stopped and a notification that the deployment is not in compliance with the security plan may be transmitted. In some examples, if a drift (drift) occurs, the operation may not be part of the security plan.

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. A security plan may be received that may include a list of resources and operations based on a deployment profile. Approval of the security plan may be received. An operation may be prepared to perform at least one of the list of resources according to the deployment configuration file. The operation may be compared to a safety plan. If the operation is determined to be part of a security plan, the operation may be performed. If it is determined that the operation is not part of a security plan, the deployment may be stopped and a notification that the deployment is not in compliance with the security plan may be transmitted.

In further 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. A security plan may be received, which 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, an operation corresponding to at least one of the list of resources may be prepared for execution. The operation may be compared to a safety plan. If the operation is determined to be part of a security plan, the operation may be performed. If it is determined that the operation is not part of a security plan, the deployment may be stopped and a notification that the deployment is not in compliance with the security plan may be transmitted.

In other examples, a method may include receiving, by at least one of a plurality of computer processors, a security plan including a list of resources and corresponding operations based at least in part on a deployment profile. The method may further include, in accordance with 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 according to the deployment profile. The method may also include comparing the operation to a security plan. The method may also include, in accordance with a determination that the operation is part of a security plan, performing the operation by at least one of the plurality of computer processors. The method may further include, in accordance with a determination that the operation is not part of a security plan: halting, by at least one of the plurality of computer processors, 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.

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 including a list of resources and corresponding operations based at least in part on a deployment profile. The operations may further include, in accordance with 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 configuration file; the operation is compared to a safety plan. The operations may also include performing the operation in accordance with a determination that the operation is part of a security plan. The operations may further include, in accordance with a determination that the operation is not part of a security plan: stopping deployment; and transmitting a notification that the deployment is not in compliance with the security plan.

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 including a list of resources and corresponding operations based at least in part on a deployment profile. The operations may further include: in accordance with receiving an indication of approval of the security plan: an operation corresponding to at least one of the list of resources according to the deployment configuration file is prepared for execution. The operations may also include comparing the operations to a security plan. The operations may also include performing the operation in accordance with a determination that the operation is part of a security plan. The operations may further include, in accordance with a determination that the operation is not part of a security plan: stopping deployment; and transmitting a notification that the deployment is not in compliance with the security plan.

An apparatus comprising means for performing steps according to any of the methods described herein.

Drawings

To readily identify the discussion of any particular element or act, one or more of the most significant digits in a reference number refer to the figure number that first introduces that element.

Fig. 1 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service according to at least one embodiment.

Fig. 2 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service according to at least one embodiment.

FIG. 3 is a flow diagram illustrating an example group (flip) in accordance with at least one embodiment.

FIG. 4 is a flow diagram illustrating an example cluster in accordance with at least one embodiment.

Fig. 5 is a block diagram of a cloud infrastructure orchestration service according to at least one embodiment.

FIG. 6 is a flow diagram describing a process for using security plans in a cloud infrastructure orchestration service according to at least one embodiment.

FIG. 7 is a flow diagram describing a process for generating a security plan in a cloud infrastructure orchestration service according to at least one embodiment.

FIG. 8 is a swim lane diagram for describing how a security plan is generated and used in accordance with at least one embodiment.

FIG. 9 is a block diagram of a disconnect region in accordance with at least one embodiment.

FIG. 10 is a flow diagram describing a process for using a security plan in a disconnected region in accordance with at least one embodiment.

FIG. 11 is a block diagram of a distributed system in accordance with at least one embodiment.

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

FIG. 13 is a block diagram of an example computer system in which various embodiments of the present disclosure may be implemented.

Detailed Description

In some examples, infrastructure as a service (IaaS) is a particular type of cloud computing. IaaS may 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 consider the other major categories to be software as a service (SaaS) and platform as a service (PaaS), and sometimes SaaS can be considered a broader category, encompassing both PaaS and IaaS, and even some consider IaaS a subcategory of PaaS.

In the IaaS model, cloud computing providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.).

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

In some cases, the IaaS customer may access resources and services over a Wide Area Network (WAN), such as the internet, and may use the services of the cloud provider to install the remaining elements of the application stack. For example, a user may log into the IaaS platform to create Virtual Machines (VMs), install an Operating System (OS) in each VM, deploy middleware such as databases, create buckets for workloads and backups, and even install enterprise software into that VM. The customer may then use the provider's services to perform various functions, including balancing network traffic, solving application problems, monitoring performance, managing disaster recovery, and the like.

In most cases, the cloud computing model will require the involvement of a cloud provider. The cloud provider can be, but need not be, a third party service that specifically provides (e.g., sells) IaaS. An entity may also choose to deploy a private cloud to become a provider of its own infrastructure services.

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

In some examples, IaaS provisioning may refer to obtaining a computer or virtual host for use, and even installing a required library or service on them. In most cases, the deployment does not include provisioning, and may require that provisioning be performed first.

In some cases, IaaS provisioning presents two distinct issues. First, provisioning an initial set of infrastructure before anything runs is an initial challenge. Second, once all of the content has been served, challenges are faced in developing an infrastructure that is exposed (e.g., adding new services, changing services, removing services, etc.). In some cases, these two challenges may be addressed by enabling the configuration of the infrastructure to be defined in a declarative manner. In other words, the infrastructure (e.g., which components are needed and how they interact) may be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which resources, and how they each work together) can be described in a declarative manner. In some cases, once the topology is defined, a workflow may be generated that creates and/or manages the different components described in the configuration file.

In some examples, an infrastructure may have many interconnected elements. For example, there may be one or more Virtual Private Clouds (VPCs) (e.g., potential on-demand pools of configurable and/or shared computing resources), also referred to as core networks. In some examples, there may also be one or more security group rules provisioned to define how to set the security of the network, and one or more Virtual Machines (VMs). Other infrastructure elements may also be provided, such as load balancers, databases, and the like. As more and more infrastructure elements are desired and/or added, the infrastructure may evolve.

As mentioned above, one way to provision the infrastructure is to describe it declaratively. As such, a configuration file may be a declarative file that merely describes each of the infrastructure components described above and how they interact. The configuration file may describe the resources and related fields needed to create the element, and may then describe other elements that reference the previously described elements. In some examples, the provisioning tool may then generate a workflow for creating and managing the elements described in the configuration file.

In some cases, the workflow of the provisioning tool may be configured to execute various commands. One function that may be performed is view coordination, where the provisioning tool may compare the current view of the infrastructure (e.g., the expected state of the infrastructure) to how the infrastructure actually functions. In some cases, performing the view coordination function may include querying various resource providers or infrastructure resources to identify which resources are actually running. Another function that the supply tool may perform is plan generation, where the supply tool may compare the actual running infrastructure components to what the supply tool expects the state to look like (e.g., the desired configuration). In other words, the plan generation function can determine which changes need to be made to bring the resource up to date to expectations. In some cases, the third function is an execute (e.g., application) function, where the provisioning tool may execute the plan generated by the plan generation function.

In general, the provisioning tool may be configured to obtain 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 the security group rules and VM boots, the provisioning tool will be able to make this determination and implement the boots in that order without user intervention and/or without including that information in the configuration file.

In some cases, a continuous deployment technique may be employed to enable deployment across the infrastructure code of various virtual computing environments. Further, the described techniques may enable infrastructure management in these environments. In some examples, a service team may write code that is desired to be deployed to one or more (but often many) different production environments (e.g., across various different geographic locations, sometimes across the world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning may be done manually, provisioning tools may be used to provision resources, and/or deployment tools may be used to deploy code once the infrastructure is provisioned.

As described above, there are generally two different tools for handling each of provisioning of infrastructure resources and deployment of code that controls infrastructure resources, with orchestration between the two tools being performed manually. However, on a scale, manual implementation always leads to deviations. Thus, automated tools that can both provision and deploy virtual infrastructures enable virtual cloud environments with more efficient and reliable technologies.

In some examples, when using two tools, problems arise when a user manually makes changes to code between the provisioning phase and the deployment phase. As described herein, techniques that use a single tool to both provision and deploy can mitigate this situation by automating the process so that there is no opportunity for manual code changes. It is likely that slight changes to the user's encoding scheme will create significant problems during the deployment phase. In some examples, the first time the operator performs an action (e.g., a misclass in the code) in a new region, the objects encoded using the misclass may always be. If the application is deployed using that bug and is not sensitive to that bug (e.g., it is still working), then it is possible that at some later time, additional code changes may be sensitive to that bug and cause the entire system to crash. Thus, the techniques provided herein can eliminate the gap between provisioning and deployment that often leads to problems.

In general, modeling deployments are declarative, such that configuration files can be used to declare infrastructure resources. For example, create, read, update, delete (CRUD) instructions are commonly used to generate deployment files using a general representation state transfer (REST) concept (e.g., REST Application Programming Interface (API)). However, deployment itself generally does not follow the same concept. Furthermore, while infrastructure provisioning tools tend to be very powerful and/or expressive, tools for deployment tend to have more limitations on the operations they can perform (e.g., they are mandatory rather than declarative). Thus, there is a long-felt need for a tool that can handle both functional needs (e.g., provisioning and deployment of infrastructure elements) in a cloud environment.

In some examples, techniques for implementing Cloud Infrastructure Orchestration Services (CIOS) are described herein. As briefly described above, such techniques may be configured to manage provisioning and deployment of infrastructure assets within a cloud environment. In some cases, a CIOS may include two types of services: center and area components (e.g., a CIOS center and a CIOS area).

The following terms will be used throughout:

infrastructure component-infrastructure that supports the long-standing existence of running code.

Example o: deployment applications, load balancers, Domain Name System (DNS) entries, object buckets, and the like.

Artifact-configuration information deployed to a deployment application or kubernets engine cluster, or applied to infrastructure components (hereinafter referred to simply as "configuration"). These may be read-only resources.

Deployment tasks-short-term tasks often associated with deploying or testing code. Furthermore, deployment tasks are modeled as resources whose lifecycle does not exceed the release (release) that created them.

Example o: "deploy $ artifact to $ environment", "observe $ avatar 10 minutes", "execute $ testSuite", or "wait $ manifest approval"

For example, the CIOS may model the deployment orchestrator deployment as the creation of resources that transition to an available state upon completion.

Because the CIOS maintains the state of its associated declarative provisioner, the CIOS can control the lifecycle of these short-term resources as it is publication dependent.

resource-CRUD-capable resources.

The CIOS models each of the constructs listed above as a resource. This modeling will be discussed in detail in the next section.

Group (flip) -the only control plane resource of the CIOS. Primarily for modeling and pointing to the ownership of infrastructure components.

Group configuration-describes the set of all infrastructure components, artifacts, and deployment tasks associated with a single service.

Each group has only one group configuration. The group configuration has signed in source code control.

The group configuration is declarative. They want the CIOS to provide domain, area, advertisement and artifact versions as input.

A group is fine-grained-a group consists of a single service and a supporting infrastructure.

State — a point-in-time snapshot of the state of each resource in the cluster.

Publish-the tuple for each artifact of a particular version of the group configuration and the particular version it references.

Let's consider an issue as describing a state that may not yet exist.

Issue plan-CIOS transitions all regions from their current state to the set of steps that issue the state described.

O the publication plan has a limited number of steps and well-defined start and end times.

Application-this is a noun. A single attempt executes the publication plan. The current state of the change group is performed.

CIOS may be described as an orchestration layer that applies configuration to downstream systems (e.g., global). It is designed to allow infrastructure provisioning and code deployment worldwide without manual effort by a service team (e.g., beyond initial approval in some cases). High level responsibilities of CIOS include, but are not limited to:

provide the team with a view of the current state of the resources managed by the CIOS, including any ongoing change activities.

Help teams plan and publish new changes.

Coordinating activities across various downstream systems within the region to execute approved publication plans without human intervention.

Coordinating activities across regions/domains to execute approved release plans globally.

In some examples, the CIOS handles the boot flow by enabling the team to provide configuration information to the CIOS via sign-on code. Furthermore, the CIOS can automate more things, and therefore is a more burdensome task than previous implementations. In some cases, CIOS handles pre-deployment by providing teams the ability to automatically deploy and test code. In some cases, CIOS may handle the authoring of Change Management (CM) policies by enabling automatic generation of plans to roll out new artifacts (e.g., global) as a team builds them. It may do this by examining the current state and current CIOS configuration (which may itself be the artifact) of each region. Further, the team may review these plans and may iterate on them by changing the CIOS configuration and requiring a CIOS re-plan. Once a team is satisfied with a plan, they can create a "post" that references the plan. The plan may then be marked as approved or rejected. While teams may still write CMs, they are only pointers to the CIOS plan. Thus, the team may spend less time reasoning about the plan. The plans are more accurate because they are machine generated. Plans are almost too detailed for human consumption; however, it may be displayed via a complex User Interface (UI).

In some examples, the CIOS may handle execution of the CM by automatically executing the deployment plan. Once the release plan is created and approved, the engineer will not participate in the CM unless the CIOS initiates a rollback. In some cases, this may require the team to automate a task that is currently manual. In some examples, when the CIOS detects a degradation in service health while executing, the CIOS may handle rollback Change Management (CM) by automatically generating a plan to return the group to its original (e.g., pre-release) state. In some examples, the CIOS may deploy emergency/tactical changes by receiving a distribution plan that ranges to a subset of resources and/or a subset of regions managed by the CIOS, and then executing the plan.

In addition, CIOS may support primitives necessary to define fully automated global deployments. For example, the CIOS may measure service health by monitoring alarms and performing integrated tests. The CIOS may help the team quickly define the rollback behavior in case of service degradation and then execute it automatically. The CIOS may automatically generate and display a release plan and may track approvals. In some cases, the language used by the team to describe the desired deployment behavior may be declarative. The CIOS may combine the functionality of code deployment and infrastructure configuration (e.g., provisioning) in one system. CIOS also supports flexible ordering of components across regions and within regions. The team may express the ranking via a sign-on configuration. The team may programmatically invoke the scheduling and publishing API of the CIOS.

FIG. 1 depicts an architecture 100 for illustrating techniques for implementing at least a CIOS center 102. In some examples, the CIOS hub 102 may be a service that handles operations at the "group" level. The CIOS center 102 has several responsibilities, including but not limited to:

authentication gateway acting as group metadata change and publish operation.

Store the authoritative mapping of the swarm metadata to the deployment artifacts and the CIOS repository for the swarm.

Coordinating global releases across phases and targets.

Synchronization to enforce policies such as "issue no more than one publication in progress to the group at a time".

Detect changes to the cluster configuration (configuration) and artifacts, and trigger publication generation upon such changes.

In some examples, the source code version control management service (SCVMS)104 may be configured to store an authoritative group configuration, and the CIOS hub 102 may subscribe to an Artifact Notification Service (ANS)106 so that the CIOS hub 102 may be notified of new artifact builds. The CIOS center 102 may then map the incoming changes to the affected clusters and initiate a distribution plan where desired. Further, in some examples, an Artifact Push Service (APS) may be invoked by the CIOS center 102 prior to publication to the target to ensure that any artifacts required for successful publication are present in the area of the target prior to publication.

In some examples, a customer (e.g., engineer) 108 may call the CIOS center 102 to CRUD a group and/or publication and view the status of the in-progress CIOS activity. The community management service 110 may include one or more APIs to manipulate the community, the view/plan/approve service 112 may include CRUD APIs to create and approve plans, and to view a central copy of the state of all CIOS managed resources, the change monitoring service 114 may monitor the SCVMS 104 for changes to the community configuration, and may receive notifications from the ANS 106 regarding changes to other artifacts, and the state ingester service 116 may create a copy of the region state in the CIOS central Database (DB)118 so that the view/plan/approve 112 may expose them. In some examples, the CIOS centric DB 118 may be a DB of groups, plans, and states. The group information may be authoritative; while everything else may be a stale copy of the data from CIOS area 120.

In some examples, the engineer 108 may perform API calls to the group management service 110 (e.g., via the ingress agent queue 122) to create a list of groups. The protocol for making such API calls may be hypertext transfer protocol secure (HTTPS) or the like. The associated Access Control List (ACL) for this operation may include a Local Area Network (LAN)124 or other private connection. For example, instead of using the public internet to connect a customer's local data center or network to the CIOS (e.g., private, leased, and/or proprietary connections), the CIOS may manage/control network connectivity. Further, authentication and authorization (e.g., of the engineer 108) may be performed by a reservation system portal (e.g., a reservation service) that allows a user to manage the machine infrastructure. In some cases, the CIOS hub 102 may store group metadata, plans, and states in the hub DB 118 using Java database connectivity (JDBC) or the like. In some examples, ANS 106 may be configured to notify change monitoring service 114 when a new artifact has been published. ANS 106 may use HTTPS, and both authentication and authorization may be handled by the mutual transport layer security service. Further, in some cases, the change monitoring service 114 may poll the SCVMS 104 for a group configuration change. This polling may be performed using a Secure Shell (SSH) or other protocol. Authentication of the change monitoring service 114 may be handled by the CIOS system account and authorization may be handled by the SCVMS 104.

In some examples, the engineer 108 may use the viewing/planning/approval service 112 to perform one or more of the following operations. The engineer 108 may plan and/or approve by invoking the CIOS center 102 to generate and approve a plan. The engineer 108 may view by invoking the CIOS center 102 to view the status of the CIOS activity being performed globally. In addition, the engineer 108 may invoke the CIOS center 102 to view a copy of the state of the global CIOS management resource. These API calls (etc.) may be performed via the HTTPS protocol or similar. Further, the relevant ACLs may be controlled by LAN 124, and both authentication and authorization may be handled by subscribed services. In some examples, the view/plan/approval service 112 may request a plan and push the plan approval to all areas of the CIOS area 120 (e.g., using HTTPS, etc.). The relevant ACLs may be controlled using a security list managed by a Wide Area Network (WAN) gateway 126. Authentication may be handled by mutual transport layer security and authorization may be handled by various identity policies. In addition, the state ingester service 116 may view the operational state or state changes of the CIOS area 120 so that the CIOS may provide their central view upon request (e.g., also using HTTPS, etc.). ACLS for this may also be handled by WAN gateway 126, and authentication and authorization may both be handled by the mutual transport layer security service.

FIG. 2 depicts an architecture 200 illustrating techniques for implementing at least a CIOS area 202. In some examples, the CIOS area 202 is where much of the work of declarative provisioning and planning and approved publishing applications can occur. In some cases, each instance of the CIOS region 202 may have a region front end that may handle operations at the "execution target" level. It may be configured to perform the following operations:

handle all CIOS authentications for incoming operations from the CIOS center 102.

Enforce rules that can only be "executing" (planning/importing resources/application planning) one at a time for a given execution target.

Managing binary artifact storage for declarative provisioning artifacts for input and output during declarative infrastructure provisioning execution. Examples of inputs are a declarative infrastructure provisioning configuration file and an input state file. The typical output is a final state file.

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

In some cases, the CIOS front end may rely on a CIOS executor that may handle actual execution. In some examples, the CIOS executor runs at the "execute" level and it may:

tracking the pool of available worker nodes

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

Tracking worker status and performing updates to report to clients

Detecting dead nodes via a lease agreement, and depending on task status, tasks assigned to dead nodes can be failed.

Facilities to provide cancel/kill/pause/resume execution, and those can be mapped onto facilities to pass cancel/kill/resume information to the worker node.

In some cases, the CIOS executor may rely on a CIOS worker, which may assign tasks to be executed to the worker and provide the worker with a facility to update the work schedule. Worker services operate at the granularity of a "task". Each worker is an agent that executes tasks assigned to that worker and reports task status and output. Each of the workers may:

poll the executor worker API for assigned work items and take action to match the assigned state to its local state:

o a start container for polling locally non-existent task items

O a killing container for locally running a container without a corresponding assigned task item

Reporting status of work

Phase input and output for job container execution

Launch and monitor the declarative infrastructure provisioning container to complete the actual work directed to the publishing of execution targets.

The CIOS worker may rely on the CIOS executor to poll and report results to worker endpoints from the CIOS executor. The worker may rely on the actuator for all coordination. Further, the CIOS worker may also rely on the CIOS area 202, where worker services read input from and write output to one or more APIs associated with area front-end services. Examples of inputs are configuration and startup state files and import mappings. Examples of outputs are declarative provisioning processes, outputting declarative provisioning state files, and importing result states.

In some examples, CIOS area 202 may be an area service for managing area instances/deployments of CIOS. The CIOS area 202 is responsible for authoritatively storing and managing planning and statistics data associated with a particular area. The region DB 204 may be a CIOS DB for status and plans in a particular region. This is an authoritative copy of the regional subset of the central DB 118 of fig. 1. 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 mainly used for operational purposes. Further, the worker 210 may be a queue of a Java Virtual Machine (JVM) that manages declarative provisioning images. They receive instructions from scheduler 206 and communicate results to both scheduler 206 and CIOS area 202. The CIOS container 212 may run declarative provisioning operations in its own private dock 214 container. This container need not contain secrets. Further, in some examples, the signing agent 216 may be configured to prevent secret leakage via a declarative provisioning tool in order to avoid placing secrets into a declarative provisioning image. Instead, the CIOS may perform request signing or initiate mutual transport layer security (mTLS) services in the proxy. This also makes it easier to use FIPS compliant encryption libraries.

In some examples, the CIOS center 102 may invoke the CIOS area 202 to create plans, push approvals, view job status (service bodies), and extract declarative provider status (service bodies). The portal proxy 218 may be configured as an ACL and various identity policies may be used for authentication and authorization. In some cases, the CIOS area 202 may run the declarative provider by asking the scheduler 206 to do so. The worker 210 may ask the scheduler 206 what it should run and may report status to the scheduler 206 when completed. In some cases, mTLS may handle authentication and authorization for CIOS area 202 and worker 210 simultaneously. Further, when the worker 210 needs to run a declarative provider, it does so in the docking station container by interacting with the local docking station 214. This phase of authentication may be handled by the local unix socket. The last step may use docking station protocols; however, HTTPS may be used for those before.

In some examples, the CIOS container 212 enables the declarative provisioner to interact with the signing agent 216 (via an API) while the declarative provisioner considers it to be calling various CIOS services. The signing agent 216 listens on one temporary port for each calling instance of a declarative provisioner, only that declarative provisioner knows. The signing agent 216 may initiate request signatures or mTLS and may pass the call of the declarative provisioner to other CIOS services within a service enclave (service enclave). In some cases, the signing agent 216 may also communicate with one or more common CIOS services 220. For example, the signing agent 216 will use the internal endpoints of the public service as much as possible. For services without an internal endpoint, it must use the egress agent 222 to reach the external endpoint. This use of the signing agent 216 cannot be used for cross-regional communication; for example, the egress proxy whitelist in each region may only apply to the public IP range of that region. In some examples, the worker 210 may then maintain a log and status from the declarative provisioners in the CIOS region 202 so that they may be leaked to the CIOS hub 102.

With CIOS, there are several phases of a representative customer experience: boot flows (onboarding), pre-release, global release, and tactical release. For the pre-release phase, the following is an example that occurs between building a new artifact and releasing the artifact to release one (e.g., R1). This should replace some or most of the current change management process. As related artifacts build, the CIOS may automatically generate publications using the "latest version of all content in the community". A publication is a specific version of a group configuration with specific inputs (e.g., artifact version, domain, region, and advertisement). Publishing metadata that contains a roll-forward plan for each region and describes the region ordering. Each regional plan is a set of operations that the declarative provider will take to implement the group configuration in that region. A team with a pre-release environment may use CIOS to automatically release and test software in the environment. The team may configure the CIOS to automatically test the rollback plan. The team will be able to review and approve the release through the CIOS UI. Teams may approve some, but not all, of the regional plans in the release. If "all latest versions" do not produce a suitable plan, the team may ask the CIOS to generate a plan for the preferentially chosen artifact version.

For the global release phase, the following is an example of how teams perform tomorrow's version of today's "normal CM". Once the release is approved, the CIOS pushes each approved region plan to the corresponding region. The CIOS acts independently within each region to apply the approved plan. The CIOS will only perform the set of actions explicitly described in the plan for that region. Instead of "thinking independently," it fails. The CIOS UI shows the team the progress of execution. When manual approval is required, the CIOS UI prompts the team. If the execution fails due to a CIOS or downstream service interruption, the CIOS may notify the team and may prompt them to perform subsequent steps (e.g., abort, retry). The CIOS does perform retries, but some downstream system interrupts may exceed their retry intentions. If execution fails due to a decrease in service health or test failure, the CIOS will assist the team to roll the group back to its starting state. The CIOS will notify (e.g., page) the team when it initiates an automatic rollback. The team must approve the rollback plan and the CIOS will then execute it.

For the tactical release phase, the following is an example of how a team performs the tomorrow version of the "emergency CM". When generating a plan, a team may request that the CIOS plan for a particular resource in several ways: by topology (e.g., domain, region, AD, etc.), by resource type (e.g., "measure-only configuration" or "deploy-only orchestration service deployment", etc.), or a combination of the above (e.g., in a separate manner). The team approves tactical releases just like global releases. The CIOS programs them in a similar manner. If a team needs to deploy tactical publications when there are active global publications, the CIOS will stop performing global publications in the target area and then start performing tactical publications.

In some examples, the state of a declarative provider (e.g., traditionally a file) is an authoritative record of a 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, some type of failure may prevent the actual identifier from being recorded in a state. When this happens, the actual identifier no longer belongs to the declarative provider. These may be referred to as "orphan resources".

For most resources, orphan (orphan) represents a waste-the declarative provider launches an instance that it forgets, for example, but will launch another instance the next time it runs. For resources with unique constraints or client-supplied identifiers, the orphan prevents the declarative provisioner from making progress. For example, if the declarative provisioner created user "nglass" and the failure orphaned it, then the next run of the declarative provisioner will attempt to create "nglass" and fail because the user with that username already exists. In some cases, orphans are only a problem when adding new resources to a state. In some cases, the refresh behavior of the declarative provider may naturally recover from failures to record updates and deletions.

The CIOS needs to be robust in the event of downstream servicing interrupts or interrupts of the CIOS itself. Because the CIOS can leverage declarative provisioners to apply changes, it means that running declarative provisioners and maintaining declarative provisioner states should be robust. The declarative provider performs a "small" retry-sufficient to avoid interruptions lasting several minutes. For example, the cloud provider will retry for up to 30 minutes. Downstream system outages lasting more than 30 minutes will cause the declarative provider to fail. When a declarative provider fails, it records all changes it successfully makes in the state and then exits. To retry, the CIOS must re-execute the declarative provisioner. Re-executing the declarative provisioner also allows the CIOS to retry when the CIOS itself fails. In some cases, the CIOS may run the following operations in a loop:

the refresh-declarative provisioner calls the GET API to retrieve a new snapshot of each resource described in its state.

Plan-declarative provisioner generates a plan (a specific set of API calls) that will implement the desired state in the current state of the last refresh.

Application-declarative provisioner execution plan set of steps.

When executing a declarative vendor, the CIOS may always run all three steps. The refresh operation facilitates recovery from any updates or deletions not recorded. The CIOS examines the results of the planning operation and compares it to the approved release plan. If the newly generated plan contains operations that are not in the approved release plan, the CIOS will fail and the service team can be notified.

FIG. 3 depicts a Directed Acyclic Graph (DAG)300 illustrating an example group 302. For a single group configuration in CIOS, the progress of the code/configuration from check-in to production may be described all the way from the first test deployment to the last product deployment. Internally, CIOS refers to each element in progress as an Execution Target (ET), which extends throughout our internal API, but does not leak into the group configuration. The CIOS executes ETs based on DAG 200 defined in the group configuration. Each ET (e.g., ET-1, ET-2, ET-3, ET-4, ET-5, ET-6, and ET-7) is approximately one copy of the service described by the group configuration.

Fig. 4 depicts a DAG 400 and an example group 402 for illustration. In the group configuration, CIOS is very natural on how teams express this schedule — they must model it using cloud infrastructure leases and regions. Teams should not use domains to model progress. CIOS allows teams to use multiple leases in a domain and multiple areas in a lease. However, CIOS does not allow teams to use the same area twice within a lease (but they may use the same area twice within a domain-in different leases). DAG 400 illustrates a version of DAG 300 in FIG. 3, represented by leases and regions. This example is directed to an overlay service, where a pre-prod ET is located in the prod region. The service enclave service will have unstable and stable leases in the release one. In DAG 400, IAD is the regional airport code for doles airport, washington, d.c., YYZ is the regional airport code for toronto, ontario, PHX, LHR, and FRA are the regional airport codes for phoenix city, london, and frankfurt, respectively, and LUF and LFI are for two different air force bases.

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

In some examples, a safety plan may be generated for safely treating the drift. The configuration file may include information indicating how the CIOS changes an area (e.g., a geographic area where the cloud infrastructure will be (or has been) set up). 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 new state expected after the change) is actually modified in the region. When a client interacts with the CIOS to spawn a global schedule, the security schedule determines, based on the current world (e.g., current state), which changes the CIOS will make to reach the world files (e.g., target state) described in the configuration. As described herein, the "world" may refer to an expected state of the cloud infrastructure, including all settings and configurations of cloud settings. 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 was generated and the time the deployment of the region was started. This change is drift. The CIOS may develop a security plan and ship it to various regions around the world (e.g., for transmission to various different CIOS regions). The planning task may be repeated whenever the CIOS is about to implement a change. For example, a current state may be expected and compared to a target state, and a difference (e.g., an increment, a difference, etc.) between the two may be generated. If the difference is a subset of the security plan, no drift occurs and the security plan can still be implemented. Otherwise, a security plan problem has been detected and changes need to be made prior to deployment. Further, in some examples, the CIOS may compare different security plans (e.g., to treat a phase change). For example, for a phased deployment (e.g., deploying resources to a first phase before other phases), the security plan may be reviewed and approved, and thus the deployment may be performed. Then, later, for stage 2 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 may be automatically approved even without sending anything to the client that generated the configuration file. It should be appreciated that this may speed up the deployment process, as no delay is introduced while waiting for approval of the new security plan, while also maintaining the integrity of the deployment, as no drift occurs in these cases. Alternatively, if there is something novel in the new security plan (e.g., east-west not present in the first security plan), this novel aspect may be presented to the user (e.g., client) via a User Interface (UI). The user may then approve or reject the novel aspect (e.g., enable or disallow the deployment change).

Techniques for implementing infrastructure orchestration services are described. In some examples, a security plan may 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 may be prepared for execution. The operation may be compared to a safety plan. If it is determined that the operation is part of a security plan, the operation may be performed. If it is determined that the operation is not part of a security plan, the deployment may be stopped and a notification that the deployment is not in compliance with the security plan may be transmitted. In some examples, if a drift occurs, the operation may not be part of the security plan.

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. A security plan may be received, which may include a list of resources and operations based on a deployment profile. Approval of the security plan may be received. An operation corresponding to at least one of the list of resources according to the deployment configuration file may be prepared for execution. The operation may be compared to a safety plan. If the operation is determined to be part of a security plan, the operation may be performed. If it is determined that the operation is not part of a security plan, the deployment may be stopped and a notification that the deployment is not in compliance with the security plan may be transmitted.

In further 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. A security plan may be received that may include a list of resources and operations based at least in part on the deployment configuration file. Approval of the security plan may be received. Based on the approval, an operation corresponding to at least one of the list of resources may be prepared for execution. The operation may be compared to a safety plan. If the operation is determined to be part of a security plan, the operation may be performed. If it is determined that the operation is not part of a security plan, the deployment may be stopped and a notification that the deployment is not in compliance with the security plan may be transmitted.

In other examples, a method may include receiving, by at least one of a plurality of computer processors, a security plan including a list of resources and corresponding operations based at least in part on a deployment profile. The method may further include, in accordance with 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 according to the deployment profile. The method may also include comparing the operation to a security plan. The method may also include performing, by at least one of the plurality of computer processors, the operation in accordance with the determination that the operation is part of the security plan. The method may further include, in accordance with a determination that the operation is not part of a security plan: halting, by at least one of the plurality of computer processors, 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.

FIG. 5 is a block diagram 500 of a CIOS that may generate and use security plans according to at least one embodiment. In some examples, the security plan may be a set of operations that have been approved by a user and that may be performed by the CIOS. Block diagram 500 illustrates an example CIOS architecture that may include a central control plane 502 and a zone data plane 504. The central control plane 502 may include a CIOS hub 506 (e.g., similar to the CIOS hub 102 of fig. 1), which may include a control plane 508, a change management module 510, a view/plan/approve module 512, and a status ingestor 514. The control plane 508 and the view/plan/approve module 512 may be communicatively coupled to a Local Area Network (LAN) gateway 516 that a user 518 may use to communicate with the CIOS center 506. The view/plan/approval module 512 and the state ingestor 514 may be communicatively coupled to a Wide Area Network (WAN)520 (e.g., the internet), and the wide area network 520 may be communicatively coupled to a CIOS area 522 (e.g., similar to the CIOS area 120 of fig. 1 or the CIOS area 202 of fig. 2) contained in the area data plane 504.

The CIOS area 522 may be communicatively coupled to a scheduler node 524 and a worker node 526. The worker 526 may be communicatively coupled to a dispatcher 524, and the dispatcher 524 may be communicatively coupled to a task Database (DB) 528. The worker 526 may be communicatively coupled to a docking station 530 that may include a CIOS container 532. The CIOS container 532 may be communicatively coupled to the signing agent 534, and the signing agent 534 may be communicatively coupled to the cloud service 536.

The CIOS area 522 may receive tasks from the CIOS hub 506 and may transmit the tasks to the scheduler 524. The tasks may include performing CRUD operations at the execution target(s) or any other suitable tasks for deploying infrastructure resources in the region. The scheduler 524 may record the tasks in a task DB 528 and may transmit the tasks to workers 526, which may be included in a worker queue. The worker queue may include many workers 526, and the scheduler 524 may select the worker 526 with the least amount of work or the most available computing resources to assign a task to. Scheduler 524 may assign tasks to worker 526 one at a time. The worker 526 may perform a task, and while performing the task, the worker may call the CIOS container 532 included in the docking station 530. The CIOS container 532 may perform tasks including infrastructure provisioning and/or deployment instructions (e.g., terrafrorm instructions). The instructions may direct the API call to a cloud service 536, which cloud service 536 may include services available to the region that may not be available via a public network (e.g., the internet). To make an API call to the cloud service 536, the CIOS container 532 may transmit a request to make the API call to the signing agent 534, which may determine whether the request is valid. In response to determining that the request is valid, the signing agent 534 may make an API call to the cloud service 536.

In some examples, user 518 may create a profile that may include operations to be performed in region data plane 504. The user 518 may transmit the configuration file to the CIOS center 506 via the LAN gateway 516, and the CIOS center 506 may be a computing device included in the central control plane 502. The configuration file may be received by the CIOS center 506 at the control plane 508 or at the view/plan/approve module 512. The change management module 510 may compile the configuration file into an area agnostic (RA) configuration file that may be used at the area data plane 504. The view/plan/approve module 512 or the state ingester 514 may transmit the RA profile to the CIOS area 522 via the WAN gateway 520, and the CIOS area 522 may be a computing device included in the area data plane 504.

The CIOS area 522 may receive the RA profile from the CIOS hub 506, and the CIOS area 522 may transmit the RA profile to the scheduler 524, and the scheduler 524 may create and transmit tasks to the task DB 528. The task may include compiling a set of operations to be performed at the execution target and may include comparing a current state of the resource at the execution target to an expected state of the resource at the execution target. The task may be transmitted to a worker 526 that may perform the task. While performing the task, the worker 526 may help create a security plan, which is a set of approved operations. The operations may include deploying a resource at an execution target or any other suitable operation to be performed at an execution target. Worker 526 may transmit the security plan to CIOS area 522, and CIOS area 522 may transmit the security plan to CIOS center 506 via WAN gateway 520.

The CIOS center 506 may receive the security plan from the CIOS area 522 and may compare the set of changes contained in the security plan to the operation at the execution target. The change management module 510 may perform this comparison and may make one of two determinations: the operation is a subset of a set of changes in the security plan or the operation is not a subset of a set of changes in the security plan. While only these two determinations are described in detail, other determinations may be made (e.g., how many percent differences exist between the change set and the security plan, etc.). In response to determining that the operation is a subset of the set of changes contained in the security plan, the operation may be performed, which may include deploying the resource at an execution target. In response to determining that the operation is not a subset of the set of changes contained in the security plan, a notification may be sent to user 518. The notification may be transmitted to the user 518 via the LAN gateway 516 and may include information that alerts the user 518 that a drift may have occurred or that an operation that may be scheduled to be performed at the execution target may not be included in the security plan. In response to viewing the notification, user 518 can approve or reject operations not included in the security plan. If the user 518 approves the operation, the operation is performed and the resource may be deployed at the execution target. If user 518 rejects the operation, the operation may not be performed and user 518 may decide to create a new profile or may decide to abort the operation. Thus, a security plan may be understood as a data structure that controls the functioning of the processor(s) that execute the deployment process by allowing operations to be executed if the operations are a subset of the set of changes contained in the security plan or suspending operations if the operations are not a subset of the changes contained in the security plan.

In other examples, user 518 may create a set of profiles that may include desired states of resources at a set of regions for executing a set of goals. The configuration file may be transmitted to the CIOS hub 506, and the CIOS hub 506 may compile the configuration file into a set of RA profiles, including one RA profile for each region. The RA profile may be transmitted to the corresponding area via the WAN gateway 520 and may be received by the CIOS area 522 included in the corresponding area.

In the respective areas, the CIOS area 522 may receive the respective RA profiles from the CIOS hub 506, and the CIOS area 522 may transmit the respective RA profiles to the scheduler 524, which may create and transmit tasks to the task DB 528. The task may include compiling a set of operations to be performed at an execution target in a respective region, and may include comparing a current state of the resource at the execution target with an expected state of the resource at the execution target. The task may be transmitted to a worker 526 that may perform the task. While performing the task, the worker 526 may help create a security plan, which is an approved set of operations. The operations may include deploying a resource at an execution target or any other suitable operation to be performed at an execution target. Worker 526 may transmit the security plan to CIOS area 522, and CIOS area 522 may transmit the security plan to CIOS center 506 via WAN gateway 520.

The CIOS center 506 may receive a set of security plans from a region and may compile the security plans into a master security plan (e.g., a security plan of the security plans), also described as a compiled security plan. Each security plan included in the compiled security plan may include similar changes. A difference in changes between the security plans contained in the compiled security plan may indicate that a drift has occurred in at least one region. The CIOS center 506 may compare changes contained in each security plan contained in the compiled security plans with operations at execution targets contained in the corresponding region. The change management module 510 may perform this comparison and may make one of two determinations: the operation is a subset of a set of changes in the compiled security plan or the operation is not a subset of a set of changes in the compiled security plan. In response to determining that the operation is a subset of the set of changes contained in the compiled security plan, the operation may be performed, which may include deploying resources at execution targets contained in the respective regions. In response to determining that the operation is not a subset of the set of changes contained in the compiled security plan, a notification can be sent to the user 518. The notification may be transmitted to the user 518 via the LAN gateway 516, and may include information that alerts the user 518 to: a drift may have occurred in the at least one region, or an operation that may be scheduled to be executed in the 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 reject operations not included in the security plan. If the user 518 approves the operation, the operation is performed and the resource may be deployed at the execution target contained in the corresponding region. If user 518 rejects the operation, the operation may not be performed and user 518 may decide to create a new profile or may decide to abort the operation.

Fig. 6 and 7 illustrate example flow

diagrams showing processes

600 and 700 for implementing a technique of CIOS, according to some embodiments of the present disclosure. The processes are illustrated as logical flow diagrams, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and so forth that perform particular functions or implement particular data types. 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 processes.

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

Fig. 6 is a flow diagram depicting a process 600 for using a security plan in a cloud infrastructure orchestration service according to at least one embodiment. Process 600 may begin at block 602, where a CIOS hub (e.g., CIOS hub 506 of FIG. 5) receives a security plan from a CIOS area (e.g., CIOS area 522 of FIG. 5) containing an area of execution targets. The security plan may include a list of resources and operations based on the deployment configuration file. The operations may include deploying instructions of a resource at an 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 plan may be compiled by the CIOS hub into a compiled security plan that may include resources and operations based on a deployment configuration file corresponding to execution targets, each of which is contained in a different region.

At block 604, the CIOS center prepares to perform at least one operation corresponding to at least one resource contained in the deployment configuration file. In response to receiving the security plan from the CIOS region, the CIOS center may prepare to execute the at least one operation in the at least one execution target, such as by compiling a local plan that may include the at least one operation. The operations may involve deploying at least one resource at an execution target. In some examples, the CIOS hub may prepare to execute a set of operations corresponding to a set of resources contained 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.

At block 606, the CIOS center compares the operation to the security plan. A change management module (e.g., change management module 510 of fig. 5), which may be included in the CIOS center, may perform the comparison. The comparison may involve determining whether the operation is a subset of the security plan. If the security plan includes the operation, 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.

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 hub to a CIOS area of the respective areas and may involve deploying, at the execution target, a resource contained in the deployment configuration file. In examples where it is desirable 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 a subset of the security plan, the CIOS center may transmit a command to each zone to perform the operation. The command may be transmitted by the CIOS hub to a CIOS region in each region and may involve deploying the resources contained in the deployment configuration file at each execution target.

At block 610, no operation is performed and deployment is halted. 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 the event that it is desired to deploy a resource 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 hub may cease operations that are not a subset of the security plan and may transmit a command to perform operations that are a subset of the security plan.

At block 612, the CIOS center transmits a notification to a user (e.g., user 518 of FIG. 5) that the deployment is not in compliance with the security plan. In response to determining that the operation is not a subset of the security plan (as is done at block 610), the CIOS center may create and transmit a notification to the user that the deployment no longer conforms to the security plan. The notification may present the user with the option of selecting continued deployment even if the operation is not a subset of the security plan. The user may choose to continue the deployment or may choose to abort the deployment. If the user chooses to abandon the deployment, the user may create another configuration file to attempt a different deployment. In the event that it is desired to deploy a resource at more than one execution target, the notification transmitted to the user may include a deployment that does not comply with the security plan. The CIOS hub may transmit a command to perform an operation that has been determined to be a subset of operations.

FIG. 7 is a flow diagram 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 area included in an area (e.g., CIOS area 522 of fig. 5) receives a configuration file for deploying infrastructure resources from a CIOS hub (e.g., CIOS hub 506 of fig. 5). The configuration file may include operations including instructions to deploy resources at execution targets included in the region.

At block 704, the CIOS area identifies a new current state of the cloud infrastructure in the area. The configuration file may define a desired state of the cloud infrastructure in the area, and in response to receiving the configuration file, the CIOS area may identify a current state of the resources in the area. In some examples, the current state may be similar or the same as the desired state. In other examples, the current state may not include any resources, and the desired state may include a majority of the resources desired to be deployed at the execution target.

At block 706, the CIOS area generates a security plan for deploying infrastructure resources based on the comparison between the current state and the expected state. The security plan may include operations that may be performed at the execution target. The operations may involve deploying infrastructure resources at an execution target. In some examples where the current state is similar or the same as the desired state, the security plan compiled by the CIOS region may be empty or may not include any operations.

At block 708, the CIOS area transmits a security plan for deploying infrastructure resources to the CIOS center. In response to creating the security plan, the CIOS area may transmit the security plan to the CIOS center to perform the comparison. As in block 608 of process 600, the CIOS center 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 region may perform the operation and may deploy the resources included in the configuration file at the execution target.

FIG. 8 illustrates an example swim lane diagram showing a process 800 for implementing a CIOS technique, according to certain embodiments of the present disclosure. This process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and so forth that perform particular functions or implement particular data types. 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.

Further, process 800 may be performed under control of one or more computing devices or computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or a combination thereof. As described above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. In some embodiments, process 800 may be performed in parallel by multiple processors. The computer readable storage medium may be non-transitory.

FIG. 8 is a swim lane diagram depicting a process 800, the process 800 depicting how a security plan is generated and used, in accordance with at least one embodiment. As shown, the graph includes three lanes: user lane 802, center lane 804, and region lane 806. The user swimlane 802 may include operations performed by a user (e.g., the user 518 of FIG. 5) or commands given to the computing system by the user. The center swimlane 804 may include operations performed by a CIOS center (e.g., CIOS center 506 of FIG. 5). Region swimlane 806 may include operations performed by a CIOS region (e.g., CIOS region 522 of FIG. 5).

Process 800 may begin at block 808, where a user creates a profile. A user may desire to deploy infrastructure resources at execution targets included in an area. In response to such a desire, a user may create a profile, which may define a desired state of the execution target. At block 810, the user sends the configuration to the CIOS center. In response to creating the configuration file, the user may transmit the configuration file to the CIOS center to initiate deployment.

At block 812, the CIOS center receives a configuration file from a user. In response to receiving the configuration file from the user, the CIOS center may initiate deployment. At block 814, the CIOS centric compiled area agnostic (RA) configuration file. In response to initiating deployment, the CIOS hub may compile a RA configuration, which may be a configuration file that may not be dependent on the area in which the RA configuration file is sent. At block 816, the CIOS hub transmits the RA configuration file to the CIOS area. In response to creating the RA profile, the CIOS hub may transmit the RA profile to a CIOS area of the area in which the resource is desired to be deployed.

At block 818, it is desired to receive the RA profile in the CIOS area of the area in which the resource is deployed. The RA profile may include operations performed to deploy infrastructure resources at an execution target. The CIOS area may transmit the RA profile to a worker node (e.g., worker 526 of FIG. 5) that may perform the comparison. At block 820, the CIOS area creates a security plan based on the new current state. The worker may compare the new current state of the infrastructure resources in the area to the expected state of the infrastructure resources defined in the RA profile. The CIOS area may create a security plan based at least in part on the comparison performed by the worker. The security plan may include changes to the approval of the resource at the execution target.

At block 822, the CIOS area transmits the security plan to the CIOS center. In response to creating the security plan, the CIOS area may transmit the security plan to the CIOS hub to determine whether an operation may be deployed at the execution target. At block 824, the CIOS center receives a security plan from the CIOS area. In some examples where it is desirable to deploy resources in more than one area, the CIOS center may receive more than one security plan. In this case, the CIOS center may compile a security plan of the security plans, hereinafter referred to as a compiled security plan. At block 826, the CIOS center compares the deployed operations to the security plan. The operations of deploying may include deploying instructions of infrastructure resources at an execution target. In the case of a compiled security plan, the CIOS center may compare the operations to the compiled security plan. At block 828, the CIOS center determines whether the operation is a subset of a 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.

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 area to perform 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 such a case, the CIOS hub may take no action. At block 832, the CIOS hub stops deployment in response to the CIOS hub determining that the operation is not a subset of the security plan. In this case, the CIOS center transmits a notification to the user that a drift has occurred and that the operation is not in compliance with the security plan. The notification may allow the user to allow the operation to be performed. If the user chooses not to allow the operation to be performed, 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.

Fig. 9 is a block diagram of a disconnect region 900 in accordance with at least one embodiment. The disconnection area 900 may be communicatively coupled to a connected CIOS hub 902 (e.g., CIOS hub 506 of fig. 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 hub 904 (e.g., CIOS hub 506 of FIG. 5), a scheduler node 906 (e.g., scheduler 524 of FIG. 5), a worker node 908 (e.g., worker 526 of FIG. 5), a docking station 910 (e.g., docking station 530 of FIG. 5) that may include a CIOS container 912 (e.g., CIOS container 532 of FIG. 5), and a signing agent 914 (e.g., signing agent 534 of FIG. 5). In some examples, the disconnection area 900 may be capable of receiving information/instructions from a connected CIOS hub 902; however, for communications from the disconnected region 900, the connected CIOS center 902 may be disconnected. In other words, the communication may be unidirectional, and once the connected CIOS center 902 sends information, it will not be possible to confirm what operation the disconnected region 900 performs.

The CIOS hub 904 may receive tasks from the connected CIOS hub 902 and may transmit the tasks to the scheduler 906. The tasks may include performing CRUD operations at the execution target(s) or any other suitable task for deploying infrastructure resources in the region. The scheduler 906 may transmit tasks to workers 908, which 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 amount of work or the most amount of available computing resources to assign a task thereto. The scheduler 906 may assign tasks to the workers 908 one at a time. The worker 908 may perform a task, and while performing the task, the worker may call a CIOS container 912 included in the docking station 910. The CIOS container 912 may perform tasks including a Terraform instruction. The instructions may direct the API calls to cloud services 916, which cloud services 916 may include services available to the disconnect region 900 that may not be available via a public network (e.g., the internet). To make an API call to the cloud service 916, the CIOS container 912 may transmit a request to the signing agent 914 to make the API call, and the signing agent 914 may determine whether the request is valid. In response to determining that the request is valid, the signing agent 914 may make an API call to the cloud service 916.

The connected CIOS center 902 may transmit a first security plan and configuration file to the CIOS center 904 for deploying infrastructure resources at an execution target in the disconnected region 900. The CIOS hub 904 may transmit the configuration file to the scheduler 906, and the scheduler 906 may assign tasks to the worker 908 to create a second security plan based on the configuration file. The first security plan may be created from a different profile that is similar or identical to the profile. In response to creating the second security plan, the worker 908 may transmit the second security plan to the CIOS center 904, and the CIOS center 904 may compare the first security plan to the second security plan. The CIOS hub 904 may determine that the second security plan is a subset of the first security plan in response to the comparison. In this case, the second security plan may be automatically approved and the profile-based infrastructure resources may be deployed at the execution targets in the disconnected region 900. The CIOS hub 904 may determine that the second security plan is not a subset of the first security plan. In this case, the deployment may be stopped and a notification may be transmitted to a user (e.g., user 518 of fig. 5) informing the user that a drift may have occurred and that the deployment does not comply with the second security plan. Further, in this example, if the second security plan is not a subset of the first security plan, the connected CIOS center 902 may send an instruction to the disconnected region 900 to stop any deployments originally planned.

Fig. 10 illustrates an example flow diagram of a process 1000 showing techniques for implementing CIOS in accordance with certain embodiments of the present disclosure. This process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and so forth that perform particular functions or implement particular data types. 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 a process.

Further, process 1000 may be performed under the control of one or more computing devices or computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or a combination thereof. As described above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. In some embodiments, process 1000 may be performed in parallel by multiple processors. The computer readable storage medium may be non-transitory.

FIG. 10 is a flow diagram depicting a process 1000 for using a security plan in a disconnected region 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 infrastructure resources that a user (e.g., user 518 of fig. 5) may desire to deploy at the first execution target and the second execution target. In some examples, the configuration file may contain resources for deployment at a first execution target, while the second configuration file may include resources for deployment at a second execution target.

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 execute at the first execution target. The first security plan may be generated by a CIOS center (e.g., CIOS center 506 of FIG. 5). The first execution target may be included in the connected region. The first security plan may be created based on a comparison of a current state of the resource at the first execution target and an expected state of the resource at the first execution target, which may be defined in a configuration file.

At block 1006, approval of the first security plan is received. The 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.

At block 1008, a second security plan for a second execution target is generated based on the configuration file. The second security plan may be generated by a CIOS center that may be included in a disconnected region (e.g., disconnected region 900 of fig. 9). Also, the second execution target may be included in the disconnection area. In some examples, a second security plan may be created for a second execution target based on a second profile. In some examples, the first execution objective and the second execution objective may be similar or identical, and the first security plan and the second security plan may be similar or identical.

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 approved changes in the second security plan to approved changes 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.

At block 1012, it is determined from the CIOS hub that the second security plan is a subset of the first security plan, and the second security plan is automatically approved based on approval of the first security plan. In this case, the CIOS center may automatically approve the second security plan without user input because the first security plan has been approved and because the first security plan may have successfully executed. In some examples, the current state of the second execution target may be similar or the same as the desired state of the second execution target defined in the configuration file. In this example, the second security plan may not include the change performed at the second execution target. In this case, the second security plan may be automatically approved by the CIOS center because the empty second security plan is a subset of the first security plan.

At block 1014, in accordance with the CIOS hub determining that the second security plan is not a subset of the first security plan, the CIOS hub halts deployment at the second execution target and notifies the user of the second security plan non-compliance. The CIOS center may stop deployment of infrastructure resources at the second execution target and may transmit a notification to the user that the user may have drifted 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) select to deploy the resource despite the CIOS hub determining that the second security plan is not in compliance, (ii) abandon the 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.

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

Illustrative System

11-13 illustrate aspects of an example environment for implementing aspects of the present disclosure in accordance with various embodiments. FIG. 11 depicts a simplified diagram of a distributed system 1100 for implementing embodiments of the present disclosure. 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 the network(s) 1110. Server 1112 may be communicatively coupled to remote

client computing devices

1102, 1104, 1106, and 1108 via network 1110.

In various embodiments, the 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 some embodiments, the server 1112 may also provide other services or software applications may include non-virtual and virtual 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. A user operating

client computing devices

1102, 1104, 1106, and/or 1108 may then interact with server 1112 using one or more client applications to take advantage of the services provided by these components.

In the configuration depicted in FIG. 11,

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 those components may also be implemented by one or more of

client computing devices

1102, 1104, 1106, and/or 1108. A user operating the client computing device may then utilize one or more client applications to use 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, which may differ from distributed system 1100. Thus, the embodiment shown in FIG. 11 is one example, not limiting, of a distributed system for implementing the embodiment system.

Client computing devices

1102, 1104, 1106, and/or 1108 may include various types of computing systems. For example, the client computing devices may include portable handheld devices (e.g.,

a cellular phone,

Computing tablet, Personal Digital Assistant (PDA)) or wearable device (e.g., Google)

Head mounted display) that operates a display device such as Microsoft Windows

Such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, and/or various mobile operating systems. The client computing devices 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 devices may also include general purpose personal computers, e.g., running versions of Microsoft Windows

Apple

And/or a personal computer and/or a laptop computer of a Linux operating system. The client computing devices may be any of a variety of commercially available

Or UNIX-like operating systems (including but not limited to various GNU/Linux operating systems such as the Google Chrome OS). The client computing devices can also include electronic devices capable of providing network(s) 1110 communications, such as thin-client computers, internet-enabled gaming systems (e.g., with or without a network connection, etc.)

Microsoft of gesture input device

Game consoles) and/or personal messaging devices.

Although the distributed system 1100 in fig. 11 is illustrated as having four client computing devices, any number of client computing devices may be supported. Other devices (such as devices with sensors, etc.) can interact with the server 1112.

Network(s) 1110 in distributed system 1100 may be any type of network(s) familiar to those skilled in the art that may support data communications using any of a variety of available protocols, including but not limited to TCP/IP (transmission control protocol/internet protocol), SNA (system network architecture), IPX (internet packet exchange), AppleTalk, and the like. By way of example only, network(s) 1110 may be a Local Area Network (LAN), Ethernet-based network, token Ring, Wide area network, the Internet, virtual network, Virtual Private Network (VPN), intranet, extranet, Public Switched Telephone Network (PSTN), Infrared, and so forthNetworks, wireless networks (e.g., in any of the Institute of Electrical and Electronics Engineers (IEEE)1002.11 protocol suite, the Internet, the computer-readable storage medium, and the like,

And/or any other network operating under a wireless protocol) and/or any combination of these and/or other networks.

The server(s) 1112 can be comprised of one or more general purpose computers, special purpose server computers (including, by way of example, PC (personal computer) servers, and the like,

Servers, midrange servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and/or combination. The servers 1112 can include one or more virtual machines running a virtual operating system, or other computing architecture involving virtualization. One or more flexible logical storage pools may be virtualized to maintain virtual storage for the servers. The virtual networks may be controlled by the server 1112 using software-defined networking. In various embodiments, the server 1112 can be adapted to run one or more services or software applications described in the foregoing disclosure. For example, the server 1112 may correspond to a server for performing the processing according to the embodiment of the present disclosure as described above.

The server 1112 can execute an operating system including any of the operating systems discussed above, as well as any commercially available server operating system. The servers 1112 can also execute any of a variety of additional server applications and/or intermediate layer applications including HTTP (HyperText transfer protocol) servers, FTP (File transfer protocol) servers, CGI (common gateway interface) servers, Web services, and the like,

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), and the like.

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 an example, data feeds and/or event updates may include, but are not limited to

Feeding,

Updates or real-time updates received from one or more third-party information sources and the continuous data stream, which may include real-time events related to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like. The 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 the

client computing devices

1102, 1104, 1106, and 1108.

The distributed system 1100 may also include one or more databases 1114 and 1116. These databases may provide mechanisms 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 non-transitory storage media local to server 1112 (and/or resident in server 1112). Alternatively, databases 1114 and 1116 may be remote from server 1112 and in communication with server 1112 via a network-based or dedicated connection. In one set of embodiments, 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 stored locally and/or remotely as appropriate. In one set of embodiments, databases 1114 and 1116 may comprise a relational database suitable for storing, updating, and retrieving data in response to SQL-formatted commands, such as the database provided by Oracle.

FIG. 12 illustrates an example computer system 1200 that can be used to implement embodiments of the present disclosure. In some embodiments, computer system 1200 may be used to implement any of the various servers and computer systems described above. As shown in fig. 12, 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 communications subsystem 1224. The storage subsystem 1218 may include tangible computer-readable storage media 1222 and system memory 1210.

Bus subsystem 1202 provides a mechanism for letting the various components and subsystems of computer system 1200 communicate with each other as intended. Although the bus subsystem 1202 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1202 may 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 Micro Channel 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 in accordance with the IEEE P1386.1 standard, or the like.

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 unit 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 special-purpose coprocessors, such as a graphics processor, a Digital Signal Processor (DSP), or the like. 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).

In some embodiments, the processing units in processing subsystem 1204 may execute instructions stored in system memory 1210 or on computer-readable storage media 1222. In various embodiments, the processing unit may execute various programs or code instructions and may maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed may reside in system memory 1210 and/or on computer-readable storage media 1210, including potentially on one or more storage devices. With appropriate programming, the processing subsystem 1204 may provide the various functions described above for dynamically modifying a document (e.g., a web page) in response to usage patterns.

In some 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 accelerating the overall processing performed by the computer system 1200.

I/O subsystem 1208 may include devices and mechanisms for inputting information to computer system 1200 and/or for outputting information from or via 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 to 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 the display, a scroll wheel, a click wheel, a dial, buttons, switches, a keyboard, an audio input device with voice command recognition system, a microphone, and other types of input devices. The user interface input device may also include a motion sensing and/or gesture recognition device, such as Microsoft Windows enabling a user to control and interact with the input device

Motion sensor, Microsoft Windows

360 game controller, a device providing an interface for receiving input using gestures and voice commands. The user interface input device may also include an eye gesture recognition device, such as detectionEye activity of the user (e.g., "blinking" while taking a picture and/or making a menu selection) and transforming eye gestures into an input device (e.g., Google)

) Input of (2) Google

A blink detector. In addition, the user interface input device may include a device that enables a user to interact with a speech recognition system (e.g.,

navigator) an interactive voice recognition sensing device.

Other examples of user interface input devices include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and tablets, and audio/video devices such as speakers, digital cameras, portable media players, web cameras, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye gaze tracking devices. Further, the user interface input device may comprise, for example, a medical imaging input device, such as a computed tomography, magnetic resonance imaging, positional emission tomography, medical ultrasound examination device. The user interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, and the like.

The user interface output devices may include a display subsystem, indicator lights, or a non-visual display (such as an audio output device). The display subsystem may be a Cathode Ray Tube (CRT), a flat panel device such as one that utilizes a Liquid Crystal Display (LCD) or a plasma display, a projection device, a touch screen, or the like. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1200 to a user or other computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio/video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

Storage subsystem 1218 provides a repository or data store for storing information used by computer system 1200. 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. Software (programs, code modules, instructions) that when executed by the processing subsystem 1204 provide the functionality described above may be stored in the storage subsystem 1218. The software may be executed by one or more processing units of the processing subsystem 1204. Storage subsystem 1218 may also provide a repository for storing data used in accordance with the present disclosure.

The storage subsystem 1218 may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. As shown in fig. 12, the storage subsystem 1218 includes a system memory 1210 and computer-readable storage media 1222. The system memory 1210 may include a number of memories, including a volatile main Random Access Memory (RAM) for storing instructions and data during program execution and a non-volatile Read Only Memory (ROM) or flash memory in which fixed instructions are stored. In some implementations, a basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 1200, such as during start-up, may be stored in ROM. The RAM may contain data and/or program modules that are currently being operated on and executed by the processing subsystem 1204. In some implementations, the system memory 1210 may include a variety of different types of memory, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

By way of example, and not limitation, as depicted in FIG. 12, system memory 1210 may store application programs 1212, application programs 1212 may include client applications, Web browsers, middle tier applications, a relational database management system (RDBMS), and the like, program data 1214, and an operating system 1216. For example, the operating system 1216 may include various versions of Microsoft Windows

Apple

And/or Linux operating system, various commercially available

Or UNIX-like operating systems (including but not limited to various GNU/Linux operating systems, Google)

OS, etc.) and/or mobile operating systems (such as iOS, OS, and/or the like,

Phone、

OS、

10OS and

OS operating system).

Computer-readable storage media 1222 may store programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that the processor provides the above described functionality when executed by the processing subsystem 1204 may be stored in the storage subsystem 1218. By way of example, computer-readable storage medium 1222 may include non-volatile memory, such as a hard disk drive, a magnetic disk drive, an optical disk drive (such as a CD ROM, DVD, or the like),

A disc 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, securityAll digital (SD) cards, DVD disks, digital video tapes, and the like. The computer-readable storage media 1222 may also include non-volatile memory based Solid State Drives (SSDs), such as flash memory based SSDs, enterprise flash drives, solid state ROMs, etc., volatile memory based SSDs, such as solid state RAM, dynamic RAM, static RAM, DRAM based SSDs, magnetoresistive RAM (mram) SSDs, and hybrid SSDs that use both DRAM and flash memory based SSDs. Computer-readable media 1222 may provide storage of computer-readable instructions, data structures, program modules, and other data for computer system 1200.

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

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

Communications subsystem 1224 provides an interface to other computer systems and networks. Communications subsystem 1224 serves as an interface to receive data from other systems and to transmit data from computer system 1200 to other systems. For example, communication subsystems 1224 may enable computer system 1200 to establish a communication channel via the internet to one or more client devices for receiving information from and transmitting information to the client devices. Additionally, the communications subsystem 1224 may be used to communicate a notification of a successful login or a notification of re-entering a password from a privileged account administrator to a requesting user.

Communications subsystem 1224 may support wired and/or wireless communications protocols. For example, in some embodiments, communication subsystem 1224 may include a Radio Frequency (RF) transceiver component (e.g., using cellular telephone technology, advanced data network technologies 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 for accessing a wireless voice and/or data network.

Communications subsystem 1224 may receive and transmit data in various forms. For example, in some embodiments, communications subsystem 1224 may receive input communications in the form of structured and/or unstructured data feeds 1226, event streams 1228, event updates 1230, and so forth. For example, communication subsystem 1224 may be configured to receive (or transmit) in real-time data feeds 1226 (such as those from users of social media networks and/or other communication services)

Feeding,

Updates, web feeds such as Rich Site Summary (RSS) feeds), and/or real-time updates from one or more third-party information sources.

In some embodiments, communications subsystem 1224 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1228 and/or event updates 1230 of real-time events, which may be continuous or unbounded in nature, with no explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial codes, network performance measurement tools (e.g., network monitoring and traffic management applications), click stream analysis tools, automotive traffic monitoring, and so forth.

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

Computer system 1200 may be one of various types, including a hand-portable device (e.g.,

a cellular phone,

Computing tablet, PDA), wearable device (e.g., Google)

Head mounted display), personal computer, workstation, mainframe, kiosk, server rack, or any other data processing system.

Due to the ever-changing nature of computers and networks, the description of computer system 1200 depicted in FIG. 12 is intended only as a specific example. Many other configurations with more or fewer components than the system depicted in fig. 12 are possible. 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.

The systems depicted in some of the figures may be provided in a variety of configurations. In some embodiments, the system may 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.

A cloud infrastructure system is a collection of one or more server computing devices, network devices, and/or storage devices. These resources may be partitioned by the cloud service provider and distributed to its customers in some manner. For example, a cloud service provider, such as Oracle corporation, redwood shore, california, may provide various types of cloud services, including, but not limited to, one or more services provided under the software as a service (SaaS) category, services provided under the platform as a service (PaaS) category, services provided 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 functionality of building and delivering a suite of on-demand applications, such as Oracle Fusion applications. The SaaS service enables customers to utilize applications executing on the cloud infrastructure system without requiring the customers to purchase 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, and the ability to build new applications that leverage shared services provided by the platform (such as Oracle Java Cloud Services (JCS), Oracle database cloud services (DBCS), etc.. IaaS services can help manage and control underlying computing resources, such as storage, networks, and other basic computing resources, for customers to leverage services provided by SaaS platforms and PaaS platforms.

Fig. 13 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 system environment 1300, services provided by one or more components of an embodiment system may be provided as cloud services. In the illustrated embodiment, system environment 1300 includes one or more

client computing devices

1304, 1306, and 1308 that may be used by a user to interact with cloud infrastructure system 1302 that provides cloud services. The client computing device may be configured to operate a client application, such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application, that may be used by a user of the client computing device to interact with the cloud infrastructure system 1302 to use services provided by the cloud infrastructure system 1302.

It should be appreciated that the cloud infrastructure system 1302 depicted in the figure may have other components than those depicted. Additionally, the embodiment shown in the figures is merely one example of a cloud infrastructure system that may incorporate embodiments of the present disclosure. In some other embodiments, cloud infrastructure system 1302 may have more or fewer components than shown in the figure.

Client computing devices

1304, 1306, and 1308 may be devices similar to the devices described above for

client computing devices

1102, 1104, 1106, and 1108.

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

Network(s) 1310 may facilitate data communication and exchange between

clients

1304, 1306, and 1308 and cloud infrastructure system 1302. Each network 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 commercially available protocols, including those described above for network(s) 1110.

Cloud infrastructure system 1302 may include one or more computers and/or servers, which may include those described above for server 1112.

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 so forth. The services provided by the cloud infrastructure system can be dynamically expanded to meet the needs of its users. The 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 system of cloud service providers 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 system of a cloud service provider may host an application, and a user may order and use the application on demand via a communication network such as the internet.

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 to users by cloud providers, or as otherwise known in the art. For example, the service may include password-protected access to remote storage on the cloud over the internet. As another example, a service may include a hosted relational database based on web services and a scripting language middleware engine for private use by networked developers. As another example, the service may include access to an email software application hosted on a website of the cloud provider.

In certain embodiments, cloud infrastructure system 1302 may include application suites, middleware, and database services products that are delivered to consumers in a self-service, subscription-based, elastically extensible, reliable, highly available, and secure manner. An example of such a Cloud infrastructure system is the Oracle Public Cloud (Oracle Public Cloud) provided by the present assignee.

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

In some embodiments, the services provided by cloud infrastructure system 1302 may include one or more services provided under a software as a service (SaaS) category, a platform as a service (PaaS) category, an infrastructure as a service (IaaS) category, or other service categories including hybrid services. A customer, via a subscription order, may order one or more services provided by cloud infrastructure system 1302. Cloud infrastructure system 1302 then performs processing to provide the services in the customer's subscription order.

In some embodiments, the services provided by 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 a cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services belonging to the SaaS category. For example, the 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 the SaaS services. By utilizing the services provided by the SaaS platform, consumers may utilize applications executing on the cloud infrastructure system. The consumer can obtain the application service without the consumer separately purchasing licenses and support. Various 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 flexibility for large organizations.

In some embodiments, platform services may be provided by the cloud infrastructure system 2702 via a PaaS platform. The PaaS platform may 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 with shared services provided by the platform. The PaaS platform may manage and control the underlying software and infrastructure used to provide PaaS services. A consumer can obtain PaaS services provided by a cloud infrastructure system without requiring the consumer 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.

By leveraging the services provided by the PaaS platform, consumers can employ 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 a database cloud service, a Middleware cloud service (e.g., Oracle Fusion Middleware service), and a Java cloud service. In one embodiment, the database cloud service may support a shared service deployment model that enables an organization to aggregate database resources and provide databases as a service to consumers in the form of a database cloud. The middleware cloud service may provide a platform for consumers to develop and deploy various business applications, and the Java cloud service may provide a platform for consumers to deploy Java applications in the cloud infrastructure system.

Various infrastructure services may be provided by an IaaS platform in a cloud infrastructure system. Infrastructure services facilitate management and control of underlying computing resources, such as storage, networks, and other basic computing resources, for consumers to utilize services provided by SaaS platforms and PaaS platforms.

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

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

In certain embodiments, a plurality of internal shared services 1332 may be provided that are shared by different components or modules of cloud infrastructure system 1302 and services provided by cloud infrastructure system 1302. These internal sharing 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 restore services, services for enabling cloud support, email services, notification services, file transfer services, and the like.

In certain embodiments, cloud infrastructure system 1302 may provide integrated management of cloud services (e.g., SaaS, PaaS, and IaaS services) in a cloud infrastructure system. In one embodiment, cloud management functionality may include the ability to provision, manage, and track subscriptions of consumers received by cloud infrastructure system 1302, or the like.

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

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 some embodiments, the consumer may access a cloud User Interface (UI), cloud UI 1312, cloud UI 1314, and/or cloud UI1316 and place a subscription order via these UIs. The order information received by cloud infrastructure system 1302 in response to a customer placing an order may include information identifying the customer and one or more services provided by cloud infrastructure system 1302 to which the customer intends to subscribe.

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

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

At operation 1338, the order information is forwarded to the order management module 1320. In some instances, the order management module 1320 may be configured to perform billing and accounting functions related to the order, such as validating the order and, after validation, booking the order.

At operation 1340, information regarding the order is communicated to the order orchestration module 1322. Order orchestration module 1322 may utilize the order information to coordinate the provision of services and resources to place orders for customers. In some instances, the order orchestration module 1322 may coordinate the provision of resources using the services of the order provisioning module 1324 to support the subscribed services.

In some embodiments, order orchestration module 1322 enables management of the business processes associated with each order and application of business logic to determine whether the order should proceed to supply. At operation 1342, upon receiving an order for a new subscription, the order orchestration module 1322 sends a request to the order provisioning module 1324 to allocate resources and configure those resources needed to complete the subscribed order. The order-provisioning module 1324 enables the allocation of resources for the services to which the customer subscribes. 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 may 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.

At operation 1344, once the services and resources are provisioned, a notification of the services provided may be sent to the customer on the client computing device 1304, 1306, and/or 1308 via the order providing 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 runtime, and system downtime.

In certain embodiments, cloud infrastructure system 1300 may include 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, identity management module 1328 may control information about consumers who wish to utilize services provided by cloud infrastructure system 1302. Such information may include information that authenticates the identity of such consumers and information that describes actions that 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 is accessed and modified.

While specific embodiments of the disclosure have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the disclosure. Embodiments of the present disclosure are not limited to operation within certain specific data processing environments, but may operate freely within multiple data processing environments. Further, although embodiments of the disclosure have been described using a particular series of transactions and steps, it should be clear to those skilled in the art that the scope of the disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above-described embodiments may be used alone or in combination.

In addition, although embodiments of the present disclosure have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments of the present disclosure may be implemented in hardware only, or software only, or a combination thereof. The various processes described herein may be implemented on the same processor or on different processors in any combination. Accordingly, where a component or module is described as being configured to perform certain operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, by programming programmable electronic circuitry (such as a microprocessor) to perform the operations, or any combination thereof. The processes may communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereto without departing from the broader spirit and scope as set forth in the claims. Thus, while specific disclosed embodiments have been described, these embodiments are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims. The modifications include any relevant combination of the disclosed features.

Some exemplary items of the present disclosure are described below.

Item 1: a method, comprising:

receiving, by at least one of the plurality of computer processors, a security plan comprising a list of resources and corresponding operations based at least in part on the deployment profile; and

in accordance with 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 according to the deployment profile;

comparing the operation to a security plan;

in accordance with a determination that the operation is part of a security plan, performing the operation by at least one of the plurality of computer processors; and

in accordance with a determination that the operation is not part of a security plan:

halting, by at least one of the plurality of computer processors, 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.

Item 2. the method of item 1, the plurality of processors associated with an execution target.

Item 3. the method of item 2, wherein the execution objective comprises a geographic region.

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

Item 5. the method of item 4, wherein the deployment profile is generated by a user of the central cloud infrastructure orchestration service.

Item 6. the method of item 1, wherein the respective operation comprises 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.

Project 7 the method of project 1, further comprising stopping deployment by at least one of the plurality of computer processors based on receiving disapproval of the security plan or not receiving approval of the security plan.

Item 8 the method of item 1, further comprising generating, by at least one of the plurality of computer processors, a local plan with local operations according to the deployment configuration file, and wherein comparing the operations to the security plan includes comparing one of the local operations to the security plan.

Item 9. a computer-readable storage medium comprising instructions written thereon, which, when executed by a computer processor, cause the computer processor to perform operations comprising:

receiving a security plan comprising a list of resources and corresponding operations based at least in part on a deployment profile; and

in accordance with receiving an indication of approval of the security plan:

preparing to perform an operation corresponding to at least one resource in the list of resources according to the deployment configuration file;

comparing the operation to a security plan;

in accordance with a determination that the operation is part of a security plan, performing the operation; and

stopping deployment; and

a notification that the deployment is not in compliance with the security plan is transmitted.

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

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 particular execution goal or a particular deployment phase.

Project 12 the computer-readable storage medium of project 11, wherein the central cloud infrastructure orchestration service is further configured to generate the list of security plans concurrently with and prior to receiving approval or disapproval of the list of security plans.

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 of the plurality of deployment profiles interpreted for each respective execution target on the list of security plans.

Item 14 the computer-readable storage medium of item 10, wherein the operations further comprise transmitting the security plan to a central cloud infrastructure orchestration service.

Item 15 the computer-readable storage medium of item 14, wherein the central cloud infrastructure orchestration service is configured to:

rendering a security plan on a user interface of a user computer; and

approval or disapproval of the security plan is received.

Item 16. a system, comprising:

a processor; and

a memory storing instructions that, when executed by the processor, configure the system to:

in accordance with receiving an indication of approval of the security plan:

comparing the operation to a security plan;

stopping deployment; and

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

Item 18 the system of item 16, wherein the operation is not part of a security plan based at least in part on an operation change that occurs with one of the resources prior to the operation being performed.

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

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

Item 21. an apparatus comprising means for the steps according to any one of items 1-8.

Item 22. a method, comprising:

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;

generating, by at least one 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 including a first list of resources and corresponding operations associated with deployment at the first execution target;

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

generating, by at least one 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 security plan is a subset of the first security plan; and

in accordance with a determination that the second security plan is a subset of the first security plan:

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

transmitting, by at least one of the plurality of computer processors, the automatically approved second security plan to a second execution target.

Item 23 the method of item 22, further comprising, in accordance with a determination that the second security plan is not a subset of the first security plan, preparing a user interface to present:

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.

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.

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.

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 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.

Item 27. the method of item 22, wherein the first execution objective is a connection region of a cloud infrastructure orchestration service.

Item 28. the method of item 27, wherein the second execution objective is a disconnected region of the cloud infrastructure orchestration service.

Item 29 the method of item 28, wherein the disconnected region comprises an environment configured to receive instructions for deployment to the disconnected region, and wherein the disconnected region is further configured not to transmit any data outside of the disconnected region.

Item 30. the method of item 28, wherein the second security plan is used for deployment at a second execution target.

Item 31 the method of item 30, wherein the second security plan is further automatically approved in accordance with the determination based at least in part on a successful deployment of the first security plan at the first execution target.

An item 32 a computer-readable storage medium comprising instructions written thereon that, when executed by a computer processor, cause the computer processor to perform instructions comprising:

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

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

receiving approval of the first security plan;

generating a second security plan for the 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 whether the second security plan is a subset of the first security plan; and

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

the automatically approved second security plan is transmitted to a second execution target.

Item 33 the computer-readable storage medium of item 32, wherein the instructions further comprise, in accordance with a determination that the second security plan is not a subset of the first security plan, preparing a user interface to present:

Item 34 the computer-readable storage medium of item 33, wherein the instructions further comprise 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.

Item 35 the computer-readable storage medium of item 34, 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.

Item 36. the computer-readable storage medium of item 32, wherein the second execution goal is a disconnected region of the cloud infrastructure orchestration service, and wherein the disconnected region comprises an environment configured to receive instructions for deployment to the disconnected region, and wherein the disconnected region is further configured to not transmit any data outside of the disconnected region.

Item 37 the computer-readable storage medium of item 36, wherein the second security plan is for deployment at the second execution goal, and wherein the second security plan is further automatically approved in accordance with the determination based at least in part on the success of the deployment of the first security plan at the first execution goal.

Item 38. a system, comprising:

a processor; and

receiving approval of the first security plan;

Item 39 the system of item 38, wherein the system is further configured to 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.

Item 40 the system of item 39, 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 at least one difference over all other visual representations of the second list of resources and corresponding operations of the second security plan.

Item 41. the system of item 38, wherein the second execution objective is a disconnected region of the cloud infrastructure orchestration service, and wherein the disconnected region comprises an environment configured to receive instructions for deployment to the disconnected region, and wherein the disconnected region is further configured not to transmit any data outside of the disconnected region, and wherein the second security plan is for deployment at the second execution objective, and wherein the second security plan is further automatically approved in accordance with the determination based at least in part on the success of the deployment of the first security plan at the first execution objective.

Item 42. an apparatus comprising means for the steps according to any of items 22-31.

Claims

1. A method, comprising:

2. The method of claim 1, further comprising, in accordance with a determination that the second security plan is not a subset of the first security plan, preparing a user interface for presentation of:

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 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.

5. The method of any preceding claim, wherein determining whether the second security plan is a subset of the first security plan comprises determining, by at least one 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.

6. The method of any preceding claim, wherein the first execution objective is a connection region of a cloud infrastructure orchestration service.

7. The method of claim 6, wherein the second execution objective is a disconnected region of the cloud infrastructure orchestration service.

8. The method of claim 7, wherein the disconnected region comprises an environment configured to receive instructions for deployment to the disconnected region, and wherein the disconnected region is further configured not to transmit any data outside of the disconnected region.

9. The method of claim 7 or 8, wherein the second security plan is used for deployment at the second execution target.

10. The method of claim 9, wherein the second security plan is automatically approved further in accordance with the determination that the deployment at the first execution target based at least in part on the first security plan is successful.

11. 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 approval of the first security plan;

12. The computer-readable storage medium of claim 11, wherein the instructions further comprise in accordance with a determination that the second security plan is not a subset of the first security plan, preparing a user interface for presentation of:

13. The computer-readable storage medium of claim 12, wherein the instructions further comprise 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.

14. The computer-readable storage medium of claim 13, 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.

15. The computer-readable storage medium of any of claims 11 to 14, wherein the second execution objective is a disconnected region of the cloud infrastructure orchestration service, and wherein the disconnected region comprises an environment configured to receive instructions for deployment to the disconnected region, and wherein the disconnected region is further configured to not transmit any data outside of the disconnected region.

16. The computer-readable storage medium of claim 15, wherein the second security plan is for deployment at the second execution target, and wherein the second security plan is automatically approved further in accordance with the determination that the deployment at the first execution target based at least in part on the first security plan is successful.

17. A system, comprising:

a processor; and

receiving approval of the first security plan;

18. The system of claim 17, wherein the system is further configured to, in accordance with a determination that the second security plan is not a subset of the first security plan, prepare a user interface for:

19. The system of claim 18, wherein the system is further configured to:

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.

20. The system of any of claims 17 to 19, wherein the second execution objective is a disconnected region of the cloud infrastructure orchestration service, and wherein the disconnected region comprises an environment configured to receive instructions for deployment to the disconnected region, and wherein the disconnected region is further configured to not transmit any data outside of the disconnected region, and wherein the second security plan is for deployment at the second execution objective, and wherein the second security plan is further automatically approved in accordance with the determination that deployment at the first execution objective based at least in part on the first security plan is successful.

21. An apparatus comprising means for the steps of any one of claims 1-10.