System and method for application-based microsegmentation

Abstract

A system and method for controlling processing of intra-VPC and inter-VPC communications is described. First, a destination of a communication is determined, which is located within a first virtual private cloud network (VPC) of a communication source. If so, filtering communications between the destination and the source is controlled by a native cloud fabric associated with a cloud service provider (CSP) underlying network of the first public cloud network. Otherwise, communication between the filtering destination and the source is controlled by the branch gateway. The branch gateway is part of a cloud overlay network configured to provide a communication path between the first virtual private cloud network and the second private cloud network and to set and manage security policies using micro-segments.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims priority to U.S. Provisional Patent Application No. 63 / 337,055, filed on April 30, 2022, and incorporates its entire contents by reference. Technical Field

[0002] Embodiments of the present disclosure relate to the field of networking. More specifically, one embodiment of the present disclosure relates to a network service routing control system that performs micro-segmentation by establishing application domains in single cloud and multi-cloud network deployments. Background Art

[0003] Over the past few years, cloud computing has provided infrastructure as a service (IaaS), where components have been developed to leverage and control the native structure of all types of public cloud networks, such as Web Services (AWS), Cloud Services, Cloud services, etc. These components operate as part of a cloud network infrastructure that overlays portions of a public cloud network or multiple public cloud networks and provides enhanced functionality (e.g., enhanced security, increased visibility, etc.).

[0004] The overlay network infrastructure can be configured to support hundreds of tenants (e.g., different people, organizations, or other entities) simultaneously by implementing virtual network infrastructures, where the configuration of these virtual networking infrastructures can vary depending on the public cloud provider. For example, the virtual networking infrastructure may include AWS virtual private cloud, for Virtual networks (Vnets) for cloud services, etc. For convenience and consistency, we refer to all types of these virtual networking infrastructures as "Virtual Private Cloud Networks" or "VPCs."

[0005] In general, a "VPC" is an on-demand, configurable shared pool of resources that can be allocated within an overlay network infrastructure and provides a degree of isolation between different tenants using cloud resources. Overlaying the infrastructure of a public cloud network, certain types of VPCs, known as "spoke" VPCs, can be used as entry points for routing messages received from resources within an on-premises network or within the spoke VPC itself between components that form part of the overlay network infrastructure. These VPCs can be configured to support message routing to the same region as a public cloud network, different regions of the same public cloud network, or different public cloud networks.

[0006] For security, network administrators can rely on microsegmentation, a secure method of managing network access between resources configured to run application instances. Microsegmentation allows network administrators to set and manage security policies that control the propagation of network data traffic in an effort to reduce the exposure of resources to network security attacks and strengthen security compliance across the network. Microsegmentation can be utilized without redesigning the network architecture.

[0007] From a security perspective, micro-segmentation enables network administrators to allow and / or deny communications between specific resources. However, network management that relies on micro-segmentation as a security feature has been challenging. To support micro-segmentation with current network infrastructure, network administrators would have the daunting task of tag management, where tags may be directed to different types of resources, and the policy's reliance on tags brings reliability and scalability issues. Summary of the invention

[0008] An embodiment of the claimed invention is directed to a controller comprising a processor; and a non-transitory storage medium communicatively coupled to the processor, the non-transitory storage medium comprising (i) classification logic that determines a virtual area in which a newly discovered endpoint resides based on recovery information associated with the newly discovered endpoint, and (ii) rule generation logic.

[0009] Further embodiments of the claimed invention are directed to a method for controlling network traffic flow separation between inter-VPC communications and intra-VPC communications.

[0010] Another embodiment of the claimed invention is directed to a non-transitory storage medium comprising logic that, when executed, controls flow separation of inter-VPC communications and intra-VPC communications. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like reference numerals indicate similar elements and in which:

[0012] Figure 1A It is a first exemplary embodiment of a cloud platform for deploying a network service routing control system.

[0013] Figure 1B is a second exemplary embodiment of a cloud platform, which shows a connection to a local deployment network.

[0014] Figure 2 is an exemplary embodiment of a logical architecture of the controller of FIG. 1 , which is characterized by management logic, security logic, and policy configuration logic that jointly support micro-segmentation.

[0015] Figure 3A Is Figure 1A-1BAn exemplary embodiment of a first display screen of a graphical user interface (GUI) of a virtual appliance is presented to control the operability of a multi-cloud network through a micro-segmentation scheme.

[0016] Figure 3B is in response to Figure 3A An exemplary embodiment of a second screen display presented upon selection of the security display element 330 for configuring Figure 1A-1B Micro-segmentation of multi-cloud networks.

[0017] Figure 4A is in response to Figure 3B An exemplary embodiment of a third display screen presented upon selection of a micro-segmented display element shown in the second screen display.

[0018] Figure 4B-4C An exemplary embodiment of an interactive display area generated and displayed for creating an application domain using resources based on tag selection.

[0019] Figure 4D An exemplary embodiment of an interactive display area generated and displayed for creating an application domain using resources selected based on an Internet Protocol (IP) address.

[0020] Figure 5A is an exemplary embodiment of an exemplary embodiment of a fourth display screen for routing rule generation.

[0021] Figure 5B is an exemplary embodiment of a fourth display screen, showing Figure 5A The routing rules for the operational configuration are shown and described in .

[0022] Fig. 6A is an exemplary embodiment of a first interactive display area, which is generated and displayed to show that Figures 4A-4D The set of operations shown is when the resources of the first application domain are created.

[0023] Figure 6B is an exemplary embodiment of a second interactive display area that is generated and displayed to show the Figures 4A-4D The set of operations shown is when resources of the second application domain are created.

[0024] Figure 6C It shows the control Figure 6A-6B An exemplary embodiment of a third interactive display area of ​​a routing rule for operability of the first and second application domains, wherein the routing rule is based on Figure 5A-5B to configure as shown.

[0025] Figure 7 is an exemplary embodiment of an application domain. DETAILED DESCRIPTION

[0026] An embodiment of a network service routing control system is described. The network service routing control system includes routing control logic that operates with a cloud component of a software-defined network, which is constructed to overlay one or more public cloud networks (hereinafter referred to as a "cloud platform"). In general, the routing control logic and the cloud component are configured to support micro-segmentation on a single public cloud network or multiple (different) public cloud networks. The routing control logic can be deployed in a centralized controller, where a subset of these cloud components is responsible for controlling the egress and ingress communications between resources associated with different VPCs on the cloud platform. "Resources" may include, but are not limited to, or constrained to a virtual private cloud network (VPC), a virtual subnet, a virtual machine (VM) instance, or another type of computing device configured to run an application instance. Communications between resources within the same VPC are controlled by native constructs within the public cloud network, which is independent of the operability of the required routing control logic.

[0027] As described herein, routing control logic is configured to utilize a single public cloud network or multiple public cloud networks (hereinafter referred to as "multi-cloud networks") to collect and / or distribute attributes associated with one or more resources. The collection and / or distribution can be triggered by an event, where the event can be periodic or non-periodic. For example, an event can be non-periodic, such as a query message from a virtual facility, as described below. Alternatively, an event can be periodic, such as a scheduled (time / date) list of resources associated with a tenant and residing within a public cloud network or a multi-cloud network. For clarity, the operation of the network service routing control system, and in particular micro-segmentation, will be described in conjunction with resources deployed within a multi-cloud network.

[0028] In addition to the connection and / or distribution of resource attributes, routing control logic can be configured to operate with the virtual appliance to create one or more application domains and programmable routing policies that control communications between different application domains. Application domains isolate resources, including resources residing in different VPCs operating in different public cloud networks (e.g., resources within a multi-cloud network), where routing policies can be configured to control transmissions to / from any of these resources included in the application domain.

[0029] Here, application domains can be created by selecting resources based on their assigned tags, and routing policies can be created by applying actions (e.g., allow, deny, reroute) to communications between resources represented by these assigned tags. However, the routing control logic can be configured to modify, store, and download filtering and / or routing rules (hereinafter referred to as "routing rules") associated with the routing policy to selected cloud components of the cloud platform. The modification involves the conversion of user-defined tags associated with each resource managed by the routing rule (e.g., resources identified as a "source" application domain or a "destination" application domain). Selected cloud components can include branch gateways and / or transit gateways, which are computing devices responsible for implementing data plane operability in accordance with the routing rules.

[0030] More specifically, the branch gateways and / or transit gateways forming the cloud platform may locally store rules associated with routing policies for application domains involving one or more resources (e.g., VM instances, virtual subnets, VPCs) that control egress and ingress communications to the one or more resources. For example, the routing policies for the application domain are characterized by routing rules that are intended to control transmissions from / to resources that operate as source / destination. According to one embodiment of the present disclosure, these routing policies are created based on tags associated with resources selected as part of the application domain, but then the routing control logic is responsible for converting routing policies developed using the user interface of the virtual facility to replace their tags with Internet Protocol (IP) addressing for each resource. In other words, the routing control logic is configured to convert portions of the routing rules associated with each routing policy by replacing tags that identify resources belonging to the source or destination application domain with IP addresses associated with the resources. During the inventory of resources performed by the controller, the IP address of the resource is obtained together with its tag.

[0031] For example, an application domain may include multiple resources, where each resource within the application domain is associated with a tag that populates the application domain. As an illustrative example, a resource may be assigned one or more tags, where one tag may constitute a first key-value pair (e.g., name: VM-A) and another tag may constitute a key-value pair (e.g., department: sales), where the VM instance (VM-A) may be part of the sales department of a category (selector) identified as a first public cloud network (AWS), while other VM instances (VM-B, VM-C) may be part of the sales department of a category identified as a second public cloud network (Azure). During processing and before passing the routing rules to the cloud component, the routing control logic converts the tag "name: VM-A" to an IP address associated with the VM-A instance (e.g., 192.168.10.1) and converts the tag (department: sales) to IP addresses associated with the VM-B and VM-C instances (e.g., 192.168.50.30 and 192.168.50.40).

[0032] Alternatively, instead of key-value pairs, the application domain configuration allows entry of an IP address range (e.g., a subnet address, a Classless Inter-Domain Routing (CIDR) address), where the application domain will include all cloud components that have IP addresses assigned within that IP address range. Thus, if labels are not used in the generation of application domains, no label to IP address conversion is required.

[0033] Here, the routing control logic is implemented, and the controller can be communicatively coupled to the virtual facilities that operate in coordination with the controller to provide an organized global operational view of the tenant's multi-cloud network and a dynamic topology map to maintain the accurate topology of their global multi-cloud network and analyze the global network service flow to easily pinpoint and eliminate service anomalies. The virtual facilities utilize the attribute information collected by the controller to formulate micro-segments of the tenant's multi-cloud network when allowing, denying, or rerouting network communications (e.g., messages) on the network.

[0034] I. the term In the following description, certain terms are used to describe features of the present invention. In some cases, each of the terms "logic" and "component" represents hardware, software, or a combination thereof configured to perform one or more functions. As hardware, logic (or component) may include circuits with data processing and / or storage functions. Examples of such circuits may include, but are not limited to, or constrained to, a processor (e.g., a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, an application-specific integrated circuit, etc.); non-temporary storage media; combinational circuit elements that collectively perform one or more specific functions, etc.

[0035] Alternatively, or in combination with the above-mentioned hardware circuits, the logic (or component) may be software in the form of one or more software modules. (Multiple) software modules may be configured to operate as one or more software instances with selected functions (e.g., virtual processors, data analysis, etc.) or as a virtual network device including one or more virtual hardware components. (Multiple) software modules may include, but are not limited to, or be constrained to executable applications, application programming interfaces (APIs), subroutines, functions, procedures, applets, servlets, routines, source code, shared libraries / dynamically loaded libraries, or one or more instructions. (Multiple) software modules may be stored in any type of suitable non-transitory storage medium or temporary storage medium (e.g., electrical, optical, acoustic or other forms of propagation signals, such as carrier waves, infrared signals or digital signals). Examples of non-transitory storage media may include, but are not limited to, or be constrained to programmable circuits; semiconductor memories; non-persistent memories, such as volatile memories (e.g., any type of random access memory "RAM"); or persistent storage devices, such as non-volatile memories (e.g., read-only memory "ROM", power-supported RAM, flash memory, phase change memory, etc.), solid-state drives, hard drives, optical drives, or portable memory devices.

[0036] One type of component may be a cloud component, i.e., a component that operates within a cloud-based network. A cloud component may be part of a network overlay that operates to control message routing between native code components of one or more public cloud networks. A cloud component associated with native code may be referred to as a "native cloud component."

[0037] Controller: A "controller" is generally defined as a component that manages the operability of cloud components within one or more regions of a single public cloud network or within multiple (two or more) public cloud networks (hereinafter referred to as a "multi-cloud network"). Such management may include leveraging intelligence (e.g., addresses, attributes such as assigned tags, etc.) obtained from cloud components that are communicatively coupled to gateways, which form part of an overlay network whose operability is controlled by the controller. According to one embodiment, the controller may include management logic, security logic, and policy configuration logic to install policies for routing rules, which may be unique for each gateway and / or each VPC based on the active application domain. Routing rules may be applied by the gateway to control egress or ingress transmissions from application instances deployed within the VPC.

[0038] Tenants: Each "tenant" uniquely corresponds to a specific customer that is provided access to a cloud or multi-cloud network, such as a company, individual, partner, or any group of entities (e.g., individual(s) and / or business(es)).

[0039] Computing Devices: A "computing device" is generally defined as a virtual or physical logic device that has data processing and / or data storage capabilities. Here, a computing device may include a virtual device that is configured to perform functions based on information received from a cloud component. For example, a computing device may correspond to a virtual server that is configured to execute a software instance. A computing device may correspond to a virtual routing device, such as a gateway, that is responsible for controlling communications between different resources.

[0040] Gateway: A "gateway" is generally defined as virtual or physical logic that has data monitoring or data routing functionality. As an illustrative example, a first type of gateway may correspond to virtual logic, such as a data routing software component, that is assigned an Internet Protocol (IP) address within an IP address range associated with a virtual networking infrastructure (VPC) that includes the gateway to handle routing of messages within and from the VPC. Here, a first type of gateway may be identified differently based on its location / operability within a public cloud network, although the logical architecture is similar.

[0041] For example, a "branch" gateway is a gateway that supports routing network traffic between components requesting cloud-based services and a VPC that maintains cloud-based services available to multiple (two or more) tenants. A "transit" gateway is a gateway that is configured to further facilitate the propagation of network traffic (e.g., one or more messages) between different VPCs, such as different branch gateways within different branch VPCs. Alternatively, in some embodiments, a gateway may correspond to a physical logic, such as a class of computing devices that support and are addressable (e.g., assigned a network address such as an IP address).

[0042] Virtual Facilities: A “virtual appliance” is generally defined as software operating in conjunction with a controller to present display screens that allow tenants to visualize and control the operability of a single (public) cloud network or a multi-cloud network.

[0043] Transmission medium: "Transmission medium" is generally defined as a physical or logical communication link (or path) between two or more components. For example, as a physical communication path, wired and / or wireless interconnects in the form of wires, optical fibers, cables, bus tracks, or wireless channels using infrared, radio frequency (RF) can be used. As a logical communication link, an API, function call, etc. can be used to communicatively couple two or more components together.

[0044] Computerization: The term generally denotes any corresponding operation performed by hardware in conjunction with software.

[0045] information:Information in a prescribed format and transmitted according to a suitable delivery protocol. Thus, each message may be in the form of one or more packets (e.g., data plane packets, control plane packets, etc.), frames, or any other sequence of bits in a prescribed format.

[0046] Finally, the terms "or" and "and / or" as used herein should be interpreted as inclusive, or meaning any one or any combination. As an example, "A, B, or C" or "A, B, and / or C" means "any of the following: A; B; C; A and B; A and C; B and C; A, B, and C". An exception to this definition would only occur if a combination of elements, functions, steps, or actions are inherently mutually exclusive in some way.

[0047] As the invention is susceptible to embodiments in many different forms, this disclosure is intended to be considered as an exemplification of the principles of the invention and is not intended to limit the invention to the specific embodiments shown and described.

[0048] II. Network Service Routing Control System Architecture / Operability Reference now Figure 1A , showing a first exemplary embodiment of a cloud platform 100 deploying a network service routing control system 105. As described below, the network service routing control system 105 features a controller 160 having routing control logic 161 responsible for modifying one or more routing rules 182 (hereinafter referred to as "routing rule(s)") associated with one or more application domains 180 (hereinafter referred to as "application domain(s)") prior to distribution to cloud components, such as branch gateways 132, 137, 152, and / or 157 that control egress and / or ingress communications with resources included in the application domain(s) 180.

[0049] like Figure 1A As shown, the cloud platform 100 may correspond to a software-defined cloud or multi-cloud overlay network characterized in that cloud components communicate via messages using private network addresses such as Internet Protocol (IP) addresses. As shown, the cloud platform 100 operates as an overlay network that supports and controls routing of communications between resources within the multi-cloud network 112 (i.e., resources within the first public cloud network 110 and resources within the second public cloud network 115).

[0050] According to an illustrative embodiment, cloud platform 100 is configured to provide connectivity between resources 120 associated with a first virtual private cloud network (VPC) 130 (e.g., Sales VPC) and resources 140 associated with a second VPC 150 (e.g., Human Resources "HR" VNet). Resources 120 may include one or more virtual machine (VM) instances 122, one or more virtual subnets (subnets) 124, and / or the first VPC 130 itself. Similarly, resources 140 may include one or more virtual machine (VM) instances 142, one or more subnets 144, and / or the second VPC 150 itself.

[0051] Here, the cloud platform 100 operating as an overlay network includes a data plane 102 and a control plane 104. The control plane 104 refers to all functions and / or processes that determine which routing path to use when sending control messages between cloud components. The data plane 102 refers to all functions and / or processes that forward data messages from one interface to another based on controls set by a controller 160 that is communicatively coupled to the control plane 104.

[0052] For example, according to one embodiment of the present disclosure, the data plane 102 can be configured with a cloud component that enables data messages to be transmitted through the cloud platform 100. For example, as an illustrative embodiment, the data plane 102 can include a branch gateway 132 associated with the first VPC 130, a branch gateway 152 associated with the second VPC 150, a transit gateway 164 associated with the first transit VPC 165, and a transit gateway 166 associated with the second transit VPC 167. The transit gateways 164 / 166 provide connectivity between different VPCs. Different VPCs can reside in the same public cloud network (e.g., VPCs 130 and 135 within the first public cloud network 110, VPCs 150 and 155 within the second public cloud network 115, etc.). In addition, or alternatively, as shown, these different VPCs can reside in different public cloud networks (e.g., VPCs 130 and 150).

[0053] Similarly, the control plane 104 features a transmission medium 162 that communicatively couples the controller 160 to other components of the cloud platform 100, such as the branch gateways 132, 137, 152, and 157 and / or transit gateways 164 and 166, as shown. The controller 160 relies on the control plane 104 to issue resource discovery messages 163 to the branch gateways 132 / 137 / 152 / 157 (and optionally the transit gateways 164 and 166), where the resource discovery message initiates a resource discovery process by the native cloud components of the CSP, and the CSP returns information (e.g., (multiple) tags, network addresses, and other attributes) associated with resources within the VPC 130 / 135 / 150 / 155 (and optionally the transit VPCs 165 and 166) via a discovery response message 175. To reduce bandwidth usage, the returned information can relate to newly discovered resources and / or resources that have been modified (updated) since a previous resource discovery process.

[0054] Still reference Figure 1A , the virtual appliance 170 (e.g., software having a user interface for collecting, organizing, and displaying network attributes associated with resources within the multi-cloud network 112) is configured to receive at least a portion of the return information (e.g., tags) included in the discovery response message 175 to generate one or more application domains 180. In addition to the application domain(s) 180, one or more routing rules 182 may be configured for the application domain(s) 180. During or after configuration, the routing rule(s) 182 are provided to the routing control logic 161, which performs a label-to-IP address conversion on the tags associated with the resources identified in the application domain(s) 180 and related to the routing rule(s) 182. The label-to-IP address conversion is performed before distributing the routing rule(s) 182 to a local data store accessible by at least the branch gateway 132 / 137 / 152 / 157. The routing rule(s) 182 affect the operability of branch gateways such as branch gateways 132 and / or 152 (when the application domain(s) 180 include resources within the first and second VPCs 130 and 150) by controlling (e.g., filtering or rerouting) certain communications between the first VPC 130 and the second VPC 150. Additionally, or alternatively, the routing rule(s) 182 may be distributed to a local data store accessible to at least the transit gateway 164 / 166 to control the operability of certain communications between the first VPC 130 and the second VPC 150.

[0055] As an illustrative example, in response to a request from a virtual appliance 170 (e.g. CoPilot TMIn response to a tag query message 172 of a discovery response message (software), the controller 160 is configured to utilize one or more APIs 174 provided by a cloud service provider (CSP) for each of the public cloud networks 110 and / or 115 to collect network information associated with resources of tenants within a VPC deployed in the (multiple) public cloud networks 110 and / or 115. The (multiple) APIs 174 allow the controller 160 to collect network information 176, including network (IP) addresses 177 and attributes 178 associated with resources within the VPC (e.g., tags assigned by operation of native cloud components). The network information 176 is provided to the controller 160 as part of the discovery response message 175. As shown, the controller 160 is configured to collect network information 176 associated with cloud components, such as (multiple) VM instances 122, virtual subnets 124, and / or VPCs 130, via the APIs 174 and / or the transmission mediums 162.

[0056] Here, the virtual facility 170 operates in conjunction with the controller 160 to provide an organized global operational view of the tenant's multi-cloud network 112 along with a dynamic topology map to maintain the accurate topology of its global multi-cloud network and analyze the global network service flow to easily pinpoint and troubleshoot service anomalies. For example, the virtual facility 170 utilizes attributes 178, such as tags, collected by the controller 160 in the creation of (multiple) application domains 180, which implement micro-segmentation of the tenant's multi-cloud network 112 when allowing, denying, or rerouting certain network communications (e.g., messages) propagating on the multi-cloud network 112.

[0057] Reference now Figure 1B , a second exemplary embodiment of the cloud platform 100 is shown, which shows a connection to an on-premises (on-premises) network 190. As described above, the cloud platform 100 includes a data plane 102 and a control plane 104. The control plane 104 is characterized by a transmission medium 162 that communicatively couples a controller 160 and a transit gateway 164. Here, the (multiple) transit gateways 164 include a data store 168 that is configured to store routing rules 169 for an application domain to control egress and ingress transmissions between the on-premises network 190 and resources within any VPC (such as, for example, a virtual machine (VM) instance 122 or a virtual subnetwork (subnet) 124 within a first VPC 130).

[0058] like Figure 1AAs described, routing control logic 161 is configured to perform label-to-IP address translation on routing rule(s) 182 prior to storage in local data store(s) (e.g., local data store 168) relied upon by at least transit gateway 164. Routing rule(s) 182 pertain to resources associated with application domain(s) provisioned by a tenant, wherein application domain(s) 180 include resources 192 within an on-premises network 190 and edge routing devices 194 of on-premises network 190, not operating as an extension of cloud platform 100. Routing rule(s) 182 may include rules that cause transit gateway 164 to control (e.g., filter or reroute) receipt (ingress) of data messages to and / or transmission (egress) of data messages from on-premises resources 192.

[0059] III. Controller-Network Service Routing Control System Reference now Figure 2 , showing Figure 1A-1B 100, characterized by management logic 240, security logic 250, and policy configuration logic 260. Here, the controller 160 includes one or more interfaces, which are shown as a first interface 200 and a second interface 210. The first interface 200 provides connections between cloud components associated with the cloud platform 100, while the second interface 210 provides connections with the cloud components associated with the cloud platform 100. Figure 1A-1B In addition to interfaces 200 and 210 , controller 160 also includes processing logic 220 and non-transitory storage medium 230 . Non-transitory storage medium 230 includes management logic 240 , security logic 250 , and policy configuration logic 260 .

[0060] Here, according to one embodiment of the present disclosure, the management logic 240 is configured to support communication with cloud components that are part of the resources 120 / 140 of the cloud platform 100. For example, in response to the controller 160 receiving a tag query message 172 from the virtual facility 170, the management logic 240 is configured to initiate a resource discovery message 163 through one or more CSP-provided APIs 174 to communicate with the native cloud components of the CSP. The native cloud components of the CSP (not shown) are adapted to return one or more discovery response messages 175, wherein each discovery response message 175 includes network information 176 (e.g., (multiple) network (IP) addresses 177, (multiple) tags 178, and / or other attributes) about the resources communicating with the (multiple) gateways. For example, as Figure 1A and Figure 2As shown, the branch gateway 132 is adapted to return a discovery response message 175 that includes IP addresses and network attributes associated with resources within the first VPC 130, including VM instances associated with the first virtual subnet 124 (CIDR 10.20.1.0 / 24) and VM instances associated with the second virtual subnet (CIDR 10.20.2.0 / 24).

[0061] In addition to controlling the discovery message exchange described above, the management logic 240 is also configured to parse the content of the received discovery response message(s) 175 to obtain and identify the IP address associated with each resource along with its corresponding attributes (e.g., one or more tags assigned to the cloud component). The IP address along with its corresponding network attributes is stored in the resource data store 270.

[0062] like Figure 2 As shown, the security logic 250 is configured to support communication with the virtual facility 170 for generating application domains and / or routing policies associated with these application domains. Here, the security logic 250 includes resource evaluation logic 252, which is configured to analyze network information included as part of the received discovery response message 175. The analysis may include identification and organization of network information, which will include network (IP) addresses and attributes (e.g., tags, etc.) associated with each discovered resource. The network information may be stored in the resource data store 270.

[0063] In addition, before the network information is stored in the resource data store, the resource evaluation logic 252 can further analyze the network information to detect newly discovered and / or (multiple) resources that have been updated since the last discovery message exchange. These analyses may involve comparisons between the IP address associated with the resource discovered and the IP address associated with the known resource. For newly discovered resources (that is, the resource IP address is not currently maintained in the resource data store 270), the network information associated with the resource (for example, IP address, label, etc.) is stored in the resource data store 270. However, for the IP address associated with the resource discovered that has been included in the resource data store 270, the attribute of each discovered resource can be analyzed to confirm that no attribute change has been performed. For example, this can be achieved by performing a hash operation on the attribute of the discovered resource, and comparing the running, stored hash value of the attribute associated with the known (and stored) resource in the resource data store 270. Any difference will represent the change of the attribute, and ensure that the attribute is updated in the resource data store 270.

[0064] Here, according to one embodiment of the present disclosure, when generating an application domain, the virtual appliance 170 may access network information associated with the discovered resource(s) maintained in the resource data store 270. Specifically, the resource data store 270 may be organized so that the virtual appliance 170 can access the network information associated with the discovered resource(s). Figure 1A-1B According to another embodiment of the present disclosure, the security logic 250 may include a query response logic 254, which is responsible for generating a tag reply message 245 in response to the tag query message 172 to provide tag information related to the resources within the multi-cloud network 112. The logic within the virtual facility 170 can use the tag information to generate a tag reply message such as Figures 4A-4D The content associated with the resulting application domain may be stored in the application domain data store 256 .

[0065] It is anticipated that the query response logic 254 may be configured with filtering logic 255 to optimize bandwidth usage between the controller 160 and the virtual facility 170. For example, the filtering logic 255 may be configured to return network information 176 related only to resources that have been updated or newly added to the multi-cloud network 112 in response to receiving discovery response message(s) 175 prompted by the corresponding resource discovery message(s) 163. Alternatively, the filtering logic 255 may be configured to control the return of network information 176 associated with newly discovered resources, but only return updated attributes of known (discovered) resources.

[0066] After configuring application domains, you can create routing policies for these application domains. As described below, each routing policy can be characterized by one or more routing rules, which are based on the Figure 5A-5B The routing rules are generated by selecting a display element represented on a graphical user interface (GUI) presented by the virtual facility shown. Here, each routing rule can be configured to (i) allow or deny receiving messages from resources associated with a specific application domain, and / or (ii) reroute messages originating from resources of a selected application domain or destined for specific resources of another application domain, where the rerouting can be performed to submit the message to another resource (e.g., a network threat analyzer, a firewall, or an integrated firewall solution for multiple CSPs, etc.) to provide enhanced security for messages sent from or directed to a specific application domain. In addition, each routing rule can also include parameters that restrict communication between application domains. For example, a routing rule can only allow or deny the transmission or reception of messages associated with one or more selected transport protocols (e.g., TCP, UDP, etc.) and / or associated with one or more selected port numbers (e.g., port number 443). The (multiple) routing rules associated with each application domain can be stored in the rule data store 257.

[0067] Still reference Figure 2 , the policy configuration logic 260 is configured to, in response to the generation of routing rules associated with the application domain, translate one or more tags used to identify resources within the application domain into IP addresses associated with those resources. The policy configuration logic 260 is configured to change the routing rules by determining the tags of each resource included in the application domain associated with the routing rule, accessing the resource data store 270 to determine the IP address associated with each tagged resource, replacing its corresponding tag in the routing rule with the IP address, and storing the changed routing rules in the rule data store 257. The changed routing rules are passed from the controller 160 to the egress and / or ingress points (such as the egress and / or ingress points) associated with the cloud platform. Figure 1A Branch Gateway 132 / 137 / 152 / 157 and / or Figure 1B A local storage device associated with the transit gateway 164 / 169).

[0068] IV. Application domain and routing rule generation Reference now Figure 3A , showing a graphical user interface (GUI) presented by the virtual appliance 170 to control Figure 1A-1B 1. Here, the first display screen 300 features a navigation menu 310 that includes a plurality of user interface (UI) display elements 320, including a security display element 330. Selection of the security display element 330 signals the virtual application 170 to generate a virtual application 170 such as Figure 3B A second display screen 350 is shown.

[0069] In addition to the navigation menu 310, the first display screen 300 also includes a plurality of icons 340, which show Figure 1A-1B The component types and operating characteristics of the multi-cloud network 112. For example, Figure 3A As shown, the plurality of icons 340 may include (i) a plurality of branch gateways 342 representing entry points to the cloud platform, (ii) a plurality of transit gateways 344 establishing communications between different regions of a public cloud network or between different public cloud networks, (iii) a plurality of VM instances 346 within the multi-cloud network 112, (iv) a plurality of VPCs 348 (VPC, VNet, VCN) within the multi-cloud network 112 provided by different CSPs, etc. These icons 340 are shown in a grid layout, although any orientation of the icons 340 may be used.

[0070] Reference now Figure 3B , showing the response to Figure 3A The selection of the security display element 330 is presented for configuring Figure 1A-1B1. Here, the second screen display 350 features a display element 360, such as within a title 370 of the second screen display 350, for configuring Figure 1A-1B When selected, the display element 360 labeled “Micro-segmentation” signals the logic within the virtual facility to generate a third display screen 400 that enables the tenant to create a micro-segmentation of the multi-cloud network 112. Figures 4A-4D The application domain shown and / or Figure 5A-5B The routing policy represented by the routing rules is shown.

[0071] refer to Figure 4A , showing the response to the selection Figure 3B 360 for micro-segmentation display element 360. Here, third display screen 400 includes first display element 402 and second display element 404. First display element 402, when selected (automatically selected by default or selected by a tenant administrator), prompts a virtual facility operating in conjunction with security logic 250 of controller 160 to present a selectable display element (e.g., application domain display element 406) for each previously created application domain. As an illustrative embodiment, application domain display element 406 displays selected content, such as, for example, name 407, resource type 408, and rule reference 409, to represent the application domain.

[0072] According to this illustrative embodiment, name 407 identifies a label assigned to the application domain ("Current AD"), and resource type 408 includes the type of resources that form the application domain. For example, one resource type constitutes a "VM" (virtual machine), which indicates that the resources within the application domain correspond to a VM instance. Rule reference 409 identifies a routing rule associated with the application domain. Although not shown, in response to selection of application domain display element 406, an interactive display area can be generated that shows resources associated with the application domain and allows the application domain to be modified or deleted.

[0073] like Figure 4A As further shown, the third display screen 400 features a display element (domain+) 410, which, when selected, prompts the generation of an interactive display area 420 within the third display screen 400 for creating a new application domain, such as Figure 4B As shown. Interactive display area 420 includes a plurality of interactive fields 425 that enable a tenant administrator to configure an application domain. For example, plurality of interactive fields 425 may include a first input field 430, a second input field 431, a third input field 432, a fourth input field 433, a fifth input field 434, and / or a sixth input field 435. Some of these input fields, such as input fields 432-433, have been constrained to be associated with Figure 1A-1B The key-value pairs associated with resources discovered within the multi-cloud network 112 .

[0074] According to one embodiment of the present disclosure, the first input field 430 may be configured as a text field that allows the tenant administrator to enter a name selected for the application domain. As shown, the application domain with the label "Web Application" is selected.

[0075] The second input field 431 may be configured as a resource selection type, which allows the tenant administrator to select different types of resources to be included as part of the application domain. For example, the resource type may be selected as "virtual machine" to indicate that the tags available in input fields 432 and 433 correspond to resources that constitute VM instances within the tenant's multi-cloud network. Alternatively, the resource type may be selected as "virtual subnet" or "VPC", where the tags made available in input fields 432 and 433 correspond to virtual subnets or VPCs, respectively.

[0076] Input fields 432 and 433 constitute a key-value pair (label), wherein the second input field 432 corresponds to the key portion of the label, and the third input field 432 corresponds to the value portion of the label. Here, the third input field 432 is represented as a drop-down menu, which allows different key types to be selected. Assuming that multiple tags associated with different category types can be assigned to resources, each key type identifies a unique label category. For example, a resource can be assigned a label based on the tag (name) of the resource and a label identifying the department (e.g., sales, accounting, engineering, etc.) to which the resource is related. As shown in the figure, the key type can include a name, a type, a logical area (e.g., a department), etc.

[0077] Based on the key type selected in the third input field 432, the fourth input field 433 identifies the value associated with the selected key type associated with the available resource tags. Figure 4C As shown, in response to selecting "name" as the key type in the third input field 432, the fourth input field 433 operates as a drop-down menu 440 that includes a list of tag names 450 for each tagged resource discovered by the controller 160 and provided to the virtual facility 170. Selection of one of the tags (e.g., "VM Instance A") is shown to identify that the application domain includes a VM instance resource tagged with the name "VM Instance A".

[0078] Return to reference Figure 4B , the interactive display area 420 includes a fifth input field 434, which, when selected, allows selection of additional tags (i.e., key pairs) to further populate the application domain (network application) with additional tagged resources. Instead of entering key-value pairs by relying on tags for populating the application domain, the sixth input field 435 allows entry of an IP subnet address or CIDR. Figure 4DAs shown, the input of a CIDR signal provides the controller with an application domain populated by all cloud components residing within the identified IP subnet address or CIDR.

[0079] refer to Figure 5A , showing an exemplary embodiment of a fourth display screen 500, wherein after selecting the display on Figure 4A 4, the fourth display screen 500 is presented when the second display element (rule) 404 within the third display screen 400 is selected. Here, the fourth display screen 500 is characterized by a display element (+rule) 510, which, when selected, prompts the generation of an interactive display area 520 within the fourth display screen 500 for creating routing rules. The interactive display area 520 includes a plurality of interactive fields 525 that enable the tenant administrator to configure routing rules. For example, the plurality of interactive fields 525 may include, but are not limited to, the following: a rule name input field 530; a source (application domain) input field 535; a destination (application domain) input field 540; an action input field 545; a protocol input field 550; a port number input field 555, an implementation (activation) input field 560; and a record input field 565.

[0080] According to this embodiment of the present disclosure, the rule name input field 530 operates as a text field to allow selection of a label to identify the routing rule. The name can be automatically generated, or selected by the tenant administrator. The source input field 535 and the destination input field 540 are automatically generated drop-down menus that allow the tenant administrator to select the application domains that operate as the source and destination of the communication to which the routing rule applies. More specifically, the routing rule applies to the application domain identified as the source and the application domain identified as the destination, and therefore, the rule applies to both application domains.

[0081] In addition, interactive display area 520 also includes an action input field 545, which can be set to an operational state in which the created routing rules are configured to allow certain types of transmissions, deny certain types of transmissions, or reroute certain types of transmissions originating from the source application domain and destined for the destination application domain. In the event that transmission rerouting is selected within action input field 545, an additional field (not shown) can be generated to allow selection of a target application domain or cloud component to receive the rerouted transmission.

[0082] Interactive display area 520 also features a protocol input field 550 and a port number input field 555. These input fields allow selection of a protocol type (e.g., TCP, UDP, etc.) and port number(s) to further define the type of transmission to be controlled (allow, deny, or reroute). Based on these inputs, routing rules can be customized for transmissions associated with the selected transmission protocol and / or port number(s).

[0083] The implementation input field 560 is represented as a first toggle switch that signals whether the routing rule is active or inactive depending on the position of the toggle switch. Once the policy configuration logic 260 is received, and after label to IP address mapping is performed, the active routing rule is distributed to cloud components within the cloud platform to control traffic from resources within the "Network Application" application domain and resources within the "App2" application domain. This selective implementation of routing rules provides greater control and flexibility for traffic distribution across multi-cloud networks. By default, routing rules can be placed in an inactive state until activated by a tenant.

[0084] Record input field 565 is represented as a second switch, which signals whether the routing rule is placed in a recording state or a non-recording state, depending on its position. When placed in a recording state, the logic within the virtual application can be configured to collect information associated with the transmission of messages that meet and / or violate the routing rules. The recording can be performed independently of whether the routing rules are active or inactive. This allows network administrators to test the operational benefits associated with the application of each routing rule, and to determine their relevance. Relevance can represent the change or removal of routing rules to reduce costs and / or workload.

[0085] Reference now Figure 5B , showing an exemplary embodiment of a fourth display screen 500, which shows Figure 5A Here, the routing rule parameters are shown and associated with the operation configuration shown and described in FIG. Figure 5A 565. Specifically, the listed routing rule 570 includes its name (allow https) 530, source application domain (web application) 535, destination application domain (App2) 540, type of action taken (allow) 545, protocol type applicable to the rule (TCP) 550, and port associated with the routing rule (port number 443) 555. In addition, a first indication 560 identifies the implementation state of the routing rule 570 (off - disabled), and a second indication 565 identifies the logging state of the routing rule (on - enabled).

[0086] refer to Fig. 6A , showing an exemplary embodiment of a first interactive display area 600, which is generated and displayed to show the Figures 4A-4D610. Here, when the first application domain 610 (web application) is selected, a first interactive display area 600 is generated. The first interactive display area 600 lists tags 622 associated with one or more resources (e.g., resource 620) included in the first application domain 610, together with characteristics 625 associated with the resource 620. Examples of characteristics 625 include, but are not limited to, or constrained to a name 626, a type 627 (identified as a VM instance), a cloud service provider (CSP) 628, and a region 629 where the resource 620 is located.

[0087] Similarly, if Figure 6B As shown, when the second application domain 640 (App 2) is selected, a second interactive display area 650 is generated, which lists (i) tags 660 associated with resources 661-663 of the second application domain together with characteristics 665 of these resources 661-663. Examples of characteristics 665 include, but are not limited to, or constrained to, a name 666, a type 667 (identified as a VM instance), a cloud service provider (CSP) 668, and a region 629 where the corresponding resource 661, 662, or 663 is located.

[0088] like Figure 6C As shown, an exemplary embodiment of a third interactive display area 670 is shown, which shows a routing rule 680 that controls the operability of the first and second application domains 610 and 640, wherein the routing rule 680 is based on Figure 5A-5B Here, when routing rule 680 is selected, a third interactive display area 670 is generated, which shows the routing rule 680 that can be modified (see Figure 5A ) associated with the input field. For example, the routing rule 680 can be changed by adjusting the first toggle switch 685 associated with the implementation of the routing rule 680 from a disabled (off) state to an enabled (on) state. Similarly, the routing rule 680 can be changed by adjusting the second toggle switch 690 to change its record operability. In addition, the routing rule 680 can be renamed, or different protocols or ports can be identified, as well as whether the action of the rule allows or does not allow certain operability.

[0089] V. Micro-segment layout Reference now Figure 7 , showing Figure 6A-6BAn exemplary embodiment of the layout of the first application domain 610 and the second application domain 640 is shown. Here, the first application domain 610 includes resources 620 constituting a first VM instance located within the first public cloud network 110. The second application domain 640 includes three resources, namely resources 661-663, wherein the first and second resources 661 and 662 constitute a VM instance located within the first public cloud network 110. The third resource constitutes a VM instance located within the second public cloud network 115.

[0090] Without departing from the spirit of the present disclosure, the embodiments of the present invention may be implemented in other specific forms.The described embodiments are to be considered in all respects only as illustrative and not restrictive.

Claims

1. A controller, comprising: processor; as well as A non-transitory storage medium communicatively coupled to a processor, the non-transitory storage medium comprising (i) classification logic that determines a virtual zone in which a newly discovered endpoint resides based on recovery information associated with the newly discovered endpoint, and (ii) rule generation logic configured to (a) generate a first subset of rules for controlling message flow between a destination and a source via a native cloud fabric associated with a cloud service provider (CSP) underlying network when the destination and the source reside within a first virtual zone, and (b) generate a second subset of rules for controlling message flow between the destination and the source via an overlay network that provides communication between the first virtual zone and the second virtual zone when the destination and the source reside within different virtual zones, and to set and manage security policies using micro-segmentation.

2. The controller according to claim 1, wherein: The first virtual region corresponds to a first virtual private cloud network (VPC), and the second virtual region corresponds to a second VPC. 3 . The controller of claim 2 , wherein the first VPC resides within a first public cloud network and the second VPC resides within a second public cloud network different from the first public cloud network.

4. The controller according to claim 2, wherein: The second set of rules includes filtering rules that establish one or more policies that affect propagation of inter-VPC network traffic on an overlay network that establishes a communication path between the first VPC and the second VPC. 5 . The controller of claim 4 , wherein the first set of rules includes filtering rules that establish one or more policies that affect propagation of intra-VPC network traffic over the underlying network.

6. The controller of claim 1, wherein the non-transitory storage medium further comprises endpoint discovery logic configured to identify newly added, modified, or deleted endpoints within one or more public cloud networks including the first virtual area and the second virtual area.

7. The controller according to claim 6, wherein: The restoration information associated with the newly discovered endpoint includes an identifier of the endpoint and an identifier of the virtual area.

8. The controller according to claim 7, wherein: The identifier of the virtual area includes a virtual private cloud network (VPC) identifier in which the newly discovered endpoint resides.

9. The controller of claim 8, wherein the non-transitory storage medium further comprises logic for creating and maintaining endpoint-to-VPC identifier mappings for determining whether security group orchestration is required to support intra-VPC communications between the source and the destination.

10. The controller according to claim 6, wherein: The non-transitory storage medium also includes security group generation logic configured to generate one or more network security groups, each network security group operating as a virtual firewall associated with the identified endpoint.

11. A method for controlling network traffic flow separation between inter-VPC communication and intra-VPC communication, comprising: Recovering information identifying newly added, modified, or deleted endpoints within one or more public cloud networks; determining, based on the recovery information associated with the newly discovered endpoint, a virtual area in which the newly discovered endpoint resides; generating a first subset of rules for controlling a message flow originating from or to the newly discovered endpoint via a native cloud fabric associated with a cloud service provider (CSP) underlying network when the newly discovered endpoint and another endpoint communicating with the newly discovered endpoint and operating as a destination and source of the message flow are located within a first virtual area; generating a second subset of rules for controlling a flow of messages from or to a newly discovered endpoint via an overlay network providing communication between the first virtual area and the second virtual area when the newly discovered endpoint and the other endpoint reside within different virtual areas; and Use micro-segmentation to set and manage security policies.

12. The method of claim 11, wherein the first virtual area corresponds to a first virtual private cloud network (VPC), and the second virtual area corresponds to a second VPC.

13. The method of claim 12, wherein the first VPC resides within a first public cloud network and the second VPC resides within a second public cloud network different from the first public cloud network.

14. The method according to claim 12, wherein: The second set of rules includes filtering rules that establish one or more policies that affect propagation of inter-VPC network traffic on the overlay network that establishes a communication path between the first VPC and the second VPC.

15. The method of claim 14, wherein the first set of rules includes filtering rules that establish one or more policies that affect propagation of intra-VPC network traffic over the underlying network.

16. The method according to claim 11, wherein: The restoration information associated with the newly discovered endpoint includes an identifier of the endpoint and an identifier of the first virtual area.

17. The method according to claim 11, further comprising: Create and maintain endpoint-to-VPC identifier mappings, which are used to determine whether security group orchestration is required to support intra-VPC communication between a newly discovered endpoint and another endpoint.

18. A non-transitory storage medium comprising logic that, when executed, controls flow separation of inter-VPC communications and intra-VPC communications, comprising: endpoint discovery logic configured to identify newly added, modified, or deleted endpoints within the plurality of public cloud networks; classification logic configured to determine a virtual zone in which the newly discovered endpoint resides based on the recovery information associated with the newly discovered endpoint; as well as Rule generation logic is configured to (i) generate a first subset of rules for controlling message flow between a destination and a source via a native cloud fabric associated with a cloud service provider (CSP) underlying network when the destination and the source reside within a first virtual zone, and (ii) generate a second subset of rules for controlling message flow between the destination and the source via an overlay network providing communication between the first virtual zone and the second virtual zone when the destination and the source reside within different virtual zones, and to set and manage security policies using micro-segmentation.

19. The non-transitory storage medium according to claim 18, wherein: The second subset of rules includes rules for controlling and filtering messages on the overlay network when the source resides in a first virtual zone included in the first public cloud network and the destination resides in a second virtual zone included in the second public cloud network, to be implemented by the native cloud fabric to propagate messages to perform intra-VPC network traffic control for messaging therebetween, and a second subset of rules to be implemented by one or more branch gateways to perform inter-VPC network traffic control.

20. The non-transitory storage medium of claim 18, wherein the non-transitory storage medium is communicatively coupled to the processor, the non-transitory storage medium comprising endpoint discovery logic, classification logic, security group generation logic, and rule generation logic.

Images