Techniques for automatically configuring minimum cloud service access rights for container applications

Abstract

The invention relates to techniques for automatically configuring minimum cloud service access rights for container applications. A computer system may receive one or more requests to access one or more cloud services (228, 230, 232), and may store the one or more requests in a request log (216). A computer system receives one or more access rules applicable to cloud service access rights (218). The computer system aggregates the one or more requests of the request log to determine access requirements for a container (206, 208, 210) configured to store one or more applications. The computer system generates and stores a container access policy (222) defining access to the container and the one or more cloud services, the container access policy based at least in part on the aggregated one or more requests and one or more access rules. The computer system sends the container access policy (222) to a request transponder (274) of the compute instance in the production environment (252).

Description

[0001] This application is a divisional application of the PCT application entering the Chinese national phase, with an international filing date of February 8, 2022, national application number 202280015223.8, and invention name “Technology for Automatically Configuring Minimum Cloud Service Access Permissions for Container Applications”.

[0002] CROSS REFERENCE TO PRIOR APPLICATIONS

[0003] This application is a PCT application of U.S. non-provisional application No. 17 / 177,159, filed on February 16, 2021, entitled “TECHNIQUES FOR AUTOMATICALLY CONFIGURING MINIMAL CLOUD SERVICE ACCESS RIGHTS FOR CONTAINER APPLICATIONS,” and claims the benefit and priority thereof under 35 U.S.C. 119(e), the contents of which are incorporated herein by reference in their entirety for all purposes. Background Art

[0004] Infrastructure and platform as a service cloud providers support integrated authentication. In particular, customer workloads hosted on a cloud provider's infrastructure can authenticate using the identities of the compute instances on which they are hosted. This model can allow customers to build secure workloads. Without it, customers would be required to bootstrap their instances or applications running on them with credentials every time they create an instance and ensure that such credentials are recognized by the cloud service.

[0005] Customer access rules can restrict access to certain services or customer data by a compute instance or node to prevent all containers from having the same level of access to the cloud infrastructure. Existing systems that establish connectivity for cloud services can often use overly permissive permission rules where all containers have the same level of access to the cloud infrastructure. Summary of the invention

[0006] Certain embodiments of the present disclosure may provide methods, systems, and computer-readable storage media for managing access to cloud-based services. The present disclosure describes systems and techniques for mediating requests between containers and cloud services to provide a sufficient level of access control. The disclosed techniques combine internal authentication of a cloud coordinator to identify container callers and cloud service authentication to authenticate calls made to cloud services. In some examples, individual containers running on a system may not be able to directly access metadata services or instance credentials. Instead, a container may send a request through a request forwarder component. The component establishes a container identity and verifies whether a particular container has the right to communicate with a target service (e.g., a cloud service). The request forwarder component uses instance credentials to authenticate calls to a target service. Compute instances can be configured in a way that prevents containers from accessing metadata services. The technique effectively prevents processes in a container from using compute instance credentials. A compute instance is an example of a virtual processor, a compute node in a cloud, or even a bare metal processor (e.g., a physical hardware computer).

[0007] When a container is initialized, the container orchestrator can provide credentials to it. In addition to replacing nodes, replacing containers with nodes, etc., the container orchestrator can also use credentials to identify containers. This process can take different forms. In some cases, the process will cause the credentials to be stored on the file system of the container. According to one aspect of the present disclosure, the process executed in the container is intended to call a cloud service. The process can direct a request for a cloud service to a request forwarder. The request may include container credentials. The request forwarder may receive the request and determine the identity of the container by sending the container credentials to the container orchestrator. The request forwarder may refer to one or more policies stored on the system to verify whether the container is allowed to access the target cloud service. The request forwarder may obtain instance credentials from the metadata service. The request forwarder may send a request including a computing instance credential to the target cloud service. The cloud service may verify the request against one or more stored cloud policies to verify whether the instance running in the container is allowed to access the requested cloud service.

[0008] Specifically, a container can execute one or more applications that can request access to cloud resources. For example, resources can be used to create virtual machines, or access sequences or data objects, or manage keys in a key management system, or store data in a database. Cloud infrastructure systems can include their own integrated access management mechanisms. In the access management system, access rights can be granted to subjects. Although it is technically possible to create subjects for each container, the technology would need to include granting access rights to each container. This technology is difficult to replicate on a large scale because it requires provisioning credentials and partitioning these containers. This problem can only be solved using compute nodes. Compute nodes have their own first-class identities, and access rights to these nodes can be granted. Therefore, these machines are able to perform these kinds of actions as subjects.

[0009] Assuming there are two pieces of data that need to be stored separately, the disclosed technology allows for isolation of containers. For example, one container can store the first piece of data, and a second container can store the second piece of data. Ideally, the containers are never hosted on the same machine. In this way, if there is a breach or vulnerability in one container or in the isolation of the containers, the vulnerability does not provide access to other data in other containers.

[0010] In some aspects, a method includes: receiving one or more requests for access to one or more cloud services (e.g., from a sender); storing the one or more requests in a request log; receiving one or more access rules applicable to cloud service access rights (e.g., from different senders or the same sender); aggregating the one or more requests of the request log to determine access requirements for a container, which is configured to store one or more applications; generating a container access policy that defines access to the container and the one or more cloud services, the container access policy being based at least in part on the aggregated one or more requests and the one or more access rules; storing the container access policy in a memory; and sending the container access policy to a request forwarder of a computing instance in a production environment, which accesses the container access policy to grant the container access to the one or more cloud services.

[0011] In some aspects, a node access policy is generated that specifies an access policy for granting a group of compute instances combined access rights to one or more containers on a node; and the container access policy is stored in a memory.

[0012] In some aspects, the method includes granting access permissions equivalent to the combined access rights of the one or more containers assigned to the node.

[0013] In some aspects, the method includes partitioning a computing instance having multiple computing instances into node groups, each of the nodes having different access rights; and assigning one or more containers to nodes with sufficient access rights based at least in part on a node access policy.

[0014] In some aspects, node access rights are predetermined and container access rights within each node are dynamically configured.

[0015] In some aspects, the method includes testing access requirements of the cloud system; detecting a failure of a particular application to access the one or more cloud services based at least in part on entries in a request log; and changing permissions of a computing instance to fix the failure.

[0016] In some aspects, the method includes setting a request forwarder for each container type in a production environment to a permissive mode that grants the one or more applications stored in the container access to the one or more cloud services; receiving the one or more requests from the request forwarder; and switching the request forwarder to a restricted mode based on a number of the one or more requests exceeding a threshold requirement, wherein the restricted mode grants the one or more applications access to the one or more cloud services based at least in part on a container access policy, and switching the request forwarder to a restricted mode that grants the one or more applications access to the one or more cloud services based at least in part on a container access policy.

[0017] In some aspects, a non-transitory computer-readable medium storing an instruction set for configuring cloud service access permissions for a container application includes: one or more instructions that, when executed by one or more processors of a computer system, cause the computer system to: receive one or more requests for access to one or more cloud services (e.g., from a sender); store the one or more requests in a request log; receive one or more access rules applicable to cloud service access permissions (e.g., from different senders or the same sender); aggregate the one or more requests of the request log to determine access requirements for a container configured to store one or more applications; generate a container access policy that defines access to the container and the one or more cloud services, the container access policy being based at least in part on the aggregated one or more requests and the one or more access rules; store the container access policy in a memory; and send the container access policy to a request forwarder of a computing instance in a production environment, which accesses the container access policy to grant the container access to the one or more cloud services.

[0018] In some aspects, the one or more instructions further cause the computer system to: generate a node access policy that specifies an access policy for granting a group of computing instances combined access rights to one or more containers on a node; and store the container access policy in a memory.

[0019] In some aspects, the one or more instructions further cause the computer system to: grant access permissions equivalent to the combined access rights assigned to the one or more containers of the node.

[0020] In some aspects, the one or more instructions further cause the computer system to: partition a computing instance having multiple computing instances into node groups, each of the nodes having different access rights; and assign one or more containers to nodes having sufficient access rights based at least in part on a node access policy.

[0021] In some aspects, node access rights are predetermined and container access rights within each node are dynamically configured.

[0022] In some aspects, the one or more instructions further cause the computer system to: test access requirements of the cloud system; detect a failure of a particular application accessing the one or more cloud services based at least in part on entries in the request log; and change permissions of the computing instance to fix the failure.

[0023] In some aspects, the one or more instructions further cause the computer system to: set a request forwarder for each container type in the production environment to a permissive mode that grants the one or more applications stored in the container access to the one or more cloud services; receive the one or more requests from the request forwarder; and based on the number of the one or more requests exceeding a threshold requirement, switch the request forwarder to a restricted mode that grants the one or more applications access to the one or more cloud services based at least in part on a container access policy.

[0024] In some aspects, a computer system includes: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to perform operations for configuring cloud service access rights for container applications, the operations including: receiving one or more requests for access to one or more cloud services (e.g., from a sender); storing the one or more requests in a request log; receiving one or more access rules applicable to cloud service access rights (e.g., from different senders or the same sender); aggregating the one or more requests of the request log to determine access requirements for a container, the container being configured to store one or more applications; generating a container access policy that defines access to the container and the one or more cloud services, the container access policy being based at least in part on the aggregated one or more requests and the one or more access rules; storing the container access policy in the memory; and sending the container access policy to a request forwarder of a computing instance in a production environment, the request forwarder accessing the container access policy to grant the container access to the one or more cloud services.

[0025] In some aspects, the one or more processors are further configured to perform operations including: generating a node access policy that specifies an access policy for granting a group of computing instances combined access to one or more containers on a node; and storing the container access policy in a memory.

[0026] In some aspects, the one or more processors are further configured to perform operations comprising granting access permissions equivalent to combined access rights assigned to the one or more containers of the node.

[0027] In some aspects, the one or more processors are also configured to perform operations including: partitioning a computing instance having multiple computing instances into node groups, each of the nodes having different access rights; and assigning one or more containers to nodes with sufficient access rights based at least in part on a node access policy.

[0028] In some aspects, node access rights are predetermined and container access rights within each node are dynamically configured.

[0029] In some aspects, the one or more processors are further configured to perform operations including: testing access requirements of the cloud system; detecting a failure of a particular application to access the one or more cloud services based at least in part on entries in a request log; and changing permissions of the computing instance to fix the failure.

[0030] Other features and advantages of the disclosed embodiments will be realized with reference to the remainder of this specification (including the drawings and claims). Further features and advantages of the present disclosure and the structure and operation of various examples are described in detail below with respect to the drawings. In the drawings, similar reference numerals may indicate identical or functionally similar elements.

[0031] These and other embodiments are described in detail below.For example, other embodiments are directed to systems, devices, and computer-readable media associated with the methods described herein.

[0032] A better understanding of the nature and advantages of embodiments of the present disclosure may be obtained with reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A logical construct for an example cloud network architecture is illustrated.

[0034] Figure 2 The logical construction of a second example cloud network architecture is illustrated.

[0035] Figure 3 is a flow diagram of an example process associated with a technique for automatically configuring minimal cloud service access permissions for a container application.

[0036] Figure 4 An example arrangement diagram showing permitted arrangements of the disclosed system is illustrated.

[0037] Figure 5 An example arrangement diagram showing a prohibited arrangement of the disclosed system is illustrated.

[0038] Figure 6 An example diagram of allowed groups is shown.

[0039] Figure 7 is a simplified flow chart of a technique for selective container access to a cloud service based on using a request forwarder as a hosting node for the service.

[0040] Figure 8 is a block diagram illustrating one mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0041] Fig. 9 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0042] Fig.10 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0043] Fig.11 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0044] Fig.12 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION

[0045] I. Introduction

[0046] Modern computing frameworks abstract the concept of machines. Machines can be thought of as just processing units. Modern applications are increasingly built using containers, which are microservices packaged with their dependencies and configurations. Container management / clustering services are software for deploying and managing these containers at scale. As applications grow to multiple containers deployed across multiple servers, operating them becomes more complex. To manage this complexity, container management / clustering services provide open source application programming interfaces (APIs) that control how and where these containers will run. Container management / clustering services orchestrate clusters of virtual machines and schedule containers to run on these virtual machines based on their available computing resources and the resource requirements of each container. Containers are grouped into clusters (pods), the basic operating unit for container management / clustering services, and these clusters are expanded to the desired state. Container management / clustering services also automatically manage service discovery, combine load balancing, track resource allocation, scale based on computing utilization, check the health of individual resources, and enable applications to self-heal by automatically restarting or replicating containers.

[0047] A network orchestrator can be used to assign the number of instances for each container. Based on how busy each machine is, containers can be added or removed to create high workload density, saving costs. Containers can be tailored for high input / output (I / O) bandwidth to improve performance.

[0048] Cloud providers can issue identities for each compute node. In this way, a node can have its own identity. There is a standard mechanism to get that identity. So if a container is running a process on a node, the system can call, for example, a specific IP address. This can return a specific identity associated with that specific instance, temporary credentials. That credential will have multiple parameters, such as what the specific machine is and what machine group the machine belongs to.

[0049] In the example, a customer can use two services (e.g., compute and object storage) from a cloud provider. The customer's application runs on the compute instance and retrieves and stores data from the object storage bucket. Without an integrated authentication mechanism, the customer will be forced to operate in the same way as in a traditional pre-cloud environment. That is, the customer will need to: create users under their account; grant these users access to the object storage; and provide the user's credentials to the application. The last step can be particularly problematic. Before the application can become operational, the credentials must be placed on the system. If the system is restarted, or a new machine is added, then this step must be repeated. It must also be performed manually by an engineer who has access to the credentials, which increases the risk of credential exposure. To make the process less cumbersome, the customer may decide to persist the credentials on the machine itself, or in a location where multiple machines can access it. This may further increase the risk of credential leakage. In addition to security issues, such a process cannot scale for complex and large workloads. The requirement for synchronized actions (e.g., creation of credentials, distribution of credentials) poses a serious problem for highly automated cloud workloads. Moreover, the process must be repeated every time the customer wants to change the credentials.

[0050] Modern cloud vendors offer highly integrated identity access management (IAM) solutions. IAM is a framework of policies and technologies used to ensure that the right people in an enterprise have appropriate access to technology resources. IAM systems fall under the overall umbrella of IT security and data management. Identity and access management systems identify, authenticate, and authorize not only the individuals who will use IT resources, but also the hardware and applications that employees need to access. Identity and access management solutions have become more prevalent and important in recent years as regulatory compliance requirements have become increasingly stringent and complex.

[0051] It addresses the need to ensure appropriate access to resources across increasingly heterogeneous technology environments and meet increasingly stringent compliance requirements. Compute instances and other resources dedicated to host customer workloads (such as serverless functions) have their own identities recognized by cloud IAM under the customer's account. Customers can directly treat these components as a class of principals, group them and grant them the access they need. Compute machines, functions, and other components are automatically provisioned with short-term credentials accessible to their hosting processes. Applications retrieve these credentials and use them to access cloud resources.

[0052] Problems can arise when customers intend to host multiple heterogeneous processes on a single compute instance. This is common when compute nodes are used to run containers managed by an orchestration framework, such as those used in commercial container management / clustering services. The core of the problem is that the smallest granularity of identity is a single machine. Just because containers are hosted on the same machine, it does not mean that they are intended to have the same access to cloud resources. However, since a single machine is the most fine-grained identity, containers all need to share it.

[0053] Consider the following example. A customer uses two services from a cloud provider: compute and object storage. The customer's application runs on the compute instances and performs operations to store and retrieve data from buckets within the object storage. Without an integrated authentication mechanism, the customer would be forced to operate in the same way as in a traditional pre-cloud environment. The pre-cloud system would: (1) create a user in its account; (2) grant the user access to the object storage; and (3) provide the user's credentials to the application.

[0054] This last step is particularly problematic. Before the application can become operational, the credentials must be placed on the system. If the system is restarted, or a new machine is added, then this step must be repeated. It must also be performed manually by an engineer who has access to the credentials, which increases the risk of credential exposure. To save time, customers may decide to persist the credentials on the machine itself, or store it in a location where multiple machines can access it, further increasing the risk of credential leakage.

[0055] In addition to security issues, this process does not scale to accommodate large or complex workloads. The requirement for synchronous actions (e.g., creation of credentials or distribution of credentials) can cause problems for highly automated cloud workloads. In addition, the process must be repeated every time a customer wants to change credentials.

[0056] Compute instances and other resources (such as serverless functions) dedicated to hosting customer workloads have their own identities recognized by cloud IAM under the customer account. Customers can simply treat these components as first-class principals, group them and grant them the access they need. Compute instances, functions, and other components are automatically provisioned with short-term credentials that enable access to the processes they host. Applications can then retrieve these credentials and use them to access cloud resources.

[0057] In a typical implementation, a compute instance includes a locally accessible network service, often referred to as a metadata service. This service allows local workloads on the system to access various information propagated by the cloud provider, such as the credentials representing the principal of the compute instance. The metadata service can only be accessed by processes running on this particular computer. The process makes a request to the metadata service, receives the credentials, and uses it to access other cloud services. Other services use the cloud provider's IAM service to verify that the principal representing the instance has the authority to perform the requested operation.

[0058] Certain embodiments of the present disclosure may provide methods, systems, and computer-readable media for managing access to cloud-based services. Two types of access control are described herein. First, a container can access a specific cloud service. This access can be based on a policy called a service to determine whether the container has permission. In addition, a second access control is performed by a computing instance on a cloud service. Therefore, a process running on a container requires permission from the container to access the cloud service, but it also requires permission from the computing instance of which the container is a part to access the cloud service.

[0059] The present disclosure describes systems and techniques for mediating requests between containers and cloud services in order to provide an adequate level of access control. The disclosed techniques combine internal authentication of a cloud orchestrator to identify container callers and cloud service authentication to authenticate calls made to cloud services. In some examples, individual containers running on a system may not have direct access to metadata services or instance credentials. Instead, containers can send requests through a request forwarder component. This component establishes container identity and verifies whether a particular container has permission to communicate with a target service. The request forwarder component uses instance credentials to authenticate calls to target services. Compute instances can be configured in a way that prevents containers from accessing metadata services. The techniques effectively prevent processes in a container from using compute instance credentials. A container gains access to cloud services through the machine on which it runs, since containers cannot be given direct access due to these techniques.

[0060] When a container is initialized, the container orchestrator can provide it with credentials. This process can take different forms, but the most typical will be a process that causes the credentials to be stored on the container's file system. According to one aspect of the present disclosure, a process executed in a container is intended to make a call to a cloud service. The process can direct a request to a cloud service to a request forwarder. The request may include container credentials. The request forwarder can receive the request and determine the identity of the container by sending the container credentials to the container orchestrator. The request forwarder can consult one or more policies stored on the system to verify whether the container is allowed to access the target cloud service. The request forwarder can obtain instance credentials from the metadata service. The request forwarder can send a request including the computing instance credentials to the target cloud service. The cloud service can verify the request against the cloud policy to verify whether the cloud service allows the instance to perform a given operation.

[0061] For the purposes of this disclosure, an instance (e.g., a compute instance) is a hosted server running in a customer enclave (publicly available) or a service enclave. If the instance has direct access to the hardware on which it is running, it can be considered a bare metal instance. If there is a hypervisor between the instance and the operating system, it can be considered a virtual instance. A hypervisor is a piece of software that enables a user to create and run one or more virtual machines simultaneously. A hypervisor is also known as a virtual machine monitor (VMM). One of the key functions provided by a hypervisor is isolation, which means that a guest cannot affect the operation of the host or any other guest, even if it crashes. Hypervisors can be of two types: type 1 and type 2. Type 1 hypervisors can be referred to as native or bare metal hypervisors, which run directly on top of the physical hardware. Each virtual operating system runs on top of the hypervisor. Examples of bare metal hypervisors can be Oracle VM Server, Vmware ESX / ESXi, and Microsoft Hyper-V. Type 2 hypervisors can also be referred to as hosted hypervisors. This type of hypervisor is installed as a software application on an existing host operating system (OS). Examples of hosted hypervisors can be Oracle VirtualBox, Microsoft Virtual PC, Vmware Server, and Workstation.

[0062] For the purposes of this disclosure, a container is a collection of schemas, objects, and related structures in a multi-tenant container database (CDB) that logically appears as a separate database to an application. Within a CDB, each container has a unique ID and name. The root and each pluggable database (PDB) are considered containers. PDBs isolate data and operations, so from a user or application perspective, each PDB looks like a traditional non-CDB.

[0063] Figure 1 The logical construction of an example cloud network architecture 100 is illustrated. The cloud network architecture may include one or more containers (e.g., container 1 104, container 2 106, and container 3 108). In an embodiment, the computing instance 102 may include a locally accessible network service, generally referred to as a metadata service 110. This metadata service 110 allows local workloads on the system to access various information propagated by the cloud provider, including credentials representing the principal of the computing instance 102. The metadata service 110 can only be accessed by processes running on this particular machine. The process can contact the metadata service 110 to obtain credentials and use the credentials to access other cloud services (e.g., cloud service A 112, cloud service B 114, or cloud service C 116). These services use the cloud provider's IAM service to verify whether the principal representing the instance has the authority to perform the requested cloud operation.

[0064] Problems may arise when a customer intends to host multiple heterogeneous processes on a single compute instance 102. This may be common when compute nodes are used to run containers managed by an orchestration framework (e.g., such as a container management / clustering service, etc.). The smallest granularity of an identity may be a single machine. Previous techniques may simply assign access to one or more cloud services to a machine, and not necessarily to different containers residing on the same machine. Just because containers are hosted on the same machine does not mean that they have the same access to cloud resources. However, since a single machine is the most granular identity, they all need to share it.

[0065] For example, Figure 1 Container 1 104 communicates only with Cloud Service A 112. Container 2 106 communicates with Cloud Service A 112 and Cloud Service B 114. Container 3 108 communicates with Cloud Service C 116. In one arrangement, the customer may accept the risk of nodes accessing unintended cloud services. In this arrangement, compute nodes are granted all access rights that any container they host may need, and all containers receive access node credentials. This approach effectively sacrifices security for convenience. For example, in Figure 1 In the arrangement shown in , compute instance 102 may be provided access to cloud service A 112, cloud service B 114, and cloud service C 116. As an example, a process running on container 1 104 may be prohibited from accessing cloud service C 116, perhaps because the service belongs to a competitor entity. If access was controlled only by the compute instance, then a process running in container 1 104 could inadvertently gain access to cloud service C 116 because compute instance 102 provides all containers with permission to access all three cloud services shown.

[0066] In a second arrangement, customers can selectively disable metadata service 110 access to some containers. In this arrangement, containers that do not need access to any cloud resources can be prohibited from accessing metadata service 110. This can be simple to implement, but it is an all-or-nothing approach. This arrangement does not help with containers that have different access requirements. Therefore, using firewall rules or network policies, the user can decide to only allow this container to access the entire metadata service network. Furthermore, this only works if the container needs to access any services. Therefore, at least the components that do not need to access any cloud services can be isolated by disrupting the path for the container to obtain credentials.

[0067] In a third arrangement, customers can distribute containers to individual machines. In this arrangement, customers can create a group of compute nodes and grant different access rights to each group of compute nodes. Customers can then configure the container orchestrator to place containers on nodes with access rights that match the needs of each container. Nodes can be put into different groups. These groups assign different access rights to these nodes, and then configure the scheduler in the container orchestrator to assign only specific containers to specific nodes. This approach works in limited cases, but the more you need to do it, the more dispersed a group of machines becomes, the more users lose out on machines, and the overall workload density suffers. This arrangement provides containers with customized access to cloud resources. However, this arrangement can be more complex and requires careful mapping strategies and planning to nodes and nodes to containers, and can result in poor resource utilization.

[0068] Customers can also use any combination of these options, increasing the complexity of access management. The drawbacks of the solutions mentioned above increase with the size and complexity of the workload, especially the number of different containers and their cloud service access requirements. Accepting the risk will result in increasing scope of access to individual containers, even if they may not need it. Distributing a large number of containers can lead to an ever-increasing number of different machines required and will make it more complex to find the right set of access rights required on each node. In extreme cases, customers may decide to set up pools of machines for each container type, which will provide perfect access restrictions but defeat the purpose of using a container management service in the first place and greatly increase costs due to low process density.

[0069] Some providers (such as commercially available container management / clustering services) provide support for containers (e.g., clusters) using their own type of principal in the services they manage. Thus, access can be granted directly to the container itself, rather than relying on metadata service 110. While this can be a useful solution, it is limited to a given vendor and the vendor's specific services. Customers who want to manage their own clusters or want to use a different framework will not be able to implement this solution.

[0070] II. Logical Structure of Cloud Network Architecture

[0071] Multiple types of instances can be required as cloud services add and remove containers or add rules. Multiple types of instances can grant different levels of access to different instances. This process can be difficult to perform at scale and is more complex than simple manual network mapping.

[0072] Machine access to cloud services can be managed by cloud IAM. The disclosed technology can determine two policies. One policy manages container access within a node. The second policy manages node access within the cloud.

[0073] A potential IAM solution could establish a request forwarder that can identify components making calls to cloud services. Components can use their own identities to call cloud provider services. This request forwarder has access to one or more policies that determine the configuration and which services can be called with which APIs and with which credentials.

[0074] Such a system can be difficult to implement at scale or with the modern, fast-paced software delivery paradigm. New or updated components can be delivered on a daily basis, each with different requirements for communicating with cloud services. This makes any manual management of individual component policies impractical and error-prone. This, in turn, can lead to overly permissive licensing policies that allow all components to access services that are not needed. Access to the compute node itself must also be managed to ensure that there is no discrepancy between it and the combined licensing of all containers running on the node.

[0075] A second issue can be managing compute node access. The above discussion assumes that a compute node has sufficient access rights to handle all requests from the various containers located on that node. However, managing compute node access can also be very difficult, especially in a rapidly changing environment. In principle, a compute node must have access rights to the union of all access nodes for all containers hosted on that node. As containers on a node are added, removed, or relocated, the access requirements of the node change. This often results in granting too many permissions to compute nodes to ensure that all containers have the required access rights. Best security practices dictate that node access rights be granted to the smallest possible set. Management of node access rights, now correctly understood to be distinct from management of container access rights, becomes a major operational hurdle.

[0076] The present disclosure describes a system that automatically infers a minimum required set of access requirements for both containers and compute nodes. These requirements are further expressed as policies provided to request forwarders and cloud IAM. It also combines the life cycle of components with the life cycle of the policy itself. In addition, the system allows the specification of criteria or access rules to control how access rights are assigned to nodes. Therefore, by aggregating the requests of the request log, the system can determine the minimum required set of access requirements, which is used to determine the access requirements (e.g., minimum set) of the container. In other words, the access requirement can be equal to the minimum required set of the container (and / or the compute node of the container).

[0077] With such a system, users can quickly deliver new components and modify existing components while ensuring that access granted to cloud services is kept to a minimum. Without an automated mechanism for generating narrow and specific policies, users may tend to grant overly permissive access to containers (or even more likely compute instances). Alternatively, when a high level of security is desired, manually preconfiguring a single centralized policy may negatively impact the performance of feature release cycles. The disclosed system allows development teams to achieve high-speed delivery without sacrificing high security for access control. In addition, because access rules can be specified, the system can automatically divide containers into nodes and automatically build secure isolation boundaries for containers.

[0078] Figure 2 The diagram illustrates the logical construction for the second cloud network architecture 200. The disclosed system operates in two key phases. In the first phase, the container undergoes integration testing. The test environment is set up with a request forwarder that is set to run in a permissive mode. Such tests, typical in continuous delivery and containerized systems, execute the functions of the container and trigger calls to the cloud provider. Requests to the cloud provider are logged by the request forwarder. This log is then aggregated to create a cloud service access policy specific to a particular container, as well as a cloud service access policy for the compute node (often a node group) that hosts the container. Policy creation can be fine-tuned through access rules provided as system configuration. For example, such access rules can prevent a node from accessing two specific cloud services. The policy is then packaged with the container into a single deployment package.

[0079] The deployment package consists of the following: container, container-specific policy, and node policy. The architecture orchestration system deploys the node access policy 224 to the cloud IAM 226, while deploying the container and container-specific access policy 222 to the container cluster. The cluster then deploys the container and sends its policy to the request forwarder. Similarly, when a container is removed, access rights (i.e., container access rights in the forwarder and unnecessary parts of the policy granted to the compute node) are also removed.

[0080] The second cloud network architecture 200 may include a test environment 202. The test environment 202 may include one or more computing instances 204. The computing instance 204 may include one or more containers (e.g., container 1 206, container 2 208, and container 3 210). Each container may receive credentials to identify the container on the network. In various examples, the container orchestrator may provide an identity to the container at creation time. The container identity may be stored in a memory of the container.

[0081] As previously addressed Figure 1 As discussed, a process executed in a container of a computing instance 204 may request a cloud service (e.g., cloud service A 228, cloud service B 230, or cloud service C 232). The container may send its container credentials to a request forwarder 214. The request forwarder 214 may act as a proxy between the container and the cloud service. The request forwarder 214 is responsible for obtaining the credentials so that components on the machine can use the instance credentials to call the cloud service, which allows the network architecture to disconnect all of these containers from accessing the credentials. Therefore, these containers do not have the credentials, and now the container must make all calls through the request forwarder 214 because this is the only way to obtain the credentials. The request forwarder 214 may receive a request including the container credentials from the container. The request forwarder 214 may verify the credentials with the container orchestrator in the control plane. The request forwarder 214 may send the container credentials to the container orchestrator and receive back the container identity.

[0082] In the test environment 202, a request forwarder 214 may send a request to a metadata service. The request may include container credentials. The metadata service 212 may use the container credentials to obtain instance credentials. The request forwarder 214 may transmit a request for a cloud service from one or more containers to a request log 216. The request may be stored in the request log 216. The request log 216 data may be stored on a server. An aggregator 220 may aggregate one or more requests and store the aggregated list on a server. The aggregator 220 may also receive one or more access rules 218. The aggregator 220 may generate one or more container access policies 222. The aggregator 220 may generate one or more node access policies 224.

[0083] The production environment 252 may include a computing instance 254. The computing instance 254 may include one or more containers (e.g., container 1 256, container 2 258, and container 3 260). Each container may receive credentials to identify the container on the network. In various examples, the container orchestrator may provide an identity to the container when it is created. The container identity may be stored in a memory for the container. The computing instance 254 may include a request forwarder 274. The request forwarder 274 may act as a proxy between the container and the cloud service. The request forwarder 274 is responsible for obtaining the credentials so that the components on the machine can call the cloud service with the instance credentials, which allows the network architecture to disconnect all of these containers from accessing the credentials. Therefore, these containers do not have the credentials, and now the container must make all calls through the request forwarder 274 because this is the only way to obtain the credentials. The request forwarder 274 may receive a request including the container credentials from the container. The request forwarder 274 may verify the credentials using the container orchestrator in the control plane. The request forwarder 274 may send the container credentials to the container orchestrator and receive back the container identity.

[0084] The computing instance 254 may include a metadata service 262. The request forwarder 274 may send a request to the metadata service 262. The request may include a container credential. The metadata service 262 may use the container credential to obtain the instance credential. The request forwarder 274 may access the container access policy 222. In various embodiments, the container access policy 222 may be stored on the computing instance 254. In a production environment, the request forwarder 274 may receive one or more container access policies 222. The container access policy 222 may be used to determine which cloud services (if any) the container is allowed to use. The request forwarder 274 may use the container access policy 222 to determine the permissions of the container. The request forwarder 274 may request the instance credential from the metadata server 222. The metadata server 262 may send the instance credential information based on the container access policy 222 of the container. The request forwarder 274 may send the request to a cloud service (e.g., cloud service A 228, cloud service B 230, or cloud service C 232). The instance credential may be attached to the request sent to the cloud service.

[0085] Figure 3 is a flow diagram of an example process 300 associated with a technique for automatically configuring minimal cloud service access permissions for a container application. At 302, process 300 can begin by adding a new or modified container to a cloud server infrastructure.

[0086] At 304, the container may enter a test environment. In the test environment, the request forwarder may be set to run in permissive mode. The test environment does not control access, but is used to identify access requirements. Such tests, typical in continuous delivery and containerized systems, exercise the functionality of the container and trigger calls to the cloud provider. The test environment should be as comprehensive as possible, otherwise the test may have gaps and may not capture the request requirements, so access will not be granted.

[0087] The test environment can exist in the cloud. Within the test environment, there can be a baseline policy that provides the maximum allowed access that the system can have. For example, the baseline policy can provide restrictions, such as connections to functions as a service (for example, for security reasons). Therefore, in this case, the test machine will not be provided access to the function as a service. Therefore, if an attempt is made to connect through this system, and other permission policies are in place, the test will fail because the computer used for testing will not have that access, and the test will fail. This is to allow developers to understand what access is not possible.

[0088] At 306, a test result may be received. The test result may determine whether one or more applications running on the container can access one or more cloud services. If the test result is negative, the process does not continue because either the container is corrupted or coded incorrectly, or the baseline policy prohibits access.

[0089] The request to the cloud provider may be recorded by the request forwarder in a request log at 308. The request log may be stored on a server.

[0090] At 310, the request logs are then aggregated to create cloud service access policies specific to a particular container and for the compute nodes (often groups of nodes) hosting the container. This process can be performed through a type of infrastructure orchestration. Policy creation can be fine-tuned through access rules provided as system configuration. For example, such access rules can prevent a node from accessing two specific cloud services. The policy is then packaged with the container into a single deployment package.

[0091] At 312, a deployment package can be generated. The deployment package can include a container, container-specific policies, and node policies.

[0092] At 314 , the infrastructure orchestration module may receive a deployment package.

[0093] The architecture orchestration module can deploy the node access policy to the cloud IAM at 316. The node access policy provides machine access.

[0094] At 318 , the architecture orchestration module may deploy the container and the container-specific access policy is deployed to the container cluster.

[0095] At 320, the container cluster can deploy the container. Here the container goes to the container cluster or container with the policy, and the container itself is deployed to the container and the policy is deployed to the request forwarder. So now, the request forwarder is aware of what access rights the various containers running on the node can use and controls that access, and the cloud IAM now has a policy that allows these computers to exercise that access based on that configuration.

[0096] At 322, the container cluster sends the policy to the request forwarder. Similarly, when a container is removed, the access rights (ie, the container access rights in the forwarder and the unnecessary portion of the policy granted to the compute node) are removed.

[0097] In the example operation, a new container is identified for first use in an application. In order to proceed, two things need to happen. First, the process needs a policy that allows this container to use the object repository, so the node will recognize this container, but not other containers. This allows the container to access the object repository, and the machine on which this container will run must have access to the object repository. Therefore, these two policies are created and packaged with the new container. Now, when the container is deployed and the architecture orchestration unpacks it, the deployable artifact provisioning provides access to the cloud IAM so that the machine and the machine group to which this container will be deployed now have access to the object repository, which they never had before. In addition, when this container is deployed to the container cluster, the request forwarder or any other mechanism that controls such access will know that the container has access to the object repository. Therefore, even though other containers may be running on this machine, these containers do not have access to the object repository, even if the machine technically has access to the object repository.

[0098] A container cluster can be spread across multiple machines or multiple compute instances (e.g., Kubernetes, Docker Swarm, or Openshift). A container orchestrator can be a system that places and manages containers on multiple machines. These machines can be abstracted as workers. These machines can be added or removed by the container orchestrator, and if a machine breaks down, the container orchestrator provides the container to another machine. These machines can have groups (e.g., machine groups), which can be a collection of machines on which this container can run. From the perspective of the container orchestrator, this group of machines can also be called nodes. From the perspective of the cloud infrastructure, they can be called instances. Instances can be virtual machines or bare metal computers.

[0099] Cloud IAM can control access to groups of virtual machines or groups of bare metal machines or a combination of these for a container cluster setup. Cloud IAM controls which principals within that cloud environment have access to what is within the cloud. Machines are typically placed into groups, and those groups of machines are granted access to cloud services. Groups allow for scaling up and down to grant access to groups of machines to allow another machine to take over if one instance cannot handle the load.

[0100] Figure 4 An example deployment diagram 400 is illustrated, which shows an allowable deployment of the disclosed system. The example may assume a workload consisting of six containers, and the following connectivity requirements were identified in a test environment. Table 1 illustrates a container / service or resource diagram. An example service may be Oracle Cloud Infrastructure (OCI), which allows for management and scaling of networks. Another example service may be VMware Configuration Manager (VCM). Resources within a service may be a subnet or a load balancer.

[0101]

[0102] Table 1

[0103] In this example, access rules can be specified by a system administrator to reflect the security requirements of the services. An example access rule may require access to service C / resource X solely from service C / resource Y. Access rules may also require access to service A solely from service D. These rules provide restrictions on the access that can be granted to compute nodes and tune the operation of the system. Based on known communication paths and access control restrictions, the system can identify which containers can be co-located on the same node. This is in Figure 4 This is depicted in the "Allowed Arrangements" graph shown in . Using graph operations, the system can identify groups of containers that can be shared with multiple different nodes. Figure 4 , container 1 402 may be co-located with container 2 404, container 3 406, container 4 408, or container 5 410, but not co-located with container 6 412. Container 2 may be co-located with container 1 402, container 3 406, container 4 408, container 5 410, or container 6 412. Container 3 406 may be co-located with container 1 402, container 2 404, container 4 408, or container 5 410. Container 4 408 may be co-located with container 1 402, container 2 404, container 3 406, or container 6 412. Container 5 may be co-located with container 1 402, container 2 404, or container 3 406. Container 6 may be co-located with container 2 404 or container 4 408.

[0104] Figure 5An example arrangement diagram 500 showing a prohibited arrangement of the disclosed system is illustrated. Figure 5 Follow the instructions specified in Table 1 and Figure 4 One way to do this is to use a graph to capture the forbidden arrangements of containers. This is done in Figure 5 Given a forbidden arrangement, any set of disconnected graph nodes becomes a valid grouping of containers. This is captured in the “allowed groupings” as Figure 4 . It should be noted that container 2 504 is disconnected from each node; therefore, it can be included in any container grouping. Also, it should be noted that there are other possible arrangements that are not shown. The system can only provide strict criteria for container grouping, allowing the container orchestrator to schedule containers based on its own algorithms within these constraints and taking into account other factors. Figure 5 As shown in , container 1 502 is prohibited from being co-located with container 6 512. Container 2 504 is not prohibited from being co-located with any other container. Container 6 512 is prohibited from being co-located with container 1 502, container 3 506, or container 5 510. Container 3 506 is prohibited from being co-located with container 6 512. Container 5 510 is prohibited from being co-located with container 6 512 and container 4 508. Container 4 508 is prohibited from being co-located with container 5 510.

[0105] From the “Allowed Grouping” example above, the access requirements of the node groups are identified, which represent the union of the access requirements of the containers, and can be scheduled as shown in Table 2:

[0106]

[0107] Table 2

[0108] Figure 6 An example diagram 600 of allowed groupings is illustrated. Such groupings follow the specified access rules. Moreover, such groupings provide a natural separation of containers from the rules. The access requirements of individual containers as well as node groups are captured in corresponding policies and packaged with the corresponding containers. Cloud orchestration systems (such as Terraform) can be used to automatically deploy policies to cloud IAM and perform any required node groupings using mechanisms specific to the particular cloud infrastructure. If the system is operating in a mode where compute node policies are not set, the system can check existing node groups, identify node groups that match the containers, and then report insufficient or excessive permissions.

[0109] Figure 6Node group 1 602 and node group 2 604 are illustrated. Node group 1 602 may include container 2 608, container 4 612, and container 6 616. Node group 2 may include container 1 606, container 3 610, container 5 614, and container 2 608.

[0110] The allowed group graph 600 is from an implementation perspective. The system can analyze graph 600 to determine allowed placements. For example, a first group of machines can host containers 2, 6, and 4, while a second group of machines can host containers 1, 3, 5, and 2. As depicted, container 2 can be hosted in machines in both group 1 and group 2, which can be useful for performance reasons. For example, there may be excess capacity in node group 2, and container 2 can be placed there. This is just one possibility.

[0111] In the example, each container may get its own node group. This also works, but it is not optimal or helpful. Since the system knows that this is an allowed grouping of containers, the system can now create node groups; can schedule containers within these node groups; can identify a combined policy for each group because the system knows what the specific needs of the container are; and can assume that the nodes themselves do not require any access.

[0112] But in general, the combined needs of a group of machines are just the needs of all the containers on that machine. So node group 1 can access service BDC and resource X node group 2 can access service ABC resource Y. This generates policy. By identifying the needs of the containers, the system creates logical isolation within the application that adheres to those rules. Logical isolation of the application can be created by placing containers in node groups and those containers within that node group, just as the security engineer does when reviewing with the team. The system can infer the logical separation of the environment through completely different mechanisms from those rules it wants to implement. And these rules will be preserved in the event that, for example, the system keeps adding more containers with other access needs, etc.

[0113] There can be situations where this cannot be solved graphically; this is a situation where a container violates some of these rules. If the system separates access to service C resource X from service resource Y, then the system will have containers that access both resources in the service. This problem cannot be solved because both service resources cannot be accessed at the same time, and the system will fail. It will fail in the aggregation step, which can be beneficial. To do this, the system will determine that it cannot actually proceed because the designer has created a container that violates the rules that the system has established.

[0114] Figure 7is a flow chart of an example process 700 associated with a technique for automatically configuring minimal cloud service access permissions for a container application. In some embodiments, Figure 7 One or more process blocks of Fig.12 Additionally or alternatively, Figure 7 One or more process blocks of the device 1200 may be performed by one or more components of the device 1200, such as the processing unit 1204, the storage subsystem 1218, the communication subsystem 1224, the input / output subsystem 1208, and the bus subsystem 1202. The processing unit 1204 may include sub-processing units 1232, 1234. The storage subsystem 1218 may include a system memory 1210. The system memory 120 may include application programs 1212, program data 1214, and an operating system 1216. The storage subsystem 1218 may include a computer-readable storage medium reader 1220 and a computer-readable storage medium 1222.

[0115] like Figure 7 As shown in , process 700 may include receiving one or more requests for accessing one or more cloud services (block 710). For example, a computer system may receive one or more requests for accessing one or more cloud services, as described above. The requests may be received from one or more of the same or different senders.

[0116] like Figure 7 As further shown in FIG. 7 , process 700 may include storing one or more requests in a request log (block 720). For example, the computer system may store one or more requests in a request log, as described above.

[0117] like Figure 7 As further shown in FIG. 7 , process 700 may include receiving one or more access rules applicable to cloud service access rights (block 730 ). For example, a computer system may receive one or more access rules applicable to cloud service access rights, as described above.

[0118] like Figure 7 As further shown in FIG. 7 , process 700 may include aggregating one or more requests of a request log to determine access requirements for a container that is configured to store one or more applications (block 740). For example, a computer system may aggregate one or more requests of a request log to determine access requirements for a container that is configured to store one or more applications, as described above.

[0119] like Figure 7As further shown in FIG. 7 , process 700 may include generating a container access policy that defines access to the container and one or more cloud services, the container access policy based at least in part on the aggregated one or more requests and the one or more access rules (block 750). For example, the computer system may generate a container access policy that defines access to the container and one or more cloud services, the container access policy based at least in part on the aggregated one or more requests and the one or more access rules, as described above.

[0120] like Figure 7 As further shown, process 700 may include storing the container access policy in a memory (block 760). For example, the computer system may store the container access policy in a memory, as described above.

[0121] like Figure 7 As further shown in , process 700 may include sending the container access policy to a request forwarder of a computing instance in the production environment, which accesses the container access policy to grant the container access to one or more cloud services (block 770). For example, the computer system may send the container access policy to a request forwarder of a computing instance in the production environment, which accesses the container access policy to grant the container access to one or more cloud services, as described above.

[0122] Process 700 may include additional implementations, such as any single implementation or any combination of implementations described below and / or in combination with one or more other processes described elsewhere herein.

[0123] Process 700 can operate in two modes. In the first mode, process 700 controls access to cloud services. In the first node, the access rights of the container and the access rights of the node are dynamically set by the system. All access requirements of the containers and nodes used by the cluster are automatically configured. The system can be configured to adjust how to grant node access rights. The simplest case is that all nodes are equal and any container can be scheduled on any node. In this case, the access permission required by each node is equivalent to the combined access rights of all containers. However, application designers usually separate containers so that attacks on one container (i.e., a container with a higher degree of exposure or a lower degree of trust) do not expose other containers in the same node. The process for separating containers can be a manual process and depends on the expert's understanding of the system and security constraints. In the disclosed system, the requirement to decide how to separate individual containers can be eliminated. The system can be configured with general rules about how access rights should be granted (for example, a system must not access two specific services or resources). After formulating such rules, the system automatically partitions the cluster into node groups with different access rights and assigns containers to the correct nodes with sufficient access rights. At the same time, it retains the flexibility to assign containers that can operate in multiple groups to any node in the cluster. While this mechanism has its benefits, some users may strongly prefer to manually configure access rights for nodes in the system or may be reluctant to delegate any IAM access management to an automated system.

[0124] In a first embodiment, process 700 includes generating a node access policy that specifies an access policy for granting a group of compute instances combined access rights to one or more containers on a node, and process 700 includes storing the container access policy in a memory.

[0125] In a second embodiment, either alone or in combination with the first embodiment, process 700 includes granting access permissions equivalent to the combined access rights of one or more containers assigned to the node.

[0126] In a third embodiment, alone or in combination with one or more of the first and second embodiments, process 700 includes partitioning a computing instance having multiple computing instances into node groups, each node having different access rights, and assigning one or more containers to nodes with sufficient access rights based at least in part on a node access policy.

[0127] In the second mode, process 700 does not control the node's access to the cloud service. In a fourth embodiment, either alone or in combination with one or more of the first to third embodiments, access is predetermined and container access within each node is dynamically configured. When a user is unwilling to delegate access management to an automated system, access to a node can be preconfigured and known to the system. Here, only the container access rights granted within the node are dynamically configured. The system can then place containers with specific access requirements to nodes with sufficient access rights when needed. Because the access rights granted to computing nodes are predefined and immutable by the system, it may happen that a container requires access rights that cannot be allowed by any node in the cluster. This can be detected during the testing phase. If the forwarder fails to issue a request, the failure is recorded, indicating that the permissions of the computing instance must be changed. There are multiple ways to determine whether the forwarder's request has failed. In a test environment, assuming that the test instance and the production instance have exactly the same permissions, the failure of the test itself is sufficient proof.

[0128] In a fifth embodiment, alone or in combination with one or more of the first to fourth embodiments, process 700 includes testing access requirements of the cloud system, detecting a failure of a particular application to access one or more cloud services based at least in part on entries in a request log, and changing permissions of a computing instance to fix the failure. In some examples, the entries in the request log are previously stored requests. For example, the request log can be configured to store multiple requests. And, each request in the request log can be considered an entry.

[0129] In a sixth embodiment, either alone or in combination with one or more of the first to fifth embodiments, process 700 includes setting a request forwarder for each container type in a production environment to a permissive mode that grants one or more applications stored in the container access to one or more cloud services, receiving one or more requests from the request forwarder, and switching the request forwarder to a restricted mode based on a number of the one or more requests exceeding a threshold requirement, the restricted mode granting one or more applications access to the one or more cloud services based in part on a container access policy.

[0130] Although Figure 7 Example blocks of process 700 are shown, but in some implementations, process 700 may include Figure 7 The blocks depicted in the process 700 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the process 700. Additionally or alternatively, two or more blocks of the process 700 may be executed in parallel.

[0131] III. Centralized Request Forwarder

[0132] A single centralized node, or a single set of request forwarders supporting multiple nodes, or any combination of nodes are allowed. The disclosed system can support all of these options by managing a container policy with a forwarder assigned to the container and a node policy for the node hosting the forwarder, regardless of where the node is located. Similarly, the system can support a centralized cloud version of the request forwarder by granting access to the entity based on the combined container requirements.

[0133] There can be multiple ways to locate the request forwarder. In one example, the request forwarder can be centrally located. In another example, the request forwarder can be external to the machine as long as there is a mechanism to feed the policy and identify the container. In some examples, the request forwarder may not exist in the production model. Finally, the container policy can obtain the container policy in the production environment. This can be done if the client believes that the testing is not comprehensive enough or there is no test environment. In this case, the technology can be implemented only in the production environment that initially has a permissive model, and when additional requests are received, it learns the access requirements. When the access requirements have been identified, it has enough information to make it aware of all access requirements and can begin enforcing them.

[0134] In one example, at the last number of requests, there are no new requests. Different thresholds can be configured to indicate that sufficient access has been achieved and identified. The system then begins enforcing access. The system may start out running with an overly permissive policy, but eventually the policy becomes more restrictive. This is better than running in permissive mode forever.

[0135] If a container is removed, access rights can be removed. If a new container is provisioned for the system, access rights may not be available, and the process will understand the life cycle of the container and remove previously established rules (for example, if a new version of the container is deployed).

[0136] The cloud network architecture may include multiple computing instances. One or more computing instances may store various containers. Another separate computing instance may include a request forwarder, a metadata service, and one or more policies. The cloud network architecture may include various cloud services (e.g., cloud service A, cloud service B, cloud service C). The cloud network architecture may also include a container orchestrator. Request forwarders may be centralized for multiple nodes, or each node may have its own request forwarder. Centralized / dedicated request forwarder nodes mean that different nodes (which may contain multiple containers) may forward their requests to cloud services via centralized nodes. Instance credentials do not need to be stored on each node, only on the node where the request forwarder exists. The request forwarder does not necessarily need to be on the same node as the container it supports.

[0137] Both architectures have advantages and disadvantages. With regard to the centralized / dedicated request forwarder, the resources of a node can be dedicated to performing only the duties of the request forwarder, while other nodes can focus on using their resources to perform their tasks. In addition to this, instance credentials do not need to be stored on each node, only on the centralized instance. However, the disadvantage of this approach is that the centralized request forwarder acts as a single point of failure. If it goes down, then all containers cannot make requests to the cloud service. As for the case where there is a request forwarder on each node, the creation and operation of network rules / architectures will become simpler. Another advantage of per-node forwarders is that each node has its own request forwarder, resulting in each node processing only the workload of its containers. One disadvantage of this design is that the credentials of each node must be maintained to access the cloud service. This makes the problem of correct key rotation and revocation more difficult, the extent of which depends on the number of nodes involved. A hybrid approach can involve using a subset of cluster nodes to host request forwarders.

[0138] In various embodiments, request forwarders do not exist in production. The system can also be useful in situations where there are no request forwarders in production. In this case, if the container has all the access rights that the node has, then there is no need to set policies for individual containers. However, the access rights of the node will be limited to the union of all containers on the node. While this does not limit container access to the minimum, it still automatically limits node access, which is a major advantage over manually configuring access.

[0139] In various embodiments, container policies can be captured in a production environment. While the system is most likely to be used in two phases, where the data needed to construct the policy is captured in a trusted test environment and then deployed to the production system along with the container, an alternative mechanism is possible only in a production environment.

[0140] This mechanism involves switching the request forwarder's permissive / restrictive mode individually for each container type in production. When a container is first deployed, the request forwarder sends all requests to the cloud service while also generating a log of the requests. After sufficient data has been collected, it switches to restricted mode for that specific container. This implementation does not provide the same level of security as allowing all access to the cloud service for a period of time. However, it does reduce system operating costs and may be sufficient for some users, especially when container turnover is low. The decision when to obtain enough data to switch modes can be done manually, based on time, or by analyzing the number of new types of requests being forwarded. For example, if all requests sent to the forwarder do not contain new requests given a specified number of requests, then the collected data can be considered sufficient. Access to nodes can be managed in a similar manner, starting with excessive access (within reasonable boundaries set by the administrator) and then reducing to the specific permissions required for individual containers, provided that the access requirements of all containers on the node are fully established.

[0141] IV. Infrastructure as a Service (IAAS)

[0142] As mentioned above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, IaaS providers can also provide various services to accompany these infrastructure components (e.g., billing, monitoring, logging, security, load balancing and clustering, etc.). Therefore, since these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain application availability and performance.

[0143] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet, and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create a virtual machine (VM), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software into the VM. Customers can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application problems, monitoring performance, managing disaster recovery, and more.

[0144] In most cases, the cloud computing model will require the involvement of a cloud provider. A cloud provider may, but need not, specialize in providing (e.g., provisioning, renting, selling) third-party IaaS services. An entity may also choose to deploy a private cloud, thereby becoming its own infrastructure service provider.

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

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

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

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

[0149] In some cases, continuous deployment techniques can be employed to enable infrastructure code to be deployed across various virtual computing environments. In addition, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is expected to be deployed to one or more but typically many different production environments (e.g., across various different geographic locations, sometimes across the world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned using a provisioning tool, and / or code can be deployed using a deployment tool once the infrastructure is provisioned.

[0150] Figure 8 8 is a block diagram 800 illustrating an example mode of an IaaS architecture according to at least one embodiment. A service operator 802 can be communicatively coupled to a secure host lease 804 that can include a virtual cloud network (VCN) 806 and a secure host subnet 808. In some examples, the service operator 802 can use one or more client computing devices (the client computing device can be a portable handheld device (e.g., Cellular phone, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head mounted display)), running software (such as Microsoft Windows ) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and supports Internet, email, short message service (SMS), Alternatively, the client computing device may be a general-purpose personal computer, including, for example, a computer running various versions of Microsoft Apple The client computing device may be a personal computer and / or laptop computer running various commercially available or any workstation computer running any operating system such as UNIX or UNIX-like operating systems, including but not limited to various GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., with or without gesture input device), and / or a personal messaging device capable of communicating over a network that can access VCN 806 and / or the Internet.

[0151] The VCN 806 may include a local peer gateway (LPG) 810, which may be communicatively coupled to a secure shell (SSH) VCN 812 via the LPG 810 contained in an SSH VCN 812. The SSH VCN 812 may include an SSH subnet 814, and the SSH VCN 812 may be communicatively coupled to a control plane VCN 816 via the LPG 810 contained in a control plane VCN 816. Furthermore, the SSH VCN 812 may be communicatively coupled to a data plane VCN 818 via the LPG 810. The control plane VCN 816 and the data plane VCN 818 may be contained in a service lease 819, which may be owned and / or operated by an IaaS provider.

[0152] The control plane VCN 816 may include a control plane demilitarized zone (DMZ) layer 820 that acts as a perimeter network (e.g., a portion of a company network between a company's internal network and an external network). DMZ-based servers can assume limited liability and help control security violations. In addition, the DMZ layer 820 may include one or more load balancer (LB) subnets 822, a control plane application layer 824 that may include (one or more) application (app) subnets 826, and a control plane data layer 828 that may include (one or more) database (DB) subnets 830 (e.g., (one or more) front-end DB subnets and / or (one or more) back-end DB subnets). The LB subnet(s) 822 included in the control plane DMZ layer 820 may be communicatively coupled to the application subnet(s) 826 included in the control plane application layer 824 and the Internet gateway 834 that may be included in the control plane VCN 816, and the application subnet(s) 826 may be communicatively coupled to the DB subnet(s) 830 included in the control plane data layer 828 as well as the service gateway 836 and the network address translation (NAT) gateway 838. The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0153] The control plane VCN 816 may include a data plane mirror application layer 840, which may include application subnet(s) 826. The application subnet(s) 826 included in the data plane mirror application layer 840 may include a virtual network interface controller (VNIC) 842 that may execute a compute instance 844. The compute instance 844 may communicatively couple the application subnet(s) 826 of the data plane mirror application layer 840 to the application subnet(s) 826 that may be included in the data plane application layer 846.

[0154] The data plane VCN 818 may include a data plane application layer 846, a data plane DMZ layer 848, and a data plane data layer 850. The data plane DMZ layer 848 may include (one or more) LB subnets 822, which may be communicatively coupled to (one or more) application subnets 826 of the data plane application layer 846 and an Internet gateway 834 of the data plane VCN 818. The (one or more) application subnets 826 may be communicatively coupled to a service gateway 836 of the data plane VCN 818 and a NAT gateway 838 of the data plane VCN 818. The data plane data layer 850 may also include (one or more) DB subnets 830, which may be communicatively coupled to (one or more) application subnets 826 of the data plane application layer 846.

[0155] The internet gateway 834 of the control plane VCN 816 and the data plane VCN 818 may be communicatively coupled to a metadata management service 852, which may be communicatively coupled to a public Internet 854. The public Internet 854 may be communicatively coupled to a NAT gateway 838 of the control plane VCN 816 and the data plane VCN 818. The service gateway 836 of the control plane VCN 816 and the data plane VCN 818 may be communicatively coupled to a cloud service 856.

[0156] In some examples, a service gateway 836 of a control plane VCN 816 or a data plane VCN 818 can make application programming interface (API) calls to cloud services 856 without going through the public internet 854. API calls from a service gateway 836 to a cloud service 856 can be one-way: the service gateway 836 can make API calls to the cloud service 856, and the cloud service 856 can send requested data to the service gateway 836. However, the cloud service 856 may not initiate the API call to the service gateway 836.

[0157] In some examples, secure host lease 804 can be directly connected to service lease 819, which can otherwise be isolated. Secure host subnet 808 can communicate with SSH subnet 814 through LPG 810, which can enable two-way communication on otherwise isolated systems. Connecting secure host subnet 808 to SSH subnet 814 can enable secure host subnet 808 to access other entities within service lease 819.

[0158] The control plane VCN 816 may allow a user of the service lease 819 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 816 may be deployed or otherwise used in the data plane VCN 818. In some examples, the control plane VCN 816 may be isolated from the data plane VCN 818, and the data plane mirror application layer 840 of the control plane VCN 816 may communicate with the data plane application layer 846 of the data plane VCN 818 via the VNIC 842, which may be included in the data plane mirror application layer 840 and the data plane application layer 846.

[0159] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet 854 which may transmit the request to the metadata management service 852. The metadata management service 852 may transmit the request to the control plane VCN 816 through the internet gateway 834. The request may be received by the LB subnet(s) 822 contained in the control plane DMZ layer 820. The LB subnet(s) 822 may determine that the request is valid, and in response to the determination, the LB subnet(s) 822 may transmit the request to the application subnet(s) 826 contained in the control plane application layer 824. If the request is validated and a call to the public internet 854 is required, the call to the public internet 854 may be transmitted to the NAT gateway 838 which may make the call to the public internet 854. The storage that the request may desire to be stored may be stored in the DB subnet(s) 830.

[0160] In some examples, data plane mirror application layer 840 may facilitate direct communications between control plane VCN 816 and data plane VCN 818. For example, it may be desirable to apply changes, updates, or other appropriate modifications to the configuration of resources contained in data plane VCN 818. Control plane VCN 816, via VNIC 842, may communicate directly with the resources contained in data plane VCN 818 and may thereby perform changes, updates, or other appropriate modifications to the configuration of such resources.

[0161] In some embodiments, the control plane VCN 816 and the data plane VCN 818 may be included in the service lease 819. In this case, the user or customer of the system may not own or operate the control plane VCN 816 or the data plane VCN 818. Alternatively, the IaaS provider may own or operate the control plane VCN 816 and the data plane VCN 818, both of which may be included in the service lease 819. This embodiment may enable the isolation of networks that may prevent a user or customer from interacting with the resources of other users or other customers. In addition, this embodiment may allow users or customers of the system to store databases privately without relying on the public Internet 854, which may not have the desired level of security, for storage.

[0162] In other embodiments, the LB subnet(s) 822 contained in the control plane VCN 816 can be configured to receive signals from the service gateway 836. In this embodiment, the control plane VCN 816 and the data plane VCN 818 can be configured to be called by customers of the IaaS provider without calling the public Internet 854. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on the service lease 819, which can be isolated from the public Internet 854.

[0163] Fig. 9 900 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 902 (e.g., Figure 8 The service operator 802) can be communicatively coupled to the secure host lease 904 (e.g., Figure 8 The secure host lease 804 may include a virtual cloud network (VCN) 906 (e.g., Figure 8 VCN 806) and secure host subnet 908 (e.g., Figure 8 The VCN 906 may include a local peer gateway (LPG) 910 (e.g., Figure 8 LPG 810), the VCN 906 may be connected to the VCN 912 (e.g., Figure 8 LPG 810 in SSH VCN 812 of the present invention is communicatively coupled to SSH VCN 912. SSH VCN 912 may include SSH subnet 914 (e.g., Figure 8 SSH subnet 814), and SSH VCN 912 can be accessed via control plane VCN 916 (e.g., Figure 8The LPG 910 in the control plane VCN 816 of the embodiment of the present invention is communicatively coupled to the control plane VCN 916. The control plane VCN 916 can be included in the service lease 919 (e.g., Figure 8 service lease 819), and the data plane VCN 918 (e.g., Figure 8 The data plane VCN 818) may be contained in a customer lease 921 which may be owned or operated by a user or customer of the system.

[0164] The control plane VCN 916 may include a control plane DMZ layer 920 (e.g., Figure 8 The control plane DMZ layer 820 may include (one or more) LB subnets 922 (e.g., Figure 8 (one or more) LB subnets 822), may include (one or more) application subnets 926 (e.g., Figure 8 (one or more) application subnets 826) of the control plane application layer 924 (e.g., Figure 8 The control plane application layer 824 of FIG. 1 may include (one or more) database (DB) subnets 930 (e.g., similar to Figure 8 (one or more) DB subnets 830) of the control plane data layer 928 (e.g., Figure 8 The LB subnet(s) 922 contained in the control plane DMZ layer 920 may be communicatively coupled to the application subnet(s) 926 contained in the control plane application layer 924 and the internet gateway 934 (e.g., Figure 8 834), and the application subnet(s) 926 may be communicatively coupled to the DB subnet(s) 930 and the service gateway 936 (e.g., Figure 8 Serving gateway) and network address translation (NAT) gateway 938 (e.g., Figure 8 The control plane VCN 916 may include a service gateway 936 and a NAT gateway 938.

[0165] The control plane VCN 916 may include a data plane mirror application layer 940 (e.g., Figure 8 The data plane image application layer 840). The application subnet(s) 926 included in the data plane image application layer 940 may include a computing instance 944 (e.g., similar to Figure 8The compute instance 944 may facilitate the application subnet(s) 926 of the data plane mirroring application layer 940 and the application subnets 926 that may be included in the data plane application layer 946 (e.g., Figure 8 Communication between (one or more) application subnets 926 in the data plane application layer 846) via the VNIC 942 contained in the data plane mirror application layer 940 and the VNIC 942 contained in the data plane application layer 946.

[0166] The Internet gateway 934 included in the control plane VCN 916 can be communicatively coupled to the metadata management service 952 (e.g., Figure 8 , which can be communicatively coupled to a public Internet 954 (e.g., Figure 8 The public Internet 954 can be communicatively coupled to a NAT gateway 938 included in the control plane VCN 916. The service gateway 936 included in the control plane VCN 916 can be communicatively coupled to a cloud service 956 (e.g., Figure 8 Cloud service 856).

[0167] In some examples, the data plane VCN 918 may be contained in a customer lease 921. In this case, the IaaS provider may provide a control plane VCN 916 for each customer, and the IaaS provider may provision each customer with a unique compute instance 944 contained in a service lease 919. Each compute instance 944 may allow communication between the control plane VCN 916 contained in the service lease 919 and the data plane VCN 918 contained in the customer lease 921. The compute instance 944 may allow resources provisioned in the control plane VCN 916 contained in the service lease 919 to be deployed or otherwise used in the data plane VCN 918 contained in the customer lease 921.

[0168] In other examples, a customer of the IaaS provider may have a database that exists in the customer lease 921. In this example, the control plane VCN 916 may include a data plane mirror application layer 940, which may include (one or more) application subnets 926. The data plane mirror application layer 940 may reside in the data plane VCN 918, but the data plane mirror application layer 940 may not be in the data plane VCN 918. In other words, the data plane mirror application layer 940 may access the customer lease 921, but the data plane mirror application layer 940 may not exist in the data plane VCN 918 or be owned or operated by the customer of the IaaS provider. The data plane mirror application layer 940 may be configured to make calls to the data plane VCN 918, but may not be configured to make calls to any entity contained in the control plane VCN 916. A customer may desire to deploy or otherwise use resources provisioned in control plane VCN 916 in data plane VCN 918, and data plane mirror application layer 940 may facilitate the customer's desired deployment or other use of resources.

[0169] In some embodiments, a customer of an IaaS provider may apply filters to the data plane VCN 918. In this embodiment, the customer may determine what the data plane VCN 918 may access, and the customer may restrict access to the public Internet 954 from the data plane VCN 918. The IaaS provider may not apply filters or otherwise control access to any external network or database by the data plane VCN 918. The customer applying filters and controls to the data plane VCN 918 contained in the customer lease 921 may help isolate the data plane VCN 918 from other customers and the public Internet 954.

[0170] In some embodiments, cloud services 956 may be called by service gateway 936 to access services that may not exist on public Internet 954, control plane VCN 916, or data plane VCN 918. The connection between cloud services 956 and control plane VCN 916 or data plane VCN 918 may not be real-time or continuous. Cloud services 956 may exist on different networks owned or operated by IaaS providers. Cloud services 956 may be configured to receive calls from service gateway 936 and may be configured not to receive calls from public Internet 954. Some cloud services 956 may be isolated from other cloud services 956, and control plane VCN 916 may be isolated from cloud services 956 that may not be in the same region as control plane VCN 916. For example, control plane VCN 916 may be located in "Region 1", and cloud service "Deployment 6" may be located in Region 1 and "Region 2". If a service gateway 936 contained in a control plane VCN 916 located in region 1 makes a call to deployment 6, the call may be transmitted to deployment 6 in region 1. In this example, control plane VCN 916 or deployment 6 in region 1 may not be communicatively coupled or otherwise in communication with deployment 6 in region 2.

[0171] Fig.10 1 is a block diagram 1000 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 1002 (e.g., Figure 8 The service operator 802 of FIG. 1002 may be communicatively coupled to the secure host lease 1004 (eg, Figure 8 The secure host lease 1004 may include a virtual cloud network (VCN) 1006 (e.g., Figure 8 VCN 806) and secure host subnet 1008 (e.g., Figure 8 VCN 1006 may include LPG 1010 (e.g., Figure 8 LPG 810), the VCN 1006 can be connected to the SSH VCN 1012 (e.g., Figure 8 The LPG 1010 in the SSH VCN 812 is communicatively coupled to the SSH VCN 1012. The SSH VCN 1012 may include an SSH subnet 1014 (e.g., Figure 8 SSH subnet 814), and SSH VCN 1012 can be accessed via control plane VCN 1016 (e.g., Figure 8 LPG 1010 in control plane VCN 816 of the present invention is communicatively coupled to control plane VCN 1016 and communicates with control plane VCN 1016 via LPG 1010 included in data plane VCN 1018 (e.g., Figure 8The control plane VCN 1016 and the data plane VCN 1018 may be included in a service lease 1019 (e.g., Figure 8 Service lease 819).

[0172] The control plane VCN 1016 may include a load balancer (LB) subnet 1022 (e.g., Figure 8 LB subnet(s) 822) of the control plane DMZ layer 1020 (e.g., Figure 8 The control plane DMZ layer 820 may include (one or more) application subnets 1026 (e.g., similar to Figure 8 (one or more) application subnets 1026) of the control plane application layer 1024 (e.g., Figure 8 A control plane application layer 824), a control plane data layer 1028 (e.g., Figure 8 The LB subnet(s) 1022 contained in the control plane DMZ layer 1020 may be communicatively coupled to the application subnet(s) 1026 contained in the control plane application layer 1024 and the internet gateway 1034 (e.g., Figure 8 834), and the application subnet(s) 1026 may be communicatively coupled to the DB subnet(s) 1030 and the service gateway 1036 (e.g., Figure 8 ) and a network address translation (NAT) gateway 1038 (e.g., Figure 8 NAT gateway 838). The control plane VCN 1016 may include a service gateway 1036 and a NAT gateway 1038.

[0173] The data plane VCN 1018 may include a data plane application layer 1046 (e.g., Figure 8 Data plane application layer 846), data plane DMZ layer 1048 (e.g., Figure 8 Data plane DMZ layer 848), and data plane data layer 1050 (e.g., Figure 8The data plane DMZ layer 1048 may include (one or more) trusted application subnets 1060 and (one or more) untrusted application subnets 1062 that may be communicatively coupled to the data plane application layer 1046 and (one or more) LB subnets 1022 of the Internet gateway 1034 included in the data plane VCN 1018. The (one or more) trusted application subnets 1060 may be communicatively coupled to the service gateway 1036 included in the data plane VCN 1018, the NAT gateway 1038 included in the data plane VCN 1018, and (one or more) DB subnets 1030 included in the data plane data layer 1050. The (one or more) untrusted application subnets 1062 may be communicatively coupled to the service gateway 1036 included in the data plane VCN 1018 and (one or more) DB subnets 1030 included in the data plane data layer 1050. Data plane data layer 1050 may include DB subnet(s) 1030 that may be communicatively coupled to service gateway 1036 included in data plane VCN 1018 .

[0174] The untrusted application subnet(s) 1062 may include one or more primary VNICs 1064(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1066(1)-(N). Each tenant VM 1066(1)-(N) may be communicatively coupled to a respective application subnet 1067(1)-(N) that may be contained in a respective container egress VCN 1068(1)-(N), which may be contained in a respective customer tenancy 1070(1)-(N). Respective secondary VNICs 1072(1)-(N) may facilitate communications between the untrusted application subnet(s) 1062 contained in the data plane VCN 1018 and the application subnets contained in the container egress VCNs 1068(1)-(N). Each container egress VCN 1068(1)-(N) may include a NAT gateway 1038 that may be communicatively coupled to the public Internet 1054 (e.g., Figure 8 of the public Internet 854).

[0175] The Internet gateway 1034 included in the control plane VCN 1016 and included in the data plane VCN 1018 can be communicatively coupled to the metadata management service 1052 (e.g., Figure 8The metadata management service 1052 may be communicatively coupled to the public Internet 1054. The public Internet 1054 may be communicatively coupled to the NAT gateway 1038 included in the control plane VCN 1016 and included in the data plane VCN 1018. The service gateway 1036 included in the control plane VCN 1016 and included in the data plane VCN 1018 may be communicatively coupled to the cloud service 1056.

[0176] In some embodiments, the data plane VCN 1018 can be integrated with the customer lease 1070. In some cases, such integration may be useful or desirable for the customers of the IaaS provider, such as where support may be desired when executing code. A customer may provide code to run that may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response to this, the IaaS provider may determine whether to run the code given to the IaaS provider by the customer.

[0177] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request functionality attached to a data plane layer application 1046. Code running the functionality may be executed in a VM 1066(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 1018. Each VM 1066(1)-(N) may be connected to a customer tenancy 1070. The corresponding container 1071(1)-(N) contained in the VM 1066(1)-(N) may be configured to run the code. In this case, there may be double isolation (e.g., the container 1071(1)-(N) runs the code, where the container 1071(1)-(N) may be contained at least in the VM 1066(1)-(N) contained in the (one or more) untrusted application subnets 1062), which may help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or damaging the network of a different customer. Containers 1071(1)-(N) may be communicatively coupled to customer lease 1070 and may be configured to transmit or receive data from customer lease 1070. Containers 1071(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 1018. After running the code, the IaaS provider may terminate or otherwise dispose of containers 1071(1)-(N).

[0178] In some embodiments, the trusted application subnet(s) 1060 may run code that may be owned or operated by the IaaS provider. In this embodiment, the trusted application subnet(s) 1060 may be communicatively coupled to the DB subnet(s) 1030 and configured to perform CRUD operations in the DB subnet(s) 1030. The untrusted application subnet(s) 1062 may be communicatively coupled to the DB subnet(s) 1030, but in this embodiment, the untrusted application subnet(s) may be configured to perform read operations in the DB subnet(s) 1030. The containers 1071(1)-(N) that may be included in each customer's VM 1066(1)-(N) and that may run code from the customer may not be communicatively coupled to the DB subnet(s) 1030.

[0179] In other embodiments, the control plane VCN 1016 and the data plane VCN 1018 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 1016 and the data plane VCN 1018. However, communication may occur indirectly through at least one method. The LPG 1010 may be established by an IaaS provider, which may facilitate communication between the control plane VCN 1016 and the data plane VCN 1018. In another example, the control plane VCN 1016 or the data plane VCN 1018 may make a call to the cloud service 1056 via the service gateway 1036. For example, the call from the control plane VCN 1016 to the cloud service 1056 may include a request for a service that can communicate with the data plane VCN 1018.

[0180] Fig.11 1 is a block diagram 1100 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 1102 (e.g., Figure 8 The service operator 802) can be communicatively coupled to the secure host lease 1104 (e.g., Figure 8 The secure host lease 1104 may include a virtual cloud network (VCN) 1106 (e.g., Figure 8 VCN 806) and secure host subnet 1108 (e.g., Figure 8 VCN 1106 may include LPG 1110 (e.g., Figure 8 810), the VCN 1106 may be connected to the LPG 810 via the SSH VCN 1112 (e.g., Figure 8LPG 1110 in SSH VCN 812 is communicatively coupled to SSH VCN 1112. SSH VCN 1112 may include SSH subnet 1114 (e.g., Figure 8 SSH subnet 814), and SSH VCN 1112 can be accessed via control plane VCN 1116 (e.g., Figure 8 LPG 1110 in control plane VCN 816 of the present invention is communicatively coupled to control plane VCN 1116 and communicates with control plane VCN 1116 via LPG 1110 included in data plane VCN 1118 (e.g., Figure 8 The control plane VCN 1116 and the data plane VCN 1118 may be included in a service lease 1119 (e.g., Figure 8 Service lease 819).

[0181] The control plane VCN 1116 may include (one or more) LB subnets 1122 (e.g., Figure 8 LB subnet(s) 822) of the control plane DMZ layer 1120 (e.g., Figure 8 The control plane DMZ layer 820 may include (one or more) application subnets 1126 (e.g., Figure 8 (one or more) application subnets 826) of the control plane application layer 1124 (e.g., Figure 8 The control plane application layer 824 of FIG. 110 may include (one or more) DB subnets 1130 (e.g., Figure 8 (one or more) DB subnet 830) of the control plane data layer 1128 (e.g., Figure 8 The LB subnet(s) 1122 contained in the control plane DMZ layer 1120 may be communicatively coupled to the application subnet(s) 1126 contained in the control plane application layer 1124 and the internet gateway 1134 (e.g., Figure 8 834), and the application subnet(s) 1126 may be communicatively coupled to the DB subnet(s) 1130 and the service gateway 1136 (e.g., Figure 8 ) and a network address translation (NAT) gateway 1138 (e.g., Figure 8 NAT gateway 838). The control plane VCN 1116 may include a service gateway 1136 and a NAT gateway 1138.

[0182] The data plane VCN 1118 may include a data plane application layer 1146 (e.g., Figure 8 Data plane application layer 846), data plane DMZ layer 1148 (e.g., Figure 8 Data plane DMZ layer 848), and data plane data layer 1150 (e.g., Figure 8 The data plane DMZ layer 1148 may include (one or more) trusted application subnets 1160 (e.g., Figure 8 (one or more) trusted application subnets 860) and (one or more) untrusted application subnets 1162 (e.g., Figure 8 The trusted application subnet(s) 1160 may be communicatively coupled to the service gateway 1136 contained in the data plane VCN 1118, the NAT gateway 1138 contained in the data plane VCN 1118, and the DB subnet(s) 1130 contained in the data plane data layer 1150. The untrusted application subnet(s) 1162 may be communicatively coupled to the service gateway 1136 contained in the data plane VCN 1118 and the DB subnet(s) 1130 contained in the data plane data layer 1150. The data plane data layer 1150 may include the DB subnet(s) 1130 that may be communicatively coupled to the service gateway 1136 contained in the data plane VCN 1118.

[0183] The untrusted application subnet(s) 1162 may include primary VNICs 1164(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1166(1)-(N) residing within the untrusted application subnet(s) 1162. Each tenant VM 1166(1)-(N) may run code in a respective container 1167(1)-(N) and may be communicatively coupled to an application subnet 1126 that may be contained in a data plane application layer 1146, which may be contained in a container egress VCN 1168. Corresponding secondary VNICs 1172(1)-(N) may facilitate communications between the untrusted application subnet(s) 1162 contained in the data plane VCN 1118 and the application subnets contained in the container egress VCN 1168. The container egress VCN may include a primary VNIC 1164(1)-(N) that may be communicatively coupled to a public Internet 1154 (e.g., Figure 8 NAT gateway 1138 of the public Internet 854).

[0184] The Internet gateway 1134 included in the control plane VCN 1116 and included in the data plane VCN 1118 can be communicatively coupled to the metadata management service 1152 (e.g., Figure 8 The metadata management service 1152 may be communicatively coupled to the public Internet 1154. The public Internet 1154 may be communicatively coupled to the NAT gateway 1138 included in the control plane VCN 1116 and included in the data plane VCN 1118. The service gateway 1136 included in the control plane VCN 1116 and included in the data plane VCN 1118 may be communicatively coupled to the cloud service 1156.

[0185] In some examples, Fig.11 The architecture model shown in block diagram 1100 can be considered as Figure 8 1168. The architecture of block diagram 800 is an exception to the pattern shown in FIG. 116 and may be desirable to customers of the IaaS provider in situations where the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer may access each customer's respective container 1167(1)-(N) contained in a VM 1166(1)-(N) in real time. The container 1167(1)-(N) may be configured to make calls to a respective secondary VNIC 1172(1)-(N) contained in an application subnet(s) 1126 of a data plane application layer 1146, which may be contained in a container egress VCN 1168. The secondary VNIC 1172(1)-(N) may transmit the call to a NAT gateway 1138, which may transmit the call to the public Internet 1154. In this example, containers 1167(1)-(N), which may be accessed by customers in real time, may be isolated from control plane VCN 1116 and may be isolated from other entities contained in data plane VCN 1118. Containers 1167(1)-(N) may also be isolated from resources from other customers.

[0186] In other examples, a customer may use containers 1167(1)-(N) to call cloud service 1156. In this example, a customer may run code in containers 1167(1)-(N) that requests a service from cloud service 1156. Containers 1167(1)-(N) may transmit the request to secondary VNICs 1172(1)-(N), which may transmit the request to a NAT gateway, which may transmit the request to public Internet 1154. Public Internet 1154 may transmit the request to LB subnet(s) 1122 contained in control plane VCN 1116 via Internet gateway 1134. In response to determining that the request is valid, LB subnet(s) may transmit the request to application subnet(s) 1126, which may transmit the request to cloud service 1156 via service gateway 1136.

[0187] It should be appreciated that the IaaS architectures 800, 900, 1000, 1100 depicted in the various figures may have other components in addition to the components depicted. In addition, the embodiments shown in the various figures are merely some examples of cloud infrastructure systems that may be combined with embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the various figures, may combine two or more components, or may have a different arrangement or configuration of components.

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

[0189] Fig.12 An example computer system 1200 in which various examples of the present disclosure may be implemented is illustrated. System 1200 may be used to implement any of the computer systems described above. As shown, computer system 1200 includes a processing unit 1204 that communicates with multiple peripheral subsystems via a bus subsystem 1202. These peripheral subsystems may include a processing acceleration unit 1206, an I / O subsystem 1208, a storage subsystem 1218, and a communication subsystem 1224. Storage subsystem 1218 includes a tangible computer-readable storage medium 1222 and a system memory 1210.

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

[0191] The processing unit 1204, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1200. One or more processors may be included in the processing unit 1204. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 1204 may be implemented as one or more independent processing units 1232 and / or 1234, wherein a single-core or multi-core processor is included in each processing unit. In other embodiments, the processing unit 1204 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0192] In various embodiments, the processing unit 1204 can execute various programs in response to the program code and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in (one or more) processors 1204 and / or in the storage subsystem 1218. Through appropriate programming, (one or more) processors 1204 can provide the various functions described above. The computer system 1200 can additionally include a processing acceleration unit 1206, which can include a digital signal processor (DSP), a special processor, and the like.

[0193] I / O subsystem 1208 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as a mouse or trackball, touch pads or touch screens incorporated into displays, scroll wheels, click wheels, dials, buttons, switches, keyboards, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices such as Microsoft Motion sensors that enable users to control devices such as 360 game controller. The user interface input device may also include an eye gesture recognition device, such as detecting eye activity from the user (e.g., a "wink" when taking a picture and / or making a menu selection) and translating the eye gesture to an input device (e.g., Google ) In addition, the user interface input device may include a device that enables the user to communicate with the voice recognition system (e.g., Navigator) interactive voice recognition sensing device.

[0194] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, a joystick or pointing stick, a game panel and a drawing board, and audio / video equipment, such as a speaker, a digital camera, a digital camcorder, a portable media player, a webcam, an image scanner, a fingerprint scanner, a barcode reader 3D scanner, a 3D printer, a laser rangefinder, and a sight tracking device. In addition, the user interface input device may include, for example, a medical imaging input device, such as computer tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound equipment. The user interface input device may also include, for example, an audio input device, such as a MIDI keyboard, a digital musical instrument, etc.

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

[0196] Computer system 1200 may include a storage subsystem 1218 containing software elements, shown as currently located within system memory 1210. System memory 1210 may store program instructions executable and loadable on processing unit 1204, as well as data generated during execution of these programs.

[0197] Depending on the configuration and type of computer system 1200, system memory 1210 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated and executed by processing unit 1204. In some embodiments, system memory 1210 may include a variety of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, a basic input / output system (BIOS) containing basic routines that help transfer information between elements within computer system 1200, such as during startup, may typically be stored in ROM. By way of example and not limitation, system memory 1210 also illustrates application programs 1212, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 1214, and an operating system 1216. As an example, operating system 1216 may include various versions of Microsoft Apple and / or Linux operating systems, various commercially available or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or such as iOS, Phone, OS, 10OS and OS operating system's mobile operating system.

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

[0199] The storage subsystem 1200 may also include a computer-readable storage media reader 1220 that may be further connected to a computer-readable storage medium 1222. Together with the system memory 1210, and optionally in conjunction therewith, the computer-readable storage medium 1222 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transferring, and retrieving computer-readable information.

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

[0201] By way of example, computer-readable storage media 1222 may include a hard drive that reads from or writes to non-removable nonvolatile magnetic media, a magnetic disk drive that reads from or writes to removable nonvolatile magnetic disks, and a magnetic disk drive that reads from or writes to removable nonvolatile optical disks (such as CD ROMs, DVDs, and optical drives). Computer readable storage media 1222 may include, but are not limited to: The computer readable storage medium 1222 may include a solid-state drive (SSD) based on non-volatile memory (such as an SSD based on flash memory, an enterprise flash drive, a solid-state ROM, etc.), an SSD based on volatile memory (such as an SSD based on solid-state RAM, dynamic RAM, static RAM, DRAM), a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a combination of a DRAM-based SSD and a flash memory-based SSD. The disk drive and its associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1200.

[0202] The communication subsystem 1224 provides an interface to other computer systems and networks. The communication subsystem 1224 is used as an interface for receiving data from other systems and transmitting data from the computer system 1200 to other systems. For example, the communication subsystem 1224 can enable the computer system 1200 to be connected to one or more devices via the Internet. In some embodiments, the communication subsystem 1224 may include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular phone technology, advanced data network technology such as 3G, 4G or EDGE (Enhanced Data Rate for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof), a global positioning system (GPS) receiver component and / or other components. In some embodiments, the communication subsystem 1224 may provide a wired network connection (e.g., Ethernet) as an addition or replacement of a wireless interface.

[0203] In some embodiments, the communication subsystem 1224 may also receive incoming communications in the form of structured and / or unstructured data feeds 1226 , event streams 1228 , event updates 1230 , and the like on behalf of one or more users who may use the computer system 1200 .

[0204] For example, the communication subsystem 1224 may be configured to receive data feeds 1226 in real time from users of social networks and / or other communication services, such as feed, Updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0205] Additionally, the communication subsystem 1224 may also be configured to receive data in the form of a continuous data stream, which may include event streams 1228 and / or event updates 1230, which may be continuous or unbounded in nature, real-time events without explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

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

[0207] Computer system 1200 may be one of various types, including a handheld portable device (e.g., Cellular phone, computing tablets, PDAs), wearable devices (e.g., Google head mounted display), PC, workstation, mainframe, kiosk, server rack, or any other data processing system.

[0208] Due to the ever-changing nature of computers and networks, the description of the computer system 1200 depicted in the figure is intended only as a specific example. Many other configurations with more or fewer components than the system depicted in the figure are possible. For example, customized hardware may also be used and / or specific elements may be implemented with hardware, firmware, software (including applets), or a combination. In addition, connections to other computing devices such as network input / output devices may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments.

[0209] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language (such as, for example, Java, C++ or Perl), using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or DVD (digital versatile disk), flash memory, etc. The computer-readable medium can be any combination of such storage or transmission devices.

[0210] Such a program can also be encoded and transmitted using a carrier signal suitable for transmission via wired, optical fiber and / or wireless networks that meet various protocols (including the Internet). Therefore, the computer-readable medium according to an embodiment of the present disclosure can be created using a data signal utilizing such program encoding. The computer-readable medium encoded with program code can be packaged with compatible devices or provided separately from other devices (for example, downloaded via the Internet). Any such computer-readable medium can reside on or inside a single computer program product (for example, a hard drive or an entire computer system), and can be present on or inside different computer program products in a system or network. The computer system can include a monitor, a printer or other suitable displays for providing any result mentioned herein to the user.

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

[0212] In addition, although the embodiments of the present disclosure have been described using a specific combination of hardware and software, it should be appreciated that other combinations of hardware and software are also within the scope of the present disclosure. The embodiments of the present disclosure can be implemented using only hardware, or only software, or using a combination thereof. The various processes described herein can be implemented in any combination on the same processor or on different processors. Thus, in the case where a component or module is described as being configured to perform certain operations, such configuration can be accomplished by, for example, designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or by any combination thereof. Processing can use a variety of techniques for communication, including but not limited to conventional techniques for inter-process communication, and different process pairs can use different techniques, or the same process pair can use different techniques at different times.

[0213] The description and drawings are therefore to be regarded in an illustrative rather than a restrictive sense. However, additions, subtractions, deletions and other modifications and changes may be made without departing from the broader spirit and scope set forth in the claims. Therefore, while specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0214] The use of the terms "one" and "an" and "the" and similar references in the context of describing the disclosed embodiments (especially in the context of the following claims) should be interpreted as covering both the singular and the plural, unless otherwise indicated herein or clearly contradictory to the context. Unless otherwise stated, the terms "include", "have", "include" and "contain" should be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connection" should be interpreted as being partially or entirely included, attached to or connected together, even if there is something in the middle. Unless otherwise indicated herein, the description of the value range in this article is only intended to be used as a shorthand method for individually quoting each individual value falling within the range, and each individual value is incorporated into the specification as if it is described separately in this article. Unless otherwise indicated herein or clearly contradictory to the context, all methods described herein can be performed in any suitable order. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., "such as") provided herein is only intended to better illustrate the embodiments of the present disclosure and is not intended to limit the scope of the present disclosure. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0215] Unless expressly stated otherwise, disjunctive language (such as the phrase "at least one of X, Y, or Z") is intended to be understood in context as serving generally to indicate that an item, term, etc. may be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z each be present.

[0216] Preferred embodiments of the present disclosure are described herein, including the best mode known to the inventor for implementing the present disclosure. Variations of these preferred embodiments will become apparent to those of ordinary skill in the art after reading the foregoing description. The inventor expects that the skilled person will appropriately adopt such variations and the inventor intends to practice the present disclosure in a manner different from that specifically described herein. Thus, the present disclosure includes all modifications and equivalent forms of the subject matter recorded in the appended claims where permitted by applicable law. In addition, unless otherwise indicated herein or clearly contradictory to the context, the present disclosure includes any combination of the above-mentioned elements in all possible variations thereof.

[0217] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and was set forth in its entirety herein.

[0218] In the foregoing description, various aspects of the present disclosure are described with reference to their specific embodiments, but those skilled in the art will appreciate that the present disclosure is not limited thereto. Each feature and aspect disclosed above can be used alone or in combination. In addition, without departing from the broader spirit and scope of this specification, the embodiment can be used in any number of environments and applications other than the environment and application described herein. Thus, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0219] The specific details of particular embodiments may be combined in any suitable manner or varied from those shown and described herein without departing from the spirit and scope of the embodiments of the present disclosure.

[0220] The above description of exemplary embodiments of the present disclosure has been given for the purpose of illustration and description. It is not intended to be exhaustive or to limit the present disclosure to the precise form described, and many modifications and variations are possible in light of the above teachings. The embodiments are selected and described in order to best explain the principles of the present disclosure and its practical application, thereby enabling others skilled in the art to best utilize the present disclosure in a variety of examples and with various modifications suitable for the specific use contemplated.

[0221] All publications, patents, and patent applications cited herein are incorporated by reference in their entirety for all purposes.

Claims

1. One or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by one or more processors, cause operations including: determining a first allowed container arrangement, the first allowed container arrangement: (a) comprising a first container and a second container, and (b) determined based at least in part on first common access permissions of the first container and the second container to access a first resource of a computing network; assigning the first container and the second container to the first node group based at least in part on the first allowed container arrangement; Generate a first node access policy for a first node group, the first node access policy comprising a first aggregated set of permissions corresponding to: a first set of permissions associated with a first container access policy corresponding to the first container; and a second set of permissions associated with a second container access policy corresponding to the second container; Deploy a first node group including a first container and a second container in a production environment of a computing network, The first container and the second container access a first resource of the computing network based at least in part on a first node access policy.

2. The one or more non-transitory computer-readable media of claim 1, wherein the operations further comprise: determining that a container arrangement including the first container and the third container is a prohibited container arrangement based at least in part on different access permission sets between the first container and the third container; Based at least in part on the prohibited container arrangement, assigning a third container to the first node group is suppressed.

3. The one or more non-transitory computer-readable media of claim 2, wherein the operations further comprise: assigning a third container to the second node group based at least in part on the prohibited container arrangement; generating a second node access policy for the second node group, the second node access policy comprising a third set of permissions associated with a third container access policy corresponding to the third container, wherein the third container access policy allows the third container to access the second resource of the computing network; deploying a second node group including a third container in a production environment of a computing network, Wherein the third container accesses a second resource of the computing network based at least in part on the second node access policy.

4. The one or more non-transitory computer readable media of claim 3, wherein the operations further comprise: determining a second allowed container arrangement based at least in part on second common access permissions of the third container and the fourth container to access a third resource of the computing network, the second allowed container arrangement including the third container and the fourth container; assigning a third container to the second group of nodes based at least in part on the second allowed arrangement of containers; further generating a second node access policy for the second node group to include a second aggregated set of permissions corresponding to: a third set of permissions associated with a third container access policy corresponding to a third container and a fourth set of permissions associated with a fourth container access policy corresponding to a fourth container; Deploy the fourth container to the second node group in the production environment of the computing network, Wherein the fourth container accesses a second resource of the computing network based at least in part on the second node access policy. 5 . The one or more non-transitory computer-readable media of claim 4 , wherein the fourth container is assigned to the second node group after the third container is deployed in a production environment of the computing network.

6. The one or more non-transitory computer-readable media of claim 4, wherein the first node group is deployed to a first computing instance, and wherein the second node group is deployed to a second computing instance. 7 . The one or more non-transitory computer-readable media of claim 3 , wherein the different set of access permissions includes an absence of common access permissions for the first container and the third container. 8 . The one or more non-transitory computer-readable media of claim 7 , wherein the second container access policy does not include permission for the second container to access the second resource.

9. The one or more non-transitory computer-readable media of claim 8, wherein the first node access policy allows access to the fourth resource, and wherein the second node access policy allows access to the fourth resource.

10. The one or more non-transitory computer-readable media of claim 1, wherein the first public access license comprises: (a) a first permission for a first container to access a first resource in accordance with a first container access policy, and (b) a second permission for a second container to access the first resource in accordance with a second container access policy.

11. The one or more non-transitory computer-readable media of claim 1, wherein the first aggregated set of permissions comprises a minimum set of permissions for the first group of nodes.

12. The one or more non-transitory computer-readable media of claim 1, wherein the first container access policy represents a first maximum set of permissions for the first container, and wherein the second container access policy represents a second maximum set of permissions for the second container.

13. One or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by one or more processors, cause operations including: Introducing containers into cloud service infrastructure; a set of one or more access parameters identifying the container; Generate container access policies for containers, wherein the container access policy comprises a first set of one or more access permissions for the container to access a first subset of cloud services in a first set of cloud services; generating a node access policy for a compute instance corresponding to the container, The node access policy includes a second access permission set for the computing instance to access the first cloud service set, wherein the first access permission set includes a subset of the second access permission set; Deploy the container to the computing instance; deploying the container access policy to a credential request forwarding service; and Deploy the node access policy to an identity access management system.

14. One or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by one or more processors, cause operations including: generating a first container access policy for the first container based at least in part on a first set of access requirements for the first container, the first set of access requirements determined based on a first request log including a first set of one or more requests to access a first set of one or more cloud services; generating a second container access policy for the second container based at least in part on a second set of access requirements for the second container, the second set of access requirements determined based on a second request log including a second set of one or more requests to access a second set of one or more cloud services; generating, based on the first container access policy and the second container access policy, a node access policy for a node including the first container and the second container, the node access policy defining a combined set of access permissions, the combined set of access permissions including a first access requirement set for the first container and a second access requirement set for the second container; as well as The node access policy is deployed in a cloud environment.

15. One or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by one or more processors, cause operations including: receiving a request for a first container to access a cloud service, wherein the first container is one of a plurality of containers executing on a node of a cloud environment; accessing a node access policy comprising a combined set of access permissions for the plurality of containers; The first container is granted access rights to the cloud service based on the node access policy.

16. A computer implemented method comprising the operations according to any one of claims 1-15.

17. A system comprising: at least one hardware processor; The system is configured to perform the operations according to any one of claims 1-15 using the at least one hardware processor.

18. A computer program product storing instructions which, when executed by one or more hardware processors, cause the operations according to any one of claims 1-15 to be performed.

19. A system comprising means for performing the operations according to any of claims 1-15.

Images