Consent-driven access management for cloud resources

Abstract

Consent-driven access management technology involves receiving a request from a requester seeking consent for an actor to access a target set of resources in a cloud environment; identifying a consent workflow that specifies the names and / or attributes of one or more user groups from which to obtain the corresponding approvals for the consent request; traversing the consent workflow to obtain the corresponding approvals from one or more user groups; and determining that one or more access policies separate from the consent workflow permit the actor to access the target set of resources, wherein the actor's access to the target set of resources is based on both (a) obtaining the corresponding approvals from one or more user groups and (b) determining that one or more access policies separate from the consent workflow permit the actor to access the target set of resources.

Description

Technical Field

[0001] Incorporation by reference, waiver of rights Each of the following applications is hereby incorporated by reference into this specification: Application No. 18 / 647,781 filed on April 26, 2024, and Application No. 63 / 462,875 filed on April 28, 2023. The applicant hereby disclaims any waiver of rights in the scope of the claims in the parent application or during the prosecution of that application, and notifies the USPTO that the claims of this application may be broader than any claims of the parent application.

[0002] Technical Field This disclosure relates to cloud environments. More particularly, this disclosure relates to access management in cloud partitions of cloud environments.

Background Art

[0003] Background Using cloud computing environments, access can be provided to various complementary cloud-based components such as software applications or services that enable an organization or enterprise customer to operate its applications and services in a highly available host environment.

[0004] The benefits for an organization to migrate its application and service needs to a cloud environment include reducing the costs and complexities of designing, building, operating, and maintaining its own on-premises data center, software application framework, or other information technology infrastructure.

Summary of the Invention

Problems to be Solved by the Invention

[0005] A Cloud Service Provider (CSP) is an entity that provides cloud services to tenants in a cloud environment. When another entity, such as the organizations mentioned above, begins a subscription to the cloud services provided by a CSP, that entity becomes a CSP customer and a tenant of the CSP's cloud environment. A CSP's customers may include resellers, service providers, payment processors, and / or other entities that use cloud services.

[0006] Cloud environments enable the provisioning of resources across multiple cloud partitions. The cloud system further provides on-demand network access to a shared pool of cloud computing resources (e.g., networks, servers, storage, applications, and services) that can be provisioned, deployed, and instantiated for each customer. Through network access, the CSP manages and configures the hardware required to deliver cloud services (e.g., networking infrastructure, processors, memory, etc.), controls the provisioning of cloud services, and delivers them. The cloud system can allocate cloud partitions to each customer and manage and maintain them according to the customer's specific application and service needs. To ensure sufficient resources to meet these needs, the CSP typically maintains complete access control to all resources within the cloud partition.

[0007] The methods described in this section are feasible, but they are not necessarily methods that have been conceived or implemented before. Therefore, unless otherwise specified, it should not be assumed that any of the methods described in this section qualify as prior art simply because they are described in this section.

[0008] In each of the accompanying drawings, embodiments are shown as examples, not as limitations. It should be noted that references to “an” or “one” embodiments in this disclosure do not necessarily refer to the same embodiment, but rather mean at least one. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows a system that provides a cloud infrastructure environment according to one embodiment. [Figure 2] This diagram further illustrates how a cloud infrastructure environment can be used to provide a cloud-based application or service or service, according to one embodiment. [Figure 3] This figure shows an example of a cloud infrastructure architecture according to one embodiment. [Figure 4] This figure shows another example of a cloud infrastructure architecture according to one embodiment. [Figure 5] This figure shows another example of a cloud infrastructure architecture according to one embodiment. [Figure 6] This figure shows another example of a cloud infrastructure architecture according to one embodiment. [Figure 7] This diagram shows how, in one embodiment, the system can provide a dedicated or private label cloud environment used by tenants or customers of a cloud infrastructure environment. [Figure 8] This figure further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment. [Figure 9] This figure further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment. [Figure 10]This figure shows a system, according to one embodiment, for providing access to software products or services in a cloud computing environment or other computing environment. [Figure 11] This diagram shows a consent-driven access management system in a cloud partition within a cloud environment. [Figure 12] This figure shows an example of a set of actions for consent-driven access management in cloud partitions of a cloud environment, according to one or more embodiments. [Figure 13A] This figure shows examples of graphical user interfaces (GUIs) for managing consent requests between a first entity and a second entity in a cloud environment, according to one or more embodiments. Figure 13A specifically shows an example of a GUI used by the first entity to request consent for an agent to access a target set of resources within the second entity's cloud partition. [Figure 13B] This figure shows examples of graphical user interfaces (GUIs) for managing consent requests between a first entity and a second entity in a cloud environment, according to one or more embodiments. Figure 13B shows an example of a GUI used by the second entity when accepting / denying a requested consent transaction. [Figure 14] This figure shows an example of a sequence of interactions between different components of a system for consent-driven access management in a cloud partition within a cloud environment. [Modes for carrying out the invention]

[0010] Detailed explanation The following description includes numerous specific details for illustrative purposes to ensure a complete understanding. One or more embodiments can be implemented without these specific details. Features described in one embodiment can be combined with features described in a different embodiment. In some examples, well-known structures and devices are described with reference to block diagrams to avoid unnecessarily obscuring this disclosure. 1. Overview 2. Examples of cloud environments 3. Consent-driven access management architecture 4. Controlling access to cloud resources 5. Examples of Embodiments 6. Other developments 1. Overview One or more embodiments use a combination of consent workflows and access policies to manage access to resources in a cloud environment. The consent workflow specifies one or more users whose approval is required to gain access to the resources. The agent requesting access to the resources must also satisfy one or more access policies separate from the consent workflow.

[0011] Specifically, one or more embodiments receive a request from an actor seeking consent to access a resource and identify a corresponding consent workflow. The consent workflow specifies at least one of the names or attributes of a group of one or more users from which to obtain the corresponding approval for the consent request. The system traverses the consent workflow to obtain the corresponding approval from the group of one or more users. One or more embodiments further determine that one or more access policies, separate from the consent workflow, permit the actor to access a target set of resources. Thus, the actor's access to a target set of resources is based on both (a) obtaining the corresponding approval from a group of one or more users and (b) determining that one or more access policies, separate from the consent workflow, permit the actor to access a target set of resources.

[0012] One or more embodiments generate an approval token indicating that appropriate consent has been given for an actor to access a target resource. One or more embodiments grant an approval token in response to obtaining a corresponding approval. Permitting or denying a request to access a set of one or more resources is based at least in part on the presence of the approval token.

[0013] One or more embodiments described herein and / or recited in the claims may not be included in this "Overview" section. 2. Examples of Cloud Environments One or more embodiments provide features associated with a cloud environment that includes a dedicated cloud environment or a private label cloud (PLC) environment. A cloud environment can be utilized, for example, by a cloud infrastructure provider or a reseller's customer or tenant when accessing software products, services, or other cloud offerings.

[0014] Access can be provided to various complementary cloud-based components, such as software applications or services, that enable an organization or enterprise customer to operate its applications and services in a highly available host environment using a cloud computing environment or a cloud infrastructure environment.

[0015] Benefits of an organization migrating its application and service needs to a cloud infrastructure environment include reducing the costs and complexity of designing, building, operating, and maintaining its own on-premises data center, software application framework, or other information technology infrastructure. Cloud Infrastructure Environment FIG. 1 and FIG. 2 illustrate a system that provides a cloud infrastructure environment according to an embodiment.

[0016] According to one embodiment, components and processes shown in Figure 1 and further described herein in relation to various embodiments may be provided as software or program code that can be executed by a computer system or other type of processing device, such as a cloud computing system.

[0017] The illustrated examples are provided for the purpose of illustrating a computing environment that can be used to provide a dedicated or private label cloud environment for use by cloud infrastructure tenants when accessing subscription-based software products, services, or other offerings associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0018] As shown in Figure 1, according to one embodiment, the cloud infrastructure environment 100 can operate on a cloud computing infrastructure 102 comprising hardware (e.g., processors, memory), software resources, and one or more cloud interfaces 104 or other application program interfaces (APIs) that provide access to shared cloud resources via one or more load balancers A106, B108. The cloud interface 102 includes user interfaces and APIs provided by the cloud service provider for interacting with its cloud services. This includes tools and platforms that enable users and administrators to manage, configure, and monitor cloud resources and services. The cloud interface 102 may include a console, such as a web-based user interface that provides a visual way to interact with and manage cloud resources. Through the console, users can create, configure, and monitor cloud services such as compute instances, databases, storage, and network components. The cloud interface 102 may also include a command-line interface for users who prefer to work with the cloud infrastructure using command-line tools. In one embodiment, the CLI enables the scripting and automation of cloud management tasks.

[0019] In one embodiment, load balancers A106 and B108 are services that distribute incoming network traffic across multiple servers, instances, or other resources to ensure that no single resource bears an excessive burden of requests. By evenly distributing requests across multiple resources, load balancers improve the responsiveness and availability of resources such as applications, websites, or databases. Load balancers A106 and B108 can be either public load balancers accessible from the internet and used for distributing external traffic, or private load balancers used within a virtual cloud network (VCN) and not accessible from the public internet (and therefore ideal for distributing internal traffic). In one embodiment, load balancers A106 and B108 are designed to provide high availability and fault tolerance and are implemented in a redundant configuration spanning multiple availability domains or fault domains.

[0020] According to one embodiment, the cloud infrastructure environment supports the use of availability domains, for example, availability domain A180 and availability domain B182, which enable customers to create and access cloud networks 184, 186 and run cloud instances A192, B194. In one embodiment, availability domains A180 and B182 may represent data centers, or sets of data centers, located within a region. These availability domains may be isolated from each other, meaning they may not share the same physical infrastructure, such as power or cooling systems. This design provides high fault independence and robustness. In one embodiment, fault domains can provide additional protection and resilience within a single availability domain by grouping hardware and infrastructure within availability domains that are isolated from other fault domains. This isolation may relate to electricity, cooling, and other potential sources of failure.

[0021] In one embodiment, tenancies (containers for resources used by tenants) can be created for each cloud tenant / customer, for example, for tenants A142, B144, providing an isolated and secure partition within the cloud infrastructure environment where customers can create, organize, and manage their cloud resources. Cloud tenants / customers can access availability domains and cloud networks to access each of their cloud instances. Tenancies are isolated from other tenancies, ensuring that each customer's data and resources are secure and inaccessible to others. Within a tenancy, customers can create, manage, and organize a wide range of cloud resources, including compute instances, storage volumes, and networks. Identity and Access Management (IAM) services enable the management of users, groups, and policies within a tenancy. Through IAM, customers can control who has access to their resources and what actions they can perform. Tenancies are also the level where billing and subscription management are handled. Usage and costs associated with resources within a tenancy are tracked and billed collectively under that tenancy. Each tenancy may have associated service restrictions and allocations for various resources. These restrictions can be used to help manage capacity and facilitate the distribution of resources across tenants.

[0022] According to one embodiment, a computing device, for example, a client device 120 having device hardware 122 (e.g., a processor, memory) and a graphical user interface 126, may enable an administrator or other user to communicate with a cloud infrastructure environment via a network such as a wide area network, a local area network, or the internet in order to create or update cloud services.

[0023] According to one embodiment, the cloud infrastructure environment provides access to shared cloud resources 140, for example, via a compute resource layer 150, a network resource layer 160, and / or a storage resource layer 170. Customers can launch cloud instances as needed to meet their compute and application requirements. Once a customer provisions and launches a cloud instance, client devices, such as a client device 120, can access the provisioned cloud instance.

[0024] In one embodiment, compute resource 150 may comprise resources such as a bare metal cloud instance 152, a virtual machine 154, a graphics processing unit (GPU) compute cloud instance 156, and / or a container 158. A bare metal instance represents a physical server with dedicated hardware, all allocated to a single tenant. Bare metal instances provide direct access to the server's processor, memory, storage, and other hardware resources. A virtual machine (VM) is a software emulation of a physical computer that runs operating systems and applications like a physical computer. VMs allow multiple operating systems to run on a single physical machine or across multiple machines. A hypervisor layer exists between the hardware and the virtual machines, allocating physical resources (such as CPU, memory, and storage) to each VM. In one embodiment, a GPU compute cloud instance provides a GPU along with conventional CPU resources. These instances are designed for tasks requiring high parallel processing capabilities, making them ideal for applications such as machine learning, scientific computing, 3D rendering, and video processing. In one embodiment, container 158 uses a virtualization method that virtualizes the operating system to enable the execution of multiple isolated applications on a single control host. Each container shares the kernel of the host system but runs in an isolated user space, making the container lightweight and efficient.

[0025] The compute resource 150 components can be used to provision and manage bare-metal compute cloud instances or to provision cloud instances as needed to deploy and run applications, similar to an on-premises data center. For example, according to one embodiment, the cloud infrastructure environment can provide control of physical host (bare-metal) machines within the compute resource tier that run directly as compute cloud instances on bare-metal servers without the use of a hypervisor.

[0026] According to one embodiment, the cloud infrastructure environment can also provide control over virtual machines within the compute resource tier, which can be launched from, for example, an image, in which case the type and amount of resources available to the virtual machine cloud instance can be determined, for example, based on the image from which the virtual machine was launched.

[0027] In one embodiment, the network resource layer may comprise several network-related resources, such as a virtual cloud network (VCN) 162, a load balancer 164, edge services 166, and / or connectivity services 168. In one embodiment, the virtual cloud network (VCN) is a customizable private network in a cloud environment. The VCN provides a virtual version of a traditional network, including subnets, route tables, and gateways. This allows users to set up a cloud-based network architecture according to their requirements. In one embodiment, the edge services 166 include services and technologies designed to place compute, data storage, and network functions closer to where they are needed. The edge services 166 may be used to provide traffic optimization, reduced latency, or other benefits.

[0028] According to one embodiment, the storage resource layer may comprise several resources, for example, a data / block volume 172, file storage 174, object storage 176, and / or local storage 178. The data / block volume 172 provides unformatted block-level storage that can be used to create a file system that hosts a database or for other purposes that require unformatted storage. In one embodiment, the file storage 174 provides a file system and can provide a shared file system that can be accessed simultaneously by multiple instances using a standard file storage protocol. The object storage 176 manages data as objects in a storage bucket. An object has certain attributes, which may include data, metadata, and a unique identifier. The local storage 178 refers to a storage device physically attached to the host computer.

[0029] As shown in Figure 2, according to one embodiment, the cloud infrastructure environment may include various complementary cloud-based components, such as cloud infrastructure applications and services, which enable an organization or enterprise customer to operate its applications and services in a highly available hosted environment.

[0030] According to one embodiment, a self-contained cloud region can be provided as a complete, dedicated region within an organization's data center, for example, on Oracle Cloud Infrastructure (OCI), which gives the data center operator the agility, scalability, and economics of, for example, the OCI public cloud, while maintaining complete control over its data and applications to meet security, regulatory, or data residency requirements.

[0031] For example, according to one embodiment, such an environment may include racks physically and logically managed by a cloud infrastructure provider (e.g., Oracle), customer racks, access for cloud operators for setup and hardware support, power and cooling for the customer's data center, customer floor space, areas for customer data center personnel, and physical access cages.

[0032] In one embodiment, a dedicated region provides tenants / customers with the same set of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) products or services, such as ERP, Financials, HCM, and SCM, that are available within the public cloud region of a cloud infrastructure provider (e.g., Oracle). Customers can seamlessly lift and shift legacy workloads using the cloud infrastructure provider's services (e.g., bare metal compute, VMs, and GPUs), database services (e.g., Oracle Autonomous Database), or container-based services (e.g., Oracle Container Engine for Kubernetes).

[0033] According to one embodiment, a cloud infrastructure environment may operate according to an Infrastructure as a Service (IaaS) model, which enables the environment to provide virtualized computing resources over a public network (e.g., the Internet).

[0034] In the IaaS model, a cloud infrastructure provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer)). Additionally, the cloud infrastructure provider may offer various services associated with these infrastructure components, such as billing software, monitoring software, logging software, load balancing software, or clustering software. In this case, these services may be policy-driven, allowing IaaS users to implement policies that promote load balancing to maintain application availability and performance.

[0035] In one embodiment, an IaaS customer may access resources and services over a wide area network (WAN), such as the internet, and use the cloud infrastructure provider's services to install the rest of their application stack. For example, a user can log into an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and install enterprise software on those VMs. The customer can then use the provider's services to perform a variety of functions, including distributing network traffic, troubleshooting application issues, monitoring performance, or managing disaster recovery.

[0036] In one embodiment, the cloud infrastructure provider may be a third-party service specializing in providing IaaS (e.g., granting, renting, or selling), although this is not required. Alternatively, an entity may choose to deploy a private cloud and become its own provider of infrastructure services.

[0037] In one embodiment, IaaS deployment is the process of deploying a new application, or a new version of an application, onto a prepared application server. This may also include the process of preparing the server (e.g., installing libraries or daemons). This is often managed by the cloud infrastructure provider at a lower level than the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). In this case, the customer may be responsible for handling the deployment of the (OS), middleware, and / or application (e.g., on self-service virtual machines that can be spun up on demand).

[0038] In one embodiment, IaaS provisioning may refer to acquiring the computers or virtual hosts to be used and installing the necessary libraries or services on them. In most cases, provisioning is not included in the deployment, and provisioning may need to be performed first.

[0039] In one embodiment, the challenges of IaaS provisioning include the initial challenge of provisioning an initial set of infrastructure when nothing is operational. Secondly, after all provisioning is complete, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, or removing services). In some cases, these two challenges can be addressed by allowing the infrastructure configuration to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. In this case, the overall topology of the infrastructure (e.g., which resources depend on other resources and how they work together) can be described declaratively. In some cases, once the topology is defined, a consensus workflow can be generated to create and / or manage the various components described in the configuration files.

[0040] In one embodiment, cloud infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as core networks (e.g., pools of configurable and / or shared computing resources, which may be on-demand). In some examples, there may also be one or more inbound / outbound traffic group rules provisioned to define how inbound / outbound network traffic for one or more virtual machines (VMs) will be set up. Other infrastructure elements, such as load balancers and databases, may also be provisioned. The infrastructure can evolve incrementally as more infrastructure elements are requested and / or added.

[0041] In one embodiment, continuous deployment techniques may be employed to enable the deployment of infrastructure code across various virtual computing environments. In addition, the techniques described may enable infrastructure management within these environments. In some examples, a service team may write code that is to be deployed to one or more, but often many, different production environments (e.g., across various geographical locations). However, in some examples, the infrastructure to which the code will be deployed needs to be provisioned. In some cases, provisioning can be done manually, using provisioning tools to provision resources and / or, once the infrastructure is provisioned, using deployment tools to deploy the code.

[0042] Figure 3 shows an example of a cloud infrastructure architecture according to an embodiment. As shown in Figure 3, according to one embodiment, the service operator 202 may be communicably coupled to a secure host tenancy 204 which may include a virtual cloud network (VCN) 206 and a secure host subnet 208.

[0043] In some cases, a service operator may use one or more client computing devices, which may be portable handheld devices (e.g., telephones, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., head-mounted displays) that run software such as Microsoft Windows® and / or various mobile operating systems such as iOS® and Android®, and support the Internet, email, short message service (SMS), or other communication protocols. Alternatively, a client computing device may be a general-purpose personal computer, including personal computers and / or laptop computers that run various versions of operating systems such as Microsoft Windows®, Apple Macintosh®, and / or Linux®. A client computing device may be a workstation computer that runs one of various commercially available UNIX® or UNIX-like operating systems, including but not limited to various GNU / Linux operating systems such as Chrome OS®. In addition, or alternatively, the client computing device may be any other electronic device that can communicate via a network accessible via a VCN and / or the Internet, such as a thin client computer, an internet-enabled gaming system (e.g., a Microsoft Xbox® game console), and / or a personal messaging device.

[0044] According to one embodiment, the VCN may include a local peering gateway (LPG) 210 that can communicately connect to a Secure Shell (SSH) VCN 212 via an LPG included in the SSH VCN. The SSH VCN may include an SSH subnet 214, and the SSH VCN may communicately connect to a control plane VCN 216 via an LPG included in the control plane VCN. The SSH VCN may also communicately connect to a data plane VCN 218 via an LPG. The control plane VCN and data plane VCN may be included in a service tenancy 219 which may be owned and / or operated by a cloud infrastructure provider.

[0045] According to one embodiment, the control plane VCN may include a control plane buffer zone (DMZ) layer 220 that functions as a perimeter network (e.g., part of the corporate network between the corporate intranet and the external network). DMZ-based servers may have limited liability, which helps to mitigate potential breaches. In addition, the DMZ layer may include one or more load balancer (LB) subnets 222, a control plane application layer 224 which may include an application subnet 226, and a control plane data layer 228 which may include a database (DB) subnet 230 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnets included in the control plane DMZ layer may be communicatively coupled to the application subnets included in the control plane application layer and to an internet gateway 234 which may be included in the control plane VCN. The application subnets may be communicatively coupled to the DB subnets included in the control plane data layer, a service gateway 236, and a network address translation (NAT) gateway 238. The control plane VCN may include the service gateway and the NAT gateway.

[0046] According to one embodiment, the control plane VCN may include a data plane mirror application layer 240 which may include application subnets. The application subnets included in the data plane mirror application layer may include virtual network interface controllers (VNICs) on which compute instances can run. The compute instances can communicately connect the application subnets of the data plane mirror application layer to the application subnets that may be included in the data plane application layer.

[0047] According to one embodiment, a data plane VCN may include a data plane application layer, a data plane DMZ layer, and a data plane data layer. The data plane DMZ layer may include an LB subnet that can be communicatively coupled to the application subnet of the data plane application layer and the internet gateway of the data plane VCN. The application subnet may be communicatively coupled to the service gateway of the data plane VCN and the NAT gateway of the data plane VCN. The data plane data layer may also include a DB subnet that can be communicatively coupled to the application subnet of the data plane application layer.

[0048] According to one embodiment, the internet gateways of the control plane VCN and the data plane VCN may be communicatively coupled to a metadata management service 252 that is communicatively coupled to the public internet 254. The public internet may be communicatively coupled to the NAT gateways of the control plane VCN and the data plane VCN. The service gateways of the control plane VCN and the data plane VCN may be communicatively coupled to a cloud service 256.

[0049] According to one embodiment, a service gateway of a control plane VCN or a data plane VCN can make application programming interface (API) calls to a cloud service without traversing the public internet. API calls from the service gateway to the cloud service can be one-way; that is, the service gateway can make API calls to the cloud service, and the cloud service can send the requested data to the service gateway. Generally, the cloud service cannot initiate API calls to the service gateway.

[0050] In one embodiment, a secure host tenancy can be directly connected to a service tenancy, otherwise the service tenancy may be isolated. A secure host subnet can communicate with an SSH subnet via LPG, which may enable bidirectional communication on systems that are normally isolated. By connecting a secure host subnet to an SSH subnet, the secure host subnet may be able to access other entities within the service tenancy.

[0051] According to one embodiment, the control plane VCN may allow users of a service tenancy to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN can then be deployed or otherwise used in the data plane VCN. In some examples, the control plane VCN can be isolated from the data plane VCN, and the data plane mirror application layer of the control plane VCN can communicate with the data plane application layer of the data plane VCN via VNICs that may be included in the data plane mirror application layer and the data plane application layer.

[0052] According to one embodiment, a user or customer of the system can make requests via the public internet, for example, create, read, update, or delete (CRUD) operations, which can be transmitted to a metadata management service. The metadata management service can transmit requests to the control plane VCN through an internet gateway. Requests may be received by an LB subnet included in the control plane DMZ layer. The LB subnet can determine that the request is valid, and in response to this determination, the LB subnet can send the request to an application subnet included in the control plane application layer. If the request is verified to be valid and requires a call to the public internet, the LB subnet can send a call to the internet to a NAT gateway that can make a call to the internet. The metadata to be stored by the request may be stored in a DB subnet.

[0053] According to one embodiment, the data plane mirror application layer can facilitate direct communication between the control plane VCN and the data plane VCN. For example, it may be desirable to apply configuration changes, updates, or other appropriate modifications to resources contained in the data plane VCN. The VNIC allows the control plane VCN to communicate directly with the resources contained in the data plane VCN, thereby enabling it to perform configuration changes, updates, or other appropriate modifications to those resources.

[0054] According to one embodiment, a control plane VCN and a data plane VCN can be included in the service tenancy. In this case, the system user or customer may not own or operate either the control plane VCN or the data plane VCN. Instead, the cloud infrastructure provider may own or operate the control plane VCN and the data plane VCN, and both can be included in the service tenancy. This embodiment can enable network isolation, which can prevent a user or customer from interacting with resources of other users or other customers. This embodiment can also enable a system user or customer to store databases privately without having to rely on the public internet for storage, which may not provide the desired level of threat prevention.

[0055] According to one embodiment, the LB subnet included in the control plane VCN may be configured to receive signals from the service gateway. In this embodiment, the control plane VCN and the data plane VCN may be configured to be invoked by the cloud infrastructure provider's customers without calling the public internet. A customer of the cloud infrastructure provider may desire this embodiment because the database used by the customer can be controlled by the cloud infrastructure provider and stored in a service tenancy that can be isolated from the public internet.

[0056] Figure 4 shows another example of a cloud infrastructure architecture according to one embodiment. As shown in Figure 4, according to one embodiment, the data plane VCN may be included in the customer tenancy 221. In this case, the cloud infrastructure provider may provide a control plane VCN for each customer, and the cloud infrastructure provider can set up a unique compute instance included in the service tenancy for each customer. Each compute instance may enable communication between the control plane VCN included in the service tenancy and the data plane VCN included in the customer tenancy. The compute instance may enable resources provisioned in the control plane VCN included in the service tenancy to be deployed or otherwise used in the data plane VCN included in the customer tenancy.

[0057] In one embodiment, a customer of a cloud infrastructure provider may have a database managed and operated within the customer tenancy. In this example, the control plane VCN may include a data plane mirror app tier that may contain app subnets. The data plane mirror app tier may reside in the data plane VCN, but may not be provided to the data plane VCN. That is, the data plane mirror app tier may be accessible to the customer tenancy, but may not reside in the data plane VCN, or may not be owned or operated by the customer. The data plane mirror app tier may be configured to make calls to the data plane VCN, but may not be configured to make calls to any entity included in the control plane VCN. The customer may want to deploy or otherwise use resources provisioned in the control plane VCN in the data plane VCN, and the data plane mirror app tier can facilitate the deployment or other use of the resources desired by the customer.

[0058] In one embodiment, a customer of a cloud infrastructure provider can apply filters to a data plane VCN. In this embodiment, the customer can determine what the data plane VCN can access and can restrict the data plane VCN's access to the public internet. It may not be possible for the cloud infrastructure provider to apply filters or otherwise control the data plane VCN's access to any external network or database. Applying customer filters and controls to data plane VCNs included in a customer tenancy can help isolate the data plane VCN from other customers and from the public internet.

[0059] According to one embodiment, a service gateway can invoke cloud services to access services that may not reside on the public internet, on a control plane VCN, or on a data plane VCN. The connection between the cloud services and the control plane VCN or data plane VCN may not be continuous. The cloud services may reside on different networks owned or operated by the cloud infrastructure provider. The cloud services may be configured to receive calls from the service gateway and not to receive calls from the public internet. Some cloud services may be isolated from other cloud services, and a control plane VCN may be isolated from cloud services that may not be in the same region as the control plane VCN.

[0060] For example, according to one embodiment, the control plane VCN may be located in "Region 1," and the cloud service "Deployment 1" may be located in both Region 1 and "Region 2." If a call to Deployment 1 is made by a service gateway included in the control plane VCN located in Region 1, the call may be sent to Deployment 1 in Region 1. In this example, the control plane VCN, or Deployment 1 in Region 1, may not be communicatively coupled to Deployment 1 in Region 2, or may not otherwise communicate with Deployment 1.

[0061] Figure 5 shows another example of a cloud infrastructure architecture according to one embodiment. As shown in Figure 5, according to one embodiment, a trusted application subnet 260 may be communicatively coupled to a service gateway included in the data plane VCN, a NAT gateway included in the data plane VCN, and a DB subnet included in the data plane data layer. An untrusted application subnet 264 may be communicatively coupled to a service gateway included in the data plane VCN and a DB subnet included in the data plane data layer. The data plane data layer may include a DB subnet that can be communicatively coupled to a service gateway included in the data plane VCN.

[0062] According to one embodiment, an untrusted application subnet may include one or more primary VNICs (1) to (N) that can be communicatively coupled to tenant virtual machines (VMs). Each tenant VM may be communicatively coupled to a corresponding application subnet 267(1) to (N) that may be included in a corresponding container output VCN 268(1) to (N) that may be included in a corresponding customer tenancy 270(1) to (N). A corresponding secondary VNIC may facilitate communication between the untrusted application subnet included in the data plane VCN and the application subnet included in the container output VCN. Each container output VCN may include a NAT gateway that can be communicatively coupled to the public internet.

[0063] According to one embodiment, the public internet can be communicatively coupled to NAT gateways included in the control plane VCN and NAT gateways included in the data plane VCN. Service gateways included in the control plane VCN and service gateways included in the data plane VCN can be communicatively coupled to cloud services.

[0064] In one embodiment, a data plane VCN can be integrated with a customer tenancy. This integration may be useful or desirable for a cloud infrastructure provider's customers in cases where additional support may be required during code execution. For example, a customer may provide code that could be executed, potentially be disruptive, communicate with other customer resources, or otherwise have undesirable consequences.

[0065] According to one embodiment, a customer of a cloud infrastructure provider can grant temporary network access to the cloud infrastructure provider and request functionality to be attached to the data plane application layer. The code for performing the functionality may run in a VM, and this code does not have to be configured to run elsewhere on the data plane VCN. Each VM may be connected to one customer tenancy. Corresponding containers (1) to (N) contained within the VM may be configured to run the code. In this case, a double isolation may exist (for example, the containers run the code, but these containers may be contained in a VM that is at least in an untrusted application subnet), which can help prevent improper or otherwise undesirable code from damaging the cloud infrastructure provider's network or the network of a different customer. The containers may be communicatively coupled to a customer tenancy and may be configured to send or receive data to or from the customer tenancy. The containers do not have to be configured to send or receive data to or from any other entity in the data plane VCN. Once the execution of the code is complete, the cloud infrastructure provider may decommission the containers.

[0066] According to some embodiments, a trusted application subnet can execute code that may be owned or operated by the cloud infrastructure provider. In this embodiment, the trusted application subnet may be communicatively joined to a DB subnet and configured to perform CRUD operations in the DB subnet. An untrusted application subnet may be communicatively joined to a DB subnet and configured to perform read operations in the DB subnet. Containers that can be included in each customer's VM and execute code from the customer do not need to be communicatively joined to the DB subnet.

[0067] In one embodiment, the control plane VCN and the data plane VCN do not have to be directly coupled in a communicative manner, or there may be no direct communication between the control plane VCN and the data plane VCN. However, communication may occur indirectly, in which case the cloud infrastructure provider may establish an LPG that facilitates communication between the control plane VCN and the data plane VCN. In another example, the control plane VCN or the data plane VCN can make calls to cloud services via a service gateway. For example, a call from the control plane VCN to a cloud service may include a request for a service that can communicate with the data plane VCN.

[0068] Figure 6 shows another example of a cloud infrastructure architecture according to one embodiment. As shown in Figure 6, according to one embodiment, a trusted application subnet can be communicatively coupled to a service gateway included in the data plane VCN, a NAT gateway included in the data plane VCN, and a DB subnet included in the data plane data layer. An untrusted application subnet can be communicatively coupled to a service gateway included in the data plane VCN and a DB subnet included in the data plane data layer. The data plane data layer may include a DB subnet that can be communicatively coupled to a service gateway included in the data plane VCN.

[0069] According to one embodiment, an untrusted application subnet may include a primary VNIC that can be communicatively coupled to tenant virtual machines (VMs) residing within the untrusted application subnet. Each tenant VM can execute code in its corresponding container and may be communicatively coupled to an application subnet that may be included in the dataplane application layer, which may be included in the container output VCN280. Corresponding secondary VNICs 282(1)~(N) may facilitate communication between the untrusted application subnet included in the dataplane VCN and the application subnet included in the container output VCN. The container output VCN may include a NAT gateway that can be communicatively coupled to the public internet.

[0070] According to one embodiment, the Internet gateway included in the control plane VCN and the Internet gateway included in the data plane VCN may be communicatively coupled to a metadata management service that can communicate with the public internet. The public internet may be communicatively coupled to the NAT gateway included in the control plane VCN and the NAT gateway included in the data plane VCN. The service gateway included in the control plane VCN and the service gateway included in the data plane VCN may be communicatively coupled to a cloud service.

[0071] In one embodiment, the pattern shown in Figure 6 can be considered an exception to the pattern shown in Figure 5 and may be desirable for customers when the cloud infrastructure provider cannot communicate directly with the customer (e.g., in a region without connectivity). The corresponding containers contained within each customer's VM are accessible to the customer in real time. The containers may be configured to make calls to the corresponding secondary VNICs contained within the application subnet of the data plane application layer, which may be contained within the container output VCN. The secondary VNICs can then forward the calls to a NAT gateway that can send the calls to the public internet. In this example, the containers accessible to the customer in real time can be isolated from the control plane VCN and also from other entities contained within the data plane VCN. The containers can also be isolated from resources from other customers.

[0072] In another example, a customer can use a container to invoke a cloud service. In this example, the customer may execute code in a container that requests a specific service of the cloud service. The container can send this request to a secondary VNIC, which can then send the request to a NAT gateway, which can then send the request to the public internet. Using the public internet, the request can be sent via an internet gateway to an LB subnet included in the control plane VCN. In response to determining that the request is valid, the LB subnet can send the request to an application subnet that can send requests to the cloud service via a service gateway.

[0073] Please understand that the IaaS architecture depicted in the above diagram may have components other than those depicted. Furthermore, the embodiments shown in the diagram are just a few examples of cloud infrastructure systems that may incorporate embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown in the diagram, may combine two or more components, or may have different configurations or arrangements of components.

[0074] In one embodiment, the IaaS system described herein may include a suite of applications, middleware, and database service offerings, which are delivered to the customer in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. Private label cloud environment According to one embodiment, a cloud infrastructure environment can be used to provide a dedicated cloud environment, for example, as one or more private label cloud environments that tenants of the cloud infrastructure environment use to access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0075] Figure 7 illustrates how, in one embodiment, the system can provide a dedicated or private label cloud environment used by tenants or customers of a cloud infrastructure environment.

[0076] As shown in Figure 7, according to one embodiment, a cloud infrastructure provider (e.g., OCI) can supply one or more private label cloud (PLC) environments to an OCI customer acting as a PLC operator 320, for example, a reseller. The PLC operator / reseller can then customize and extend the private label cloud used by its customer 330 so that it can be used to access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0077] For illustrative purposes, examples of such subscription-based products, services, or other offerings include various Oracle Cloud Infrastructure software products, Oracle Fusion Applications products, or other types of products or services that allow customers to register for use of such products or services.

[0078] Figure 8 further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment.

[0079] As shown in Figure 8, according to one embodiment, the system may include a cloud subscription service or component, such as an Oracle Cloud Subscriptions (OCS) service or component, which exposes one or more subscription management APIs for onboarding new customers or for creating orders used to create subscriptions and orchestrate billing and pricing services or other components used in PLC Realm 400.

[0080] According to one embodiment, when a PLC operator or its customer requests a PLC environment, the system creates a PLC realm used by one or more provider-owned tenancies. A realm is a logical collection of one or more cloud regions isolated from each other, and does not allow customer content to move across realm boundaries to regions outside of that realm. Each realm is accessed separately. PLC operators access cloud resources and services through cloud tenancies. A cloud tenancy is an isolated, secure partition of the cloud infrastructure environment and exists only within a single realm. Within this tenancy, operators can access services and deploy workloads across all regions within that realm, if policies permit it.

[0081] According to one embodiment, the first step in the process is to create an operator tenancy for the PLC operator before the realm and associated regions are handed over to the PLC operator for subsequent management. The PLC operator then becomes the administrator of this tenancy and can view and manage everything that happens within that realm, including their customer accounts and the use of cloud resources by those customers.

[0082] Generally, once the realm has been handed over or provided to the PLC operator, the cloud infrastructure provider will no longer be able to access the data within the operator's tenancy, unless the operator grants the cloud infrastructure provider permission to do so, for example, to provide troubleshooting for any problems that may arise.

[0083] According to one embodiment, the PLC operator can then create additional internal tenancies intended for its own internal use, for example, to determine what the end customer experience will be, to provide sales demo tenancies, or to operate databases for its own internal use. The operator can also create one or more customer tenancies where the end customer is the administrator. Cloud infrastructure usage metrics, such as compute usage, storage usage, and usage of other infrastructure resources, can be integrated by the operator to reflect both operator usage and customer usage. Cloud infrastructure usage may be reported to the cloud infrastructure provider.

[0084] According to one embodiment, a user interface or console may be provided that allows the PLC operator to manage customer accounts and customer-provided services. The cloud infrastructure provider may also install any necessary infrastructure services used by the operator and its customers using a cloud infrastructure tenancy, such as Fusion Applications tenancy.

[0085] Figure 9 further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment.

[0086] As shown in Figure 9, according to one embodiment, a cloud subscription service or component exposes one or more subscription management APIs for creating orders used to onboard new customers or to trigger workflows that create subscriptions and orchestrate billing and pricing services or other components.

[0087] According to one embodiment, the system may also include a billing service or component that operates on a billing account or a logical container of subscriptions and preferences used to generate invoices for customers.

[0088] In one embodiment, the system may also include a subscription pricing service (SPS) or component that operates on a product catalog defining products available for purchase by the customer. The subscription pricing service may also be used to provide a price list (e.g., rate cards) which is also owned by the pricing service.

[0089] In one embodiment, products can be selected from a product hub to support the sales process used to create subscriptions in the PLC realm. Once an order is created, a subscription is created in the cloud subscription service, which then manages the lifecycle of that subscription and provisions what needs to be provisioned to downstream services. The SPS component then manages the pricing and usage aspects used to bill the PLC operator for the final cost, or the aspect of the PLC operator's ability to bill their own customers. Usage events are forwarded to the billing service or component, where an invoice is created according to the subscription's billing preference and pushed to the accounts receivable component.

[0090] In one embodiment, a service provided in a realm reports its usage to a metering service or component, but no price is associated with such usage. The rating process determines how much each particular event costs, for example by applying a rate card, determines the unit quantity and cost for that subscription, associates the cost with the record, and then transfers it to a billing service or component.

[0091] As further shown in Figure 9, according to one embodiment, a PLC operator can control multiple realms A, B, etc. For example, an operator operating in multiple countries may want to operate, for example, a data center completely isolated for the United States and a separate data center completely isolated for Europe, in order to address governance or regulatory requirements. According to one embodiment, the usage associated with these multiple realms can be aggregated for use in billing the operator.

[0092] The various system examples presented above are provided for the purpose of illustrating computing environments that can be used to provide a dedicated or private label cloud environment for use when cloud infrastructure tenants access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments. Private Label Cloud Subscription Figure 10 shows a system, according to one embodiment, for providing access to software products or services in a cloud computing environment or other computing environment.

[0093] As shown in Figure 10, according to one embodiment, the system may be provided as a cloud computing environment or other computing environment, referred to herein as a platform in some embodiments, which supports the use of subscription-based products, services, or other offerings.

[0094] Examples of such subscription-based products, services, or other offerings include various Oracle Cloud Infrastructure (OCI) software products, Oracle Fusion Applications products, or other types of products or services that allow customers to register for use of such products or services.

[0095] According to one embodiment, a subscription may include artifacts such as products, commits, billing models, and state. A cloud subscription service may expose one or more subscription management APIs for creating orders used to onboard new customers or to launch workflows that orchestrate the creation of subscriptions and the appropriate footprint in billing and pricing services or components, as further described below.

[0096] According to one embodiment, a billing service or component operates on a billing account used to generate invoices, or on a logical container of subscriptions and preferences. Each billing account generates one or more invoices per billing cycle. The billing service includes a first pipeline that receives usage and costs from a metering service or component. Usage may be received through a REST API or another interface. The billing service writes usage to a database, from which deductions can be calculated and aggregated by the billing service or other services. The billing service may also include a second pipeline that takes aggregated usage and commitments and is responsible for calculating charges for one or more billing periods.

[0097] In one embodiment, a subscription pricing service (SPS) or component operates on a product catalog that defines the products available to the customer for purchase. The product catalog forms the framework of a price list (i.e., rate cards) also owned by the pricing service. Rate cards are modeled as pricing rules that are higher than public list prices. The pricing service maintains a single price list for each product. It is possible to add new product prices and modify existing ones. The price list has a complete history, and the most recent version is the current rate card. Since some contracts require taking a snapshot of the rate cards, the pricing service handles this by recording the time the customer's rate card was created and then querying the price list at that time.

[0098] In one embodiment, the SPS or pricing service is responsible for providing information about products, global price lists, and subscription-specific price lists and discounts for end customers. For example, in one embodiment, the SPS can synchronize product information from a product hub (e.g., Oracle Fusion Product Hub) with a global price list from a pricing hub (e.g., Oracle Fusion Pricing Hub).

[0099] In one embodiment, the cloud subscription service acts as an upstream service for receiving requests for new orders from, for example, an Oracle Fusion Order Management environment. The cloud subscription service can provide subscription information to the SPS service. Subscription details such as the estimated timing, configuration, and subscription type (commitment, PayG) help the SPS determine the effective base price (rate card) for that subscription. The cloud subscription service can also send discounts for subscriptions received from, for example, Oracle Fusion Order Management, which the SPS stores as an entity in its pricing rules.

[0100] In one embodiment, the SPS service runs as a background process and manages a rate card service or component responsible for generating rate cards for new subscriptions and updating them when new price changes occur. The SPS service can expose APIs for accessing rate cards and pricing rules. A metering inline rating engine can use these APIs to retrieve subscription-specific rate cards and pricing rules that use this data for cost calculations.

[0101] In one embodiment, additional SPS components could include, for example, an integration component for the Oracle Integration Cloud (OIC) Pricing / Product Hub, which would allow PLC operator entities providing subscription-based products, services, or other offerings within the environment to manage their own product and pricing lists, such as those provided by Oracle Fusion Product Hub and Oracle Fusion Pricing Hub, respectively.

[0102] For example, according to such an embodiment, the SPS OIC product integration flow can listen for create / update events within the product hub and make calls to the SPS product API. Similarly, the SPS OIC pricing integration flow can retrieve new price list creations from the pricing hub and call the corresponding SPS pricing API.

[0103] In one embodiment, the system may also include an SPS core module that manages and provides an API for accessing pricing entities. Pricing can be accessed from internal services such as an inline rating engine.

[0104] In one embodiment, the system may also include a rate card manager component. The SPS service maintains a single base price for a product at a given point in time. However, the product price for a subscription depends on the base price at the time of quotation and the attributes of the subscription's price list change policy. The SPS service uses these properties to internally maintain the prices used for subscriptions. Such price lists are compiled into rate cards. The rate card manager is capable of creating and maintaining rate cards, as well as listening for price list changes and updating existing rate cards with the new prices. The rate card manager also listens for new subscriptions and assigns rate cards based on the subscription's properties.

[0105] In one embodiment, the system may also include a rule decoder engine. The SPS service is responsible for managing subscription pricing rules, including discounts presented to end customers. Eligibility for pricing rules can be based on product attributes, such as discount groups, product categories, or specific SKUs. Internally, the SPS needs to identify a list of products to which these rules apply. To achieve this, the rule decoder engine can compile pricing rules in a format that an inline rating engine can consume for cost calculation. This compilation process may be triggered when a product or pricing rule is created / updated.

[0106] As illustrated in Figure 10, according to one embodiment, in 441, product and pricing information, managed, for example in Fusion Applications, is sent to the SPS component. In 442, an order is sent to the Cloud Subscription Service component, and a subscription, rate card, and billing account are created. In 443, pricing configurations and pricing rules are sent to the SPS for the new order. In 444, a billing account is set up in the billing service or component using the Cloud Subscription Service. In 445, the Cloud Subscription Service publishes events to the Cloud Infrastructure Streaming component. In 446, billing data is sent to the Accounts Receivable component, and an invoice is generated. In 447, the Cloud Subscription Service consumes reclaim and subscription lifecycle (RASL) events from Cloud Infrastructure Streaming. In 448, the Activation Service reads the event stream from the Cloud Subscription Service. In 449, the customer retrieves activation data from the portal. In step 450, the tenancy lifecycle service provisions the tenancy as part of the subscription activation. In step 451, the tenancy lifecycle service creates the account footprint during account provisioning. In step 452, the tenancy lifecycle service configures the limit template during account provisioning. In step 453, the account component acts as a downstream RASL client to handle legacy reclamation. In step 454, aggregated costs and usage are sent to the billing service or component. In step 455, the organization can use the tenancy lifecycle service to create child tenancies. In step 456, the metering service or component retrieves the subscription mapping data.In 457, the subscription service retrieves organizational data for subscription mapping. In 458, RASL reads the event stream of the cloud subscription service. In 459, the subscription service reads the event stream of the cloud subscription service, and in 460, the metering service or component retrieves rate card data for each subscription and can then use it when billing the PLC operator for final costs, or in the function of the PLC operator billing its customers.

[0107] The above examples are provided for the purpose of illustrating a computing environment that can be used to provide a dedicated or private label cloud environment for use when a cloud infrastructure tenant accesses subscription-based software products, services, or other offerings associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments. 2. Consent-driven access management architecture As noted above, one or more embodiments use a combination of consent workflows and access policies to manage access to resources in a cloud environment. The workflow specifies one or more users whose approval is required to obtain access to the resources. The agent requesting access to the resources must also satisfy one or more access policies separate from the consent workflow.

[0108] Generally, a consent workflow determines whether consent should be granted to an actor to access a target set of resources. To support the consent workflow, one or more embodiments include a consent service configured to communicate with an identity service. In one embodiment, the actor is a CSP operator, i.e., a user acting on behalf of the CSP to perform one or more administrative actions. The user whose consent is required may be an operator associated with the CSP's customers or tenants. For this reason, the consent workflow gives the CSP customer some control over the CSP operator's access to resources within the CSP customer's cloud partition. For ease of explanation, the term “actor-operator” is used herein to refer to both the actor seeking consent and the operator submitting the consent request on behalf of the actor (i.e., the requester). The actor and the requester may be the same user, or they may be different users. The term “tenant-operator” is used herein to refer to one or more users acting on behalf of the CSP's customers or tenants. For example, a tenant-operator may include one or more users who are responsible for selecting and / or configuring consent workflows applicable to a set of resources, and / or granting consent in response to consent requests.

[0109] In one embodiment, the target set of resources includes one or more resources within a specific cloud partition. “Resource” in the following description refers to a service or application, or even data, within a specific cloud partition. For ease of explanation, a cloud partition will be referred to as a realm in the following description. Alternatively, or in addition, a cloud partition may be a region, tenancy, or other logical sub-partition of a cloud environment.

[0110] One or more embodiments support the consent workflow with additional control and data layer components. For an actor-operator to perform an action in a given realm, the tenant-operator must authorize it, and the CSP actor-operator must obtain prerequisite consent. Actions requiring consent may include, for example, reading service logs, reading metric information, continuously monitoring the health of the PLC realm, and connecting to a product host. The tenant-operator defines instructions for handling incoming requests, for example, enabling certain actions only when approved by a designated authorizer.

[0111] Figure 11 shows a cloud system 1100 (hereinafter also simply referred to as the "System") according to one or more embodiments. As shown in Figure 11, System 1100 includes realms 1102 and 1104. Realm 1102 includes a CSP interface 1122, a control plane 1106A, a data plane 1106B, an access manager 1126, a consent service 1150, an identity service 1128, and a data repository configured to store one or more consent tokens 1124. Realm 110 includes a tenant interface 1112, a control plane 1108A, a data plane 1108B, an access manager 1110, a consent service 1114, an identity service 1116, and a data repository configured to store one or more consent workflows 1118 and access policy data 1120. Each of these components will be described in further detail herein.

[0112] In some embodiments, system 1100 may include more or fewer components than those shown in Figure 11. The components shown in Figure 11 may be local or remote from one another. The components shown in Figure 11 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into a single application and / or machine. Another component may perform the operation described for one component. Additional embodiments and / or examples related to computer networks are described in the section titled “Computer Networks and Cloud Networks” below.

[0113] System 1100 may include additional realms not shown in Figure 11. Each realm may encompass one or more data centers across geographically distinct regions. Some or all of these geographical regions may form logical groupings or partitions within the cloud environment.

[0114] Realm 1102 and Realm 1104 each represent cloud partitions of the (same) cloud environment hosted by System 1100. As further shown in Figure 11, both Realm 1102 and Realm 1104 contain various components of the consent-driven access management architecture.

[0115] In one or more embodiments, realm 1102 is configured as a cloud partition for a first entity (e.g., a CSP), and realm 1104 is configured as a cloud partition for a second entity (e.g., tenants and customers of the CSP). A third entity (e.g., tenants and customers of the second entity) may be assigned to other realms (not shown) in system 1100. Alternatively or in addition, the second entity may resell access to realm 1104 to the third entity. For example, the second entity may assign one or more tenancies within realm 1104 to their respective third-party customers (i.e., entities that are customers of the CSP's customers but not customers of the CSP itself). In one embodiment, the first entity requests the second entity to use the cloud environment, and the second entity requests the third entity to use the cloud environment.

[0116] In one embodiment, realms 1102 and 1104 run services and / or applications in a software-defined networking (SDN) paradigm. The control plane (e.g., control plane 1106A in realm 1102 or control plane 1108A in realm 1104) and data plane (e.g., data plane 1106B in realm 1102 or data plane 1108B in realm 1104) expose interfaces (e.g., APIs) to these services and / or applications. A service or application running in realm 1102 can use the APIs of control plane 1106A and / or data plane 1106B to access another service or application running in control plane 1108A and / or data plane 1108B in realm 1104, and vice versa. In a cloud partition such as Realm 1102 or Realm 1104, the management entity constitutes a home region with data plane services (e.g., identity data plane services) and control plane services that are global, i.e., available across other regions of the cloud environment. Each of the control plane / data plane pairs for 1106 and 1108 can reside within the home region of their respective realms, where the targeted set of cloud resources also resides. Any changes to the home region of any realm will automatically propagate to all regions.

[0117] In one embodiment, the access manager 1110 is configured to present information in the tenant interface 1112. The access manager 1110 can expose an API through the tenant interface 1112, through which the operator and consent service 1114 can manage consent requests (e.g., allow / deny) that seek consent from an actor to access a target set of cloud resources within the realm 1104. It should be noted that consent only grants the actor access rights, and no specific action is attempted at the time consent is granted. One or more embodiments of the access manager 1110 and / or consent service 1114 call the identity service 1116 to determine whether a particular actor in the realm 1102 is authorized to access a target set of resources.

[0118] The consent service 1114 stores data in the data plane 1108 that identifies which target set of resources corresponds to each consent request and can monitor the consented actions being performed in the realm 1104. One embodiment of an example consent request includes one or more search attributes that are mapped to a target set of resources in the cloud environment. The requester submits the example consent request via the CSP interface 1222. If one or more invalidation conditions are met, the requester is permitted to obtain consent for an agent to access a target set of resources in the cloud environment in a situation where the example consent request would normally be denied. The requester may be referred to as a user principal, such as the user principal 1402 depicted in Figure 14.

[0119] The consent service 1114 may rely on the consent workflow 1118 to determine whether to grant or deny the requested consent to the agent. The consent service 1114 may be configured to execute each of the instructions in the exemplary consent workflow 1118 when it grants / denies the consent request. The exemplary consent workflow 1118 may be configured to allow the agent to access a target set of resources only when approved by a designated authorizer. The exemplary consent workflow 1118 evaluates conditions based on state data at the time of the consent request. In another exemplary consent workflow 1118, consent is pre-approved and no additional approval is required.

[0120] The identity service 1116 can apply access policy data 1120 to the actor's user identity. After verifying the authenticity of the actor's user identity, the identity service 1116 can decide whether to allow the actor to connect to the target set of resources. The identity service 1116 may operate in cooperation with the consent service 1114 under the consent-driven access management architecture of system 1100.

[0121] The actor may be an operator of the CSP, and in some examples may also be a requester for consent to access a target set of resources. One or more operators of the CSP tenant can approve the consent request. Once the consent request is approved, the actor can submit a request to access the target set of resources and perform an action via the CSP interface 1122. In response to obtaining approval for the consent request, the consent service 1114 may return a credential representing consent, which is referred to herein as the consent token 1124. It should be noted that the consent service 1114 is not limited to granting the consent token 1124, and in other embodiments may grant alternative credentials.

[0122] The aforementioned actors in the CSP can initiate a principal session to access a target set of resources and perform actions on that target set. The access manager 1126 can submit a consent token 1124 to the identity service 1128 for activation and / or authentication. Once activated and / or authenticated, the access manager 1126 embeds the consent token 1124 into a session request submission. The session request, when received by the target resources, constitutes and initiates a principal session.

[0123] Similar to realm 1104, realm 1102 may include consent service 1150. Consent service 1150, in a similar manner to consent service 1114, can receive consent requests and proceed to either approve or deny the request for consent. Alternatively or in addition, consent service 1114 and / or consent service 1150 may be configured to support the “breakglass” functionality of consent-driven access management architectures as described in further detail herein.

[0124] The access manager 1110 can perform some of the functionality of the consent service 1114 in the control plane 1108A of the realm 1104 according to an SDN-type architecture. Specifically, the access manager 1110 may include a Representation State Transfer (REST) ​​API endpoint for receiving / sending consent requests and consent request responses between the tenant interface 1112 and the data plane 1108B. The same REST API endpoint may be called to update the consent workflow 1118 with new, expired, or modified consent workflows. The same REST API endpoint may also be called to configure the data plane 1108B with various data, including consent status information. In one embodiment, the consent service 1114 maintains a list of actions in the data plane 1108B that target any operation requiring a connection to the realm 1104 (e.g., a PLC realm). The tenant-operator provides configuration information (e.g., consent status information) via the tenant interface 1112, indicating which actions should be automatically approved / denied, and which actions require further attention (e.g., review and / or approval by one or more human operators). Thus, the consent service 1114 can take on the (one-time) configuration role of the realm 1104 with static consent approval / denial and / or consent workflows.

[0125] Access manager 1110 can store the above configuration as consent status information in data plane 1108B. In response to a service request, consent service 1114 calls data layer functions (e.g., identity data plane API) and returns the corresponding consent status to access manager 1110 and / or access manager 1126. Consent service 1114 can record incoming (and approved) consent requests in the data layer and track changes in consent status information.

[0126] In one embodiment, system 1100 includes a breakglass mechanism for consent service 1150, which allows a user principal to approve a consent request in the event of a power outage, security breach, or other serious problem. In such cases, time is critical. Quick action may be required to successfully resolve the problem without allowing the consent workflow 1118 to run. Identity service 1128 applies consent on behalf of the CSP to authorize actions in realm 1104 by a system engineer or a service / application running within realm 1102. Access manager 1126 further applies consent to approve ongoing actions such as (a) continuous monitoring of realm health, and / or (b) time-limited actions such as an engineer connecting to a product host or reading service logs to troubleshoot an ongoing problem.

[0127] In one or more embodiments, the tenant interface 1112 and the CSP interface 1122 refer to hardware and / or software configured to facilitate communication between the operator and the realms 1102 and 1104, respectively. The tenant interface 1112 and the CSP 1122 render user interface elements and receive input through user interface elements. Examples of interfaces include graphical user interfaces (GUIs), command line interfaces (CLIs), haptic interfaces, and voice command interfaces. Examples of user interface elements include checkboxes, radio buttons, dropdown lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms.

[0128] In one embodiment, different components of the tenant interface 1112 or the CSP interface 1122 are specified in different languages. The behavior of user interface elements is specified in a dynamic programming language such as JavaScript®. The content of user interface elements is specified in a markup language such as Hypertext Markup Language (HTML) or XML User Interface Language (XUL). The layout of user interface elements is specified in a stylesheet language such as Cascading Style Sheets (CSS). Alternatively, the tenant interface 1112 or the CSP interface 1122 is specified in one or more other languages ​​such as Java®, C, or C++.

[0129] In one or more embodiments, a tenant is a group, organization, company, or other entity that accesses a shared computing resource, such as a service or application. In some embodiments, tenants are independent of each other. The businesses or activities of the tenants are separate from each other.

[0130] An example of an embodiment of the CSP interface 1122 is an example of a consent page, such as a new DevOps consent page. An actor-operator can use the CSP interface 1122 to request consent to access a set of resources within the realm 1104. The actor-operator receives a notification when the consent request is approved. In one embodiment, the approved consent token 1124 can be activated within a certain amount of time (e.g., some predefined number of minutes, hours, or days). Alternatively or in addition, the activated consent token 1124 may remain active for a certain amount of time (e.g., some predefined number of minutes, hours, or days) before new consent approval is required.

[0131] In one embodiment, an agent-operator is provided with a consent principal session token, abbreviated as "CPST," by activating an approved consent token 1124. The CPST can be used to make requests to perform specific actions on a resource. For example, if consent has been granted to a logging system, the CPST can be used to request access to perform one or more actions on the logging system, such as searching logs. Alternatively or in addition, system 1100 allows the agent-operator to export the CPST (e.g., to a configuration file or other storage format) for later use elsewhere.

[0132] In one embodiment, the data repository is any type of storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, and / or any other storage mechanism). As shown in Figure 11, the data repository is configured to store consent tokens 1124, access policy data 1120, and consent workflows 1118. The data repository may include multiple different storage units and / or devices. These multiple different storage units and / or devices may or may not be of the same type, or may or may not be located at the same physical site. The data repository may be implemented or run on the same computing system as realm 1102 and / or realm 1104, and / or on a different computing system than realm 1102 and / or realm 1104. The data repository may be communicably coupled to one or more other components via direct connections or via a network. Information describing consent tokens 1124, access policy data 1120, and consent workflows 1118 may be implemented across any of the components of system 1100. However, this information is presented within the data repository for the purpose of clarity and explanation.

[0133] In one or more embodiments, the system 1100 includes hardware and / or software configured to perform the operations described herein for implementing consent-driven access control. An example of the operation of consent-driven access control is described below with reference to Figure 12.

[0134] In one embodiment, System 1100 is implemented on one or more digital devices. The term “digital device” generally refers to any hardware device including a processor. A digital device may refer to a physical device on which an application or virtual machine runs. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, specific-function hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address converters (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile devices, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations, communication management devices, routers, switches, controllers, access points, and / or client devices. 4. Controlling access to cloud resources Figure 12 shows an example of a set of actions for consent-driven access management of cloud resources by one or more embodiments. One or more actions shown in Figure 12 may be modified, rearranged, or omitted entirely. Therefore, the specific sequence of actions shown in Figure 12 should not be interpreted as limiting the scope of one or more embodiments. A system for running at least one cloud environment performs an exemplary set of actions by one or more embodiments.

[0135] In one embodiment, the system receives a consent request (operation 1200) seeking consent from an actor to access a target set of resources. As described herein, the actor is an operator of a first entity (e.g., a CSP) having at least one cloud partition of a cloud environment, and the actor's consent may relate to a specific action to be performed on the target set of resources. The consent request generally includes a request seeking consent from the actor to access a target set of resources (in a second cloud partition). The consent request may specify at least one search attribute that maps to the target set of resources. The target set of resources may belong to one of the second entity, a tenant of the second cloud partition, and a customer of the CSP. The second entity may provide approval of the required consent request by several methods, as described in detail below.

[0136] An agent-operator of the first entity can submit a consent request through a console (e.g., the CSP console), and a tenant-operator of the second entity can view the consent request as an incoming message on their own console (e.g., the tenant console). The console can communicate the consent request by calling a REST API in the first cloud partition and sending the consent request to the tenant console, which is the REST API endpoint in the second cloud partition. The tenant-operator can then use the tenant console to check pending consent requests for any inconsistencies with approved consent requests or violations of the consent workflow.

[0137] One embodiment includes a consent service that, on behalf of a second entity, either approves or denies consent requests from an actor seeking consent to access a target set of resources. Generally, a target set of resources refers to one or more services or applications that have functionality (e.g., service APIs) for performing various actions, such as log lookup services, matrix lookup services, and host connectivity services. The consent service can receive consent requests in a second cloud partition of a cloud environment. The consent service may be further configured to respond to consent requests by granting or denying the requested consent. The consent service may provide the actor with a consent token representing the granting of the requested consent. Otherwise, the actor may not be permitted access to the target set of resources and therefore cannot perform any action on any of the target set of resources. Examples of actions subject to approval and consent include reading service logs, reading metric information, continuously monitoring the health of a realm, and connecting to a product host.

[0138] Alternatively, the second entity may act as a CSP providing cloud services to the third entity, the tenants of the third cloud partition, and the customers of the second entity's CSP. In one embodiment, the second entity submits the same or similar consent request on behalf of one of its actors, or as a substitute, on behalf of an actor of another entity (e.g., the first entity). The third entity controls, at least partially, access to the third cloud partition, but in response to receiving a consent request, may grant the requested consent to an actor of the second entity. The second entity may forward the consent request to the third entity's consent service, which evaluates the consent request and either approves or rejects the actor's request for consent to access a target set of resources. Thus, the actor performing the approved action may belong to the same entity as the requester who is requesting consent for the actor to access a target set of resources, or it may belong to a different entity.

[0139] In one embodiment, the system identifies a consent request and associated consent workflow (operation 1202). In one embodiment, a consent request includes one or more search attributes that map to a target set of resources within the cloud environment (or, more specifically, within a cloud partition of the cloud environment). A tenant-operator can establish a consent workflow to handle incoming consent requests (seeking consent) for an actor to access a target set of resources. Generally, a consent workflow includes instructions indicating from whom consent approval can be obtained and to whom consent can be granted. In one embodiment, the consent workflow specifies at least one of the names or attributes of a set of one or more users from whom the corresponding approval for the consent request will be obtained. In another embodiment, the consent workflow specifies attributes that identify the action to be performed on the target set of resources.

[0140] In one embodiment, the system traverses the consent workflow (operation 1204). Based on the associated consent workflow, the system can either reject or accept a consent request. One or more embodiments of the consent service traverse the consent workflow by performing the associated consent workflow and executing it until its instructions are completed. Certain requirements outlined in the consent workflow must be met before the consent service can grant consent in response to receiving an incoming consent request. Otherwise, granting consent would be contrary to the tenant-operator's given instructions. Consent is therefore based on satisfying the consent workflow.

[0141] In one embodiment, the system obtains approval from one or more operators in a second cloud partition (operation 1206). The consent workflow can define a list of operators from which a specific number of approvals may be obtained. In an example of a consent workflow, an actor may only be able to access a target set of resources when approved by a designated authorizer. In another example of a workflow, a specific action may be automatically approved, for example, if consent has already been given.

[0142] In one embodiment, the system determines whether an actor should authorize consent to access a target set of resources (operation 1208). Based on the exemplary consent workflow and the approval obtained, the system can verify whether the consent workflow has been satisfied. In doing so, the system can enforce consent before enabling any action by any principal in a cloud partition (e.g., a tenant or PLC realm). In one embodiment, the system can verify whether the consent workflow has been satisfied, and such satisfaction is based on state data of the cloud environment. The consent service is configured to grant credentials that, if sufficient approval has been obtained, allow the actor to request access to a target set of resources to perform the consented action.

[0143] In one embodiment, if the system decides not to authorize consent (no), the system rejects the consent request (action 1210). The consent service for the second entity in the second cloud partition may return a message to the first cloud partition indicating the rejection of the consent request.

[0144] If the system decides to approve consent (yes), the system proceeds to determine whether the access policy permits the agent's access (action 1212). The consent service can call the identity service to determine whether the target set of resources satisfies any access policy.

[0145] Both the first and second entities manage their respective identity services for evaluating access policies, but these are separate from the consent workflow and are configured to control which actors are permitted access to the target set of resources. In one embodiment, the first entity also manages its own (independent) consent service for carrying out breakglass scenarios, for example, when it cannot access or direct the tenant's consent service. The first entity also manages a centralized service that onboards the target set of resources and enables actor-operators to perform the agreed-upon actions. The actor-operators of the second entity can use its consent service to retrieve consent status. Consent status information can be retrieved and dynamically evaluated for one or more purposes, such as deciding whether to validate consent tokens and / or agreed-upon actions.

[0146] In one embodiment, the system grants an actor a consent token (operation 1214). An example of the above-described credential embodiment is a consent token granted by the consent service of a second entity and a second cloud partition. The system can configure a consent token by setting a first time period during which the consent token is valid, and can also be activated for a second time period, which is the time during which the actor is permitted access to a target set of resources (i.e., while the consent token is valid and activated).

[0147] In one embodiment, the system can further configure a consent service to grant consent tokens by traversing an appropriate type of consent workflow. The consent service may use different types of consent workflows depending on the cloud environment. For example, if the appropriate consent workflow corresponds to a persistent consent workflow type, the consent request may be pre-approved by a group of one or more users (e.g., tenant-operator). In an example of a consent workflow corresponding to on-demand consent, obtaining the corresponding approval from a group of one or more users requires user input from one or more users responding to the consent request. Another example of a consent workflow type is quorum consent, which requires at least a certain minimum number of approvals from a group of one or more users in order to obtain each approval from that group of one or more users.

[0148] In one embodiment, the system sends a request to another service to access a target set of resources (operation 1216). The request may include a valid consent token granted by the consent service. The system sends this request to a service or application configured to evaluate the access policy and either allow or deny the request to access one or more target sets of resources. The second cloud partition manages its own identity and consent services to authenticate the consent token and return a consent token blob in response to validation of the token-based access policy. The consent service can be integrated with the identity service to obtain the relevant consent token blob. The consent token blob may be signed by the identity service.

[0149] In one embodiment, the system determines whether access to a target set of resources is permitted (operation 1218). The consent service can call the identity service to determine whether the target set of resources satisfies any applicable access policy. The identity service can then proceed to monitor the use of consent tokens in realm 1104. In one embodiment of the identity service, the consent token blob is evaluated to verify the scope of consent associated with the consent token. The consent service may further be adapted to operate a second cloud partition without supporting any host connections (e.g., from a first cloud partition).

[0150] One embodiment of the consent service in the second cloud partition sends a consent token to the identity service in the first cloud partition. The actor-operator in the first cloud partition can submit a service call to activate the consent token via the identity service (using the consent token blob described above) and receive a consent principal session token to initiate the execution of the consented action. As a result, the identity service can automatically grant access to a target set of resources based on the activated consent token.

[0151] After a target set of resources from another entity satisfies both the consent workflow and the access policy, the consented action is permitted by providing a consent token in a service request (e.g., a service call directed to an in-realm or in-region service). This service can be included as one of the aforementioned target sets of resources specified by the consent request. Actors—operators—can engage in a session with a service by submitting a service request and receiving the results of the service request via the console interface.

[0152] In one embodiment, a centralized service (referred to herein as the access manager) can onboard in-realm / in-region services. During an agent-operator session, the centralized service can act to submit service requests (e.g., in the form of function calls to the service API) that cause the onboarded service to perform agreed-upon actions.

[0153] If the system decides to grant access (yes), the system activates the consent token and allows the agent to perform actions on the target set of resources (action 1220). The identity service for either the first or second entity may determine that the consent token is within its validation period but has not yet been activated for use and therefore should be granted access to the target set of resources.

[0154] In one embodiment, if the system decides not to grant access (no), the system blocks access to the target set of resources (action 1222). An identity service relating to either the first or second entity may determine that the consent token is invalid or its activation period has expired and therefore should not be granted access to the target set of resources.

[0155] In an emergency, the actor-operator can access a service (e.g., a consent service) equipped with a disabling ("breakglass") function in one or more embodiments. Thus, the service can serve as an alternative consent service compared to the consent service in the second cloud partition. The disabling function allows the consent service to override previous rejections of consent requests under certain circumstances. 5. Examples of Embodiments For clarity, detailed examples are provided below. The components and / or operations described below should be understood as a single specific example, and may not be applicable to all particular embodiments. Therefore, the components and / or operations described below should not be construed as limiting the scope of any of the claims.

[0156] Figure 13A specifically illustrates an example of a GUI used by an entity to provide consent for an agent to access a target set of resources within a cloud environment, including a managed cloud partition. The entity can use this example GUI to allow / deny consent requests from different entities. The example GUI depicted in Figure 13A as Tenant Console 1300 represents an example of a tenant interface to a cloud partition in a cloud environment (e.g., Tenant Interface 1112 in Figure 11). Tenant Console 1300 renders user interface (UI) elements as GUI controls to receive inputs that include commands for presenting various information and modifying the presented information. In the case of Tenant Console 1300, an application or service (e.g., a control plane application or service) can assist in rendering the UI elements and the functionality of any controls. Inputs received through Tenant Console 1300 are processed by the application or service.

[0157] One embodiment of the tenant console 1300 notifies the tenant-operator of a pending consent request, such as the example pending consent request 1302. The above application or service can provide the example pending consent request 1302 to the tenant console 1300 and present it as a combination of a message box and form controls. The message box displays various attributes of the consent request, including actor attributes (e.g., operator identifier or user_id), action attributes, etc. The application form contains various settings for configuring the corresponding consent token request. The attributes must satisfy at least one criterion before approving the consent token request and subsequent consent token generation. Once satisfaction is confirmed, the various settings determine how the functionality of the consent token is configured.

[0158] In Figure 13A, the application form for the example pending consent request 1302 includes a button 1304, which, when activated, instructs an application or service to submit at least the entered form data to the consent service (or another identity data plane service). An example of a submission is a service call in which the above attributes and settings are entered as parameters for the function call. Once the corresponding consent token request is submitted, the tenant console 1300 deletes the example pending consent request 1302.

[0159] One embodiment of the tenant console 1300 presents a list of pending consent requests within the portal 1306. If a tenant-operator approves a given pending consent request and submits a corresponding consent token request, the tenant console 1300 removes the given pending consent request from the list or modifies the list entry to indicate the approved pending consent request. Conversely, if a consent request is rejected, the tenant console 1300 removes the given pending consent request from the list or modifies the list entry to indicate the rejected consent request. All incoming consent requests are added to the list in the portal 1306 upon receipt. Any interaction with the list entries is useful for selecting and further reviewing consent requests. Individual consent requests may be selected and presented in the same format as the exemplary pending consent request 1302.

[0160] As described herein, consent workflows are used to evaluate consent requests in accordance with tenant-operator instructions. The tenant console 1300 facilitates the definition of new consent workflows, each consent workflow generally defining a set of criteria for approving consent requests. This set of criteria can also be used when preparing to submit corresponding consent token requests for approved consent requests.

[0161] In one embodiment, the tenant console 1300 is depicted with a control 1308 (labeled “Consent Workflow” in Figure 13A) which has a dropdown menu for selecting various criteria to be programmed into an exemplary consent workflow. An exemplary pending consent request 1302 can be evaluated using that exemplary consent workflow, and if approved, the tenant console 1300 allows a button 1304 to accept activation by the tenant-operator and send a corresponding consent token request.

[0162] As shown, control 1308 includes an approval list menu that specifies which tenant-operators must provide approval before consent is granted. Control 1308 can further indicate which tenant-operators have already provided that approval. Control 1308 includes a type menu for setting the type attribute of the consent token, which defines the range of any new consent tokens that will be created when the approval list is completed. Control 1308 may include an action menu that facilitates the selection of attributes of specific agreed actions to be encoded into the new consent token. Before approving the new consent token, the attribute values ​​of the same agreed action must be found within the consent request. The new consent tokens distributed among tenant-operators in the CSP inform each tenant-operator which agreed actions have been approved.

[0163] The tenant console 1300 further includes control 1310 for displaying consent status information for any consent tokens approved / created by the tenant. Control 1310 further describes attribute information for each identified consent token.

[0164] Figure 13B specifically illustrates an example of a GUI used by a first entity to request consent for an agent to access a targeted set of resources within a cloud partition associated with a second entity. This example GUI further illustrates the network hierarchy of the cloud environment 1352 and the logical grouping of regions in the cloud partition 1354. The example GUI depicted in Figure 13B as the CSP console 1350 represents an example of a CSP interface to the cloud environment 1352.

[0165] A consent service running in region 1356 for the first entity (e.g., the home region within the CSP realm) and a consent service running in region 1358 for the second entity (e.g., the home region within the tenant realm) coordinate the tasks of consent-driven access management for a targeted set of resources within the cloud partition 1354.

[0166] The CSP console 1350 includes control 1360 (labeled “Consent Request” in Figure 13B) for defining and creating consent requests that will be sent to consent service instances within region 1356. Considering an example of a consent request from a CSP (i.e., the requester) to a tenant, a CSP operator can create and then send an example request by selecting a set of attributes from a dropdown menu, which may include user attributes (e.g., the user ID of the CSP actor - operator), action attributes (e.g., search logs, host connectivity, etc.), tenant home attributes (e.g., the region identifier of the home region within the tenant's realm), and target set attributes (e.g., identifiers that map to a target set of resources within the tenant's home region).

[0167] The CSP console 1350 includes control 1362 (labeled “Session Request” in Figure 13B) for defining and creating a session request that will be submitted to the appropriate service instance in region 1358. The target set of resources is located in a different region, within the cloud partition 1354, but the appropriate service instance can use a consent token to access the target set of resources and perform the agreed actions. For an example session request, the CSP operator can create and then submit the example request by attaching a matching consent token and selecting the identifier of the appropriate service instance. Upon receiving the example session request in region 1358, the appropriate service instance can be prompted to start a session and authenticate the agreed actions. Once the session is started, the CSP console 1350 submits a service request (e.g., a service function call or message) to the appropriate service instance in region 1358 and receives a service response (e.g., a message) from the execution of the service request. The CSP console 1350 can generate a window 1364 to display the result from the execution of the service request submitted to the appropriate service instance.

[0168] The CSP console 1350 can keep a dialog box 1366 displaying the status information of previous / current consent requests up to date. Each consent request may be pending, rejected, or approved by the tenant-operator of the cloud partition 1358. The CSP consent 1350 can display a message indicating that approval of a consent request is pending action by one or more users who will be obtaining the corresponding approval.

[0169] Figure 14 shows an example sequence of interactions between different components of a system for consent-driven access management in a cloud partition of a cloud environment. As described herein, user principal 1402 and operator 1404 refer to potential actors in the first and second entities of the cloud environment, respectively. The Identity Data Plane API 1406 represents a set of services, including consent services and identity services, for governing consent between the two entities and managing access to cloud resources. Generally, the Identity Data Plane API 1406 is configured to manage users, groups, identity domains, compartments, policies, tagging, and restrictions. Similar to the consent services described in detail above, the Identity Data Plane API 1406 facilitates interactions between user principal 1402 (e.g., CSP actor-operator) and tenant-operator 1404. The Identity Data Plane API 1406 manages the approval / rejection process for all consent requests coming from actor-operators, thereby controlling actor-operator activity within a tenant's cloud partition to host services, for example, to monitor the health of different realms within a given realm.

[0170] Service API 1408 and Service API 1410 are both APIs for local services running within the CSP home region (e.g., CSP services running within a CSP realm). User Principal 1402, by possessing a consent token, can authorize one or both of the above local services to access targeted resources (e.g., in another realm such as a tenant realm) and perform consented actions on these access-controlled targeted resources.

[0171] User Principal 1402 initiates a consent request via the CSP Console 1350 by authenticating one or more attributes, including the identity of User Principal 1402 or the First Entity. Once the consent request is authenticated, User Principal 1402 uses the CSP Console 1350 to initiate the creation / approval of the consent request via the Identity Data Plane API 1406.

[0172] Generally, the tenant console 1300 displays pending consent requests, which the operator 1404 reviews and either approves or rejects. Each consent request includes a request to access a target set of resources. The CSP console 1350 invokes the consent service function to create consent requests to present on the tenant console 1300, which the operator 1404 then receives and either rejects or approves.

[0173] Through the tenant console 1300, operator 1404 invokes a service call to the identity data plane API 1406, which is configured to send a consent token request from the consent service. In one embodiment, the consent service authorizes the creation of the requested consent token in response to evaluating the consent request against the consent workflow. Via the identity data plane API 1406, the consent service returns a consent token blob representing the requested consent token to the tenant console 1300. Operator 1404 can enter their authorization via the tenant console 1300 to convert the blob into an authorized / verified consent token.

[0174] In addition or alternatively, the consent service authorizes the creation of the requested consent token and then instructs the identity service to provide the consent token blob to the CSP console 1350 via a function call to the identity data plane API 1406. The identity service submits a service call to the CSP console 1350, which ultimately results in the user principal 1402 being notified of the successful creation of the consent token. The CSP considers the consent token blob to be an authorized consent token and can store the consent token in its local data store. The user principal 1402 can retrieve the consent token via the CSP console 1350 for several purposes. For example, following instructions from the user principal 1402, the CSP console 1350 can submit a session request with the consent token attached.

[0175] By submitting a session request to service API 1408, the consent token is activated and a consent session is initiated. In this way, user principal 1402 can leverage the token as proof of proper authorization for accessing and / or searching the logs. While the session is active, user principal 1402 submits a service request to service API 1408 to initiate a log search (as part of the consented action). Based on the presence of the consent token and session token, service API 1408 can securely authorize the log search and return any log search results to the CSP console 1350 for presentation to user principal 1402.

[0176] Similarly, the CSP console 1350 can execute a function call on behalf of the user principal 1402 to activate the consent token and initiate a consent session with the service API 1410 for operating the matrix service. The user principal 1402 provides input through the service API 1410 to instruct the execution of a matrix search. The service API 1410 can validate the scope of the matrix search based on the activated consent token before authorizing the transmission of any matrix search results to the CSP console 1350 / presentation on the CSP console 1350. 6. Other developments Unless otherwise defined, all terms (including technical and scientific terms) are given their ordinary, conventional meanings to those skilled in the art, and are not limited to any special or customized meanings unless expressly defined herein.

[0177] This application may include references to a trademark. While the use of a trademark is permitted in a patent application, the nature of a trademark as a proprietary property should be respected, and every effort should be made to prevent any use in any form that could adversely affect its validity as a trademark.

[0178] The embodiments are directed to a system comprising one or more devices, each including a hardware processor and configured to perform any of the operations described herein and / or in any of the following claims.

[0179] In one embodiment, one or more non-temporary computer-readable storage media include instructions that cause one or more hardware processors to perform any of the operations described herein and / or any of the claims.

[0180] In one embodiment, the method includes an operation described herein and / or described in any of the claims, and the method is performed by at least one device including a hardware processor.

[0181] Any combination of the features and functionalities described herein may be used according to one or more embodiments. The embodiments have been described with reference to numerous specific details, which may vary from implementation to implementation. This specification and the drawings should therefore be considered in an illustrative rather than restrictive sense. The scope of this disclosure, and the sole and exclusive indicator of what the applicants intend to be the scope of this disclosure, is the literal and equivalent scope of the set of claims issued from this application, in the specific form in which such claims are issued, including any subsequent amendments.

Claims

1. Receiving a consent request from the requester asking for the agent's consent to access a target set of resources within the cloud environment, Identifying a consent workflow that specifies at least one of the names or attributes of a group of one or more users from whom the corresponding approval for the consent request is obtained, Traversing the aforementioned consent workflow to obtain the corresponding approval from the one or more user groups, Determining that one or more access policies separate from the consent workflow permit the aforementioned actor to access the target set of resources, A method including, Access by the agent to the target set of resources is based on both (a) obtaining the corresponding authorization from the one or more user group and (b) determining that one or more access policies separate from the consent workflow permit the agent to access the target set of resources. The method is performed by at least one device including a hardware processor.

2. Granting a consent token in response to obtaining the corresponding approval, Further comprising sending a request to access one or more sets of resources, wherein the request includes the consent token. The method according to claim 1, wherein granting or denying the request to access one or more of the set of resources is at least partially based on the presence of the consent token.

3. The method according to claim 2, wherein granting or denying the request to access one or more of the set of resources is further based on verifying the access policy based on the consent token.

4. The method according to claim 2, wherein granting or denying the request to access one or more of the set of resources is further based on verifying the scope of consent associated with the consent token by an identity service.

5. The aforementioned operation is, The method of claim 2, further comprising storing information indicating the scope of consent associated with the consent token by an identity service associated with granting the consent token.

6. The consent token can be activated for a first predetermined period of time from the time the consent token is granted. The aforementioned consent token, once activated, is valid for a second predetermined period of time. The method according to claim 2.

7. The method according to claim 1, wherein a first entity manages the set of access policies and a second entity manages the consent workflow.

8. The method according to claim 1, wherein the requester is associated with a first entity, and the set of one or more users from which the corresponding approval is obtained is associated with a second entity.

9. The aforementioned first entity is a cloud service provider, The first entity controls, at least partially, the second entity's access to the cloud environment. The second entity controls, at least partially, the third entity's access to the partitions of the cloud environment. The method according to claim 8.

10. The aforementioned first entity is a cloud service provider, The first entity makes a request to the second entity for the use of the cloud environment, The second entity makes a claim to the third entity for the use of the cloud environment. The method according to claim 8.

11. The aforementioned consent workflow is (a) Sustained consent, in which the consent request is pre-approved by the one or more user group. (b) Obtaining the corresponding approval from the group of one or more users requires user input from the one or more users in response to the consent request, or on-demand consent, (c) The method according to claim 1, wherein obtaining the corresponding approval from the group of one or more users is equivalent to one of the quorum agreements which requires at least a minimum number of approvals from the group of one or more users.

12. The method according to claim 1, wherein the consent workflow evaluates conditions based on the state data at the time of the consent request.

13. The method according to claim 1, wherein if one or more invalidation conditions are met, the requester is permitted to obtain consent for the agent to access the target set of resources in the cloud environment in circumstances where the consent request would normally be denied.

14. The method according to claim 1, wherein the consent request includes one or more search attributes that are mapped to a target set of resources in the cloud environment.

15. The method according to claim 1, wherein the requester is the actor.

16. The aforementioned operation is, The requester receives a request from the agent to access one or more of the set of resources in the cloud environment, The method according to claim 1, further comprising the requester generating the consent request on behalf of the actor in response to the request to access the one or more set of resources in the cloud environment.

17. The aforementioned operation is, The system further includes receiving user input via a first console to select the consent workflow from among several available consent workflows, The method according to claim 1, wherein the requester receives the consent request via a second console separate from the first console.

18. The aforementioned operation is, The method according to claim 17, further comprising displaying a message in the second console indicating that the approval of the consent request is pending an action by the one or more user group from which the corresponding approval was obtained.

19. It is a system, One or more hardware processors, One or more non-temporary computer-readable media, The system comprises one or more program instructions stored in one or more non-temporary computer-readable media, which, when executed by the one or more hardware processors, cause the system to perform the operation described in any one of claims 1 to 18. system.

20. A system comprising means for performing the operation described in any one of claims 1 to 18.

21. One or more non-temporary computer-readable media storing instructions that, when executed by one or more hardware processors, cause an operation according to any one of claims 1 to 18, wherein the method is executed by at least one device including a hardware processor.

Images