Hierarchical API for Defining Multi-Segmented Applications in SDDC

Abstract

Some embodiments provide a simplified mechanism for deploying and controlling multi-segment applications by using application-based manifests, which represent how to define or modify the application segments of a multi-segment application and how communication forms a profile between these segments. In some embodiments, these manifests are application-specific. Additionally, in some embodiments, a deployment manager in a software-defined data center (SDDC) provides these manifests as templates to administrators, who can use these templates to express their intentions when deploying multi-segment applications in the data center. Application-based manifests can also be used to control previously deployed multi-segment applications in the SDDC. Using such manifests will enable administrators to manage fine-grained micro-segmentation rules based on endpoint and network attributes.

Description

Background Art

[0001] In an enterprise data center, a firewall has been crucial for the networking and security of applications running thereon. It starts with an access control list (ACL), which provides rules applied to host or other port numbers or IP addresses available at Layer 3, and each rule comes with a list of hosts and / or networks allowed to use the service. After the ACL, macro-segmentation emerged, which provides IP-based enforcement for each application running on a host. This gives enterprise administrators granular control to protect their workloads based on VLANs.

[0002] Leveraging network virtualization, micro-segmentation revolutionizes the networking and security landscape by providing the ability to enforce distributed firewall rules across hosts in a data center based on L4-L7 network services and attributes. There are some new firewalls with the ability to perform deep packet introspection in the transport layer and include web application filtering, verb-based firewalls, and URL filtering.

[0003] FIG. 1 illustrates the current workflow for specifying firewall controls for a micro-segmentation application. As shown, an administrator must first (at 105) define the intent regarding which application they want to protect. Based on this intent, the administrator must (at 110) create domains and groups to define the boundaries of each component of the application. Once the groups are created, the administrator then (at 115) defines how these components communicate with each other based on a communication profile.

[0004] After creating the profile and groups, the resulting policy is published (at 120) to a software-defined data center (SDDC) network manager 150. After publishing the policy, the administrator then must log in to the network manager for each instance of the data center controlled by the manager and create networking and security groups (at 125) based on the grouping criteria specified in creating the domains and groups. These criteria can be based on logical switch ports, tags, or VM / container names.

[0005] Then, the administrator must manually manage (at 130) the workload VMs / containers by applying the appropriate tags so that they match the criteria during the creation of the networking and security groups at 125. When the tags match the criteria, then the firewall rules defined in the communication profile are applied (at 135) to the corresponding VMs.

[0006] This method has several drawbacks. For example, the management of grouping criteria (such as labels, VM names, etc.) is manual and cumbersome. This is particularly problematic when this management must be repeated across multiple environments (such as development, staging, and production). In addition, the discovery and classification of applications are management overheads and are often error-prone. When the protected entities are inherently ephemeral, this method is also not scalable for dynamic workload (such as container) environments. Summary of the Invention

[0007] Some embodiments provide a simplified mechanism for deploying and controlling multi-section applications by using application-based manifests, where the application-based manifests represent how to define or modify the application sections of the multi-section application and how communication forms a profile between these sections. In some embodiments, these manifests are application-specific. In addition, in some embodiments, a deployment manager in a software-defined data center (SDDC) provides these manifests to administrators as templates that they can use to express their intentions when deploying multi-section applications in the data center. Application-based manifests can also be used to control previously deployed multi-section applications in the SDDC. Using such manifests will enable administrators to manage fine-grained micro-segmentation rules based on endpoint and network attributes.

[0008] A multi-section application refers to an application that includes multiple application sections. In some embodiments, each of the one or more application sections is an independent application executed in its own storage space (the storage space does not intersect with the storage space of any other application section of the multi-section application). In some embodiments, different application sections of the multi-section application are implemented by different machines (such as different VMs or containers).

[0009] In some embodiments, the application manifest includes a syntactic representation of the multi-section application, which can be defined after the manifest is implemented, or it can be defined earlier. In some embodiments, the application manifest is a hierarchical API that includes two or more commands for defining or modifying (1) one or more application sections and (2) one or more policies associated therewith. The application manifest is a hierarchical API because different commands can be nested under other commands. For example, the definition of a group of applications can include the definition of a specific machine (such as a specific VM) to implement a specific application in the group. In some embodiments, the application manifest is provided to administrators as a predefined template that encapsulates well-known applications and their dependencies, as well as the ability to model applications based on the requirements of the administrators.

[0010] In some embodiments, the manifest is defined in a declarative language. In some embodiments, the manifest processing framework in the SDDC parses the manifest into a number of commands that (1) instruct the compute manager in the SDDC to deploy and configure the application segments of the multi-segment application defined in the manifest, and (2) instruct the network manager in the SDDC to define and deploy network forwarding and service rules for implementing the communication profiles between the application segments specified by the manifest and between the application segments and other applications.

[0011] In some embodiments, the application segments are deployed in the SDDC as VMs or containers executing on a host computer and / or are deployed as stand-alone computers. Similarly, in some embodiments, the network forwarding and service rules are processed by software forwarding elements (e.g., software switches and routers) and software middlebox service VMs (e.g., service containers and / or service modules executing on a host computer in the SDDC). In some embodiments, these forwarding and / or service rules are also configured on hardware forwarding elements (e.g., top-of-rack switches), stand-alone hardware or software gateways, and / or stand-alone middlebox devices in the SDDC.

[0012] Some embodiments of the present invention provide a method for deploying a multi-segment application in an SDDC. The method initially receives a hierarchical API command that specifies a number of operation requests in a declarative format to define a number of application segments of the multi-segment application. The method parses the API command to identify the application segments. Based on the parsed API command, the method deploys a number of software-defined (SD) resources (required to deploy the number of application segments) and the forwarding and service operations between these segments.

[0013] The deployment process used by the method in some embodiments ensures that any first SD resource on which a second SD resource depends is deployed before the second SD resource. In some embodiments, the second SD resource depends on the first SD resource when the second SD resource is a child of the first SD resource. Alternatively or in combination, in some embodiments, the second SD resource may also depend on the first SD resource when the second SD resource has some operational dependency on the first SD resource.

[0014] In some embodiments, the method parses API commands by identifying a number of SD resource sets, each set having one or more SD resources at a resource level. In some embodiments, the identified SD resource sets are deployed at a higher resource level before the SD resources are deployed at a lower resource level. Examples of SD resources that can be specified in a hierarchical API command include SD computing elements (e.g., VMs or containers) for implementing application segmentation, SD forwarding elements (e.g., managed software switches and routers implemented by managed software switches and routers, logical switches and routers, etc.) for implementing forwarding rules for forwarding data messages associated with application segmentation, and SD service middlebox modules (e.g., service VMs or modules that perform middlebox service operations such as firewall operations, load balancing operations, network address translation operations, encryption operations, intrusion detection operations, intrusion prevention operations, etc.) for enforcing service rules for performing services on data messages associated with application segmentation.

[0015] In some embodiments, an API processing system processes API commands. The command can include a set of parameters to update previously deployed SD resources. In such a case, the API processing system deploys a multi-segment application by using the set of parameters specified in the parsed API command to update the SD resources previously deployed for the multi-segment application. In some such cases, the API command includes a set of parameters that define new SD resources. In such a case, the API processing system deploys the SD resources by deploying the SD resources based on the set of parameters specified in the parsed API command.

[0016] In some embodiments, a hierarchical API command is processed as an atomic unit. Thus, the API processing system determines whether the SD resources identified in the hierarchical API command are deployable. If so, the API processing system sends an acknowledgment that the API command has been successfully processed to the source that generated the hierarchical API command. On the other hand, when one or more of the SD resources in the API command are not deployable, the API processing system sends a message that the API command has not been successfully processed to the source that generated the hierarchical API command.

[0017] Some embodiments pave the way for the next generation of micro-segmentation by binding context from data compute endpoints to the network. The endpoint-based context can be related to user identity and application-specific attributes such as file hashes, publisher information, permissions, and process information. In some embodiments, the context information is used by application-based firewalls deployed in distributors equipped in the SDDC (e.g., via virtualized network devices). One of the biggest challenges in commoditizing application-based firewalls is the consumption model for such complex firewalls, as there may be thousands of processes running inside endpoints and millions of processes running in the data center. However, by using application manifests, some embodiments provide a new way to allow administrators to manage the very difficult task of creating fine-grained context-based rules and managing these rules.

[0018] The foregoing invention content is intended to serve as a brief introduction to some embodiments of the present invention. It is not an introduction or overview of all inventive subjects disclosed in this document. The following detailed description and the accompanying drawings referred to in the detailed description will further describe the embodiments described in the invention content as well as other embodiments. Therefore, to understand all the embodiments described in this document, a comprehensive review of the invention content, detailed description, drawings, and claims is required. Additionally, the claimed subject matter is not limited by the illustrative details set forth in the invention content, detailed description, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The novel features of the invention are set forth in the appended claims. However, for purposes of explanation, several embodiments of the invention are set forth in the following drawings.

[0020] FIG. 1 illustrates a current workflow for specifying firewall controls for micro-segmentation applications.

[0021] Figure 2 An inventory processing framework is shown that processes application inventories received from tenant administrators in the SDDC.

[0022] Figure 3 A process is presented that shows the operations of components of the inventory processing framework.

[0023] Figure 4 An example of an application inventory that defines a multi-segment application called Slack is shown.

[0024] Figure 5 An example of Slack is shown.

[0025] Figure 6 Shows Figure 5 the data model of the application shown in

[0026] Figure 7Shows a process representing an exemplary process for defining and deploying a multi-segment application based on a manifest template.

[0027] Figure 8 Shows the architecture of such a new classification engine for some embodiments.

[0028] Figure 9 Shows an example of an API processing system for some embodiments of the present invention.

[0029] Figure 10 Shows how some embodiments enforce context-based firewall rules on a host computer.

[0030] Figure 11 Shows an example of data collection for understanding the deployment of multi-segment applications in a data center.

[0031] Figure 12 Conceptually shows a computer system for implementing some embodiments of the present invention. Detailed Description

[0032] In the following detailed description of the present invention, many details, examples, and embodiments of the present invention are set forth and described. However, it will be clear and apparent to those skilled in the art that the present invention is not limited to the embodiments set forth, and that the present invention may be practiced without some of the specific details and examples discussed.

[0033] Some embodiments provide a novel application-based manifest that provides a simplified mechanism for deploying and controlling multi-segment applications and defining communication profiles between segments of a multi-segment application. A multi-segment application is an application that includes multiple application segments. In some embodiments, each application segment may be an independent application executing in its own storage space that does not intersect the storage space of any other application segment of the multi-segment application. In some embodiments, different application segments of a multi-segment application are implemented by different machines (e.g., different VMs or containers).

[0034] In some embodiments, a deployment manager in a software-defined data center (SDDC) provides these manifests as templates to administrators. When administrators deploy a multi-segment application in the data center, they can then use these templates to express their intentions. The application-based manifest can also be used to control previously deployed multi-segment applications in the SDDC. Using such a manifest will enable administrators to manage fine-grained micro-segmentation rules based on endpoint and network attributes.

[0035] In this document, a data message refers to a collection of bits sent across a network in a specific format. One of ordinary skill in the art will recognize that the term "data message" may be used herein to refer to various formatted collections of bits that can be sent across a network, such as Ethernet frames, IP packets, TCP segments, UDP datagrams, etc. Additionally, as used in this document, references to L2, L3, L4, and L7 layers (or layers 2, 3, 4, and 7) refer respectively to the second data link layer, third network layer, fourth transport layer, and seventh application layer of the OSI (Open Systems Interconnection) layer model.

[0036] Figure 2 Illustrated is a manifest processing framework 200 that processes application manifests received from a tenant administrator in an SDDC. Based on this processing, the framework 200 interacts with compute and network managers in the SDDC to deploy a multi-segment application and configure forwarding and service elements in the SDDC to establish desired communication rules between segments of the application and between these segments and other applications and devices inside and outside the SDDC. In some embodiments, the application manifest may also include requests for adjusting a previously deployed multi-segment application and / or a communication profile previously configured for a previously deployed segment.

[0037] As shown, the manifest framework includes a parser 205, a constraint checker 210, an orderer 220, a coordinator 230, and several rule and policy memories 215, 225, and 235. The operation of these components will be described with reference to Figure 3 the processes performed by these components on an application manifest. Figure 3 Illustrated is a process 300 performed by these components on an application manifest. As shown, the process 300 begins when the manifest processing framework 200 receives an application manifest (at 305) from an administrator's machine 260 (e.g., from a VM, container, or stand-alone computer used by the administrator to specify the application manifest). As described above and further below, in some embodiments, the administrator may use an application manifest template provided by the manifest framework to specify the manifest 255.

[0038] In some embodiments, the application manifest 255 includes a syntactic representation of a multi-segment application. In some embodiments, the application manifest is a hierarchical API that includes two or more commands that define or modify: (1) one or more application segments, and (2) one or more communication profiles between each application segment and another application segment or another application / machine inside or outside the SDDC.

[0039] The application manifest is a hierarchical API because different commands can be nested under other commands. For example, a domain definition can include an application segment group definition, which in turn can include one or more definitions of one or more machines (e.g., a specific VM or container) to implement application segmentation. In some embodiments, the manifest is defined in a declarative language. For example, in some embodiments, the manifest is written in the JavaScript Object Notation (JSON) format, but in other embodiments, it can be expressed in other hierarchical formats such as the XML (Extensible Markup Language) format.

[0040] After receiving the application manifest 255, the parser 205 of the framework 200 (at 310) identifies several different requests (commands) included in the manifest. For example, for a typical three-tier application, the manifest can specify the deployment of a web server, an application server, and a database server. In this case, the parser will parse the manifest into three sets of one or more commands, each set associated with the deployment of a tier (e.g., the deployment of a web server, an application server, or a database server). In some embodiments, the parser generates an input API tree from the manifest. The input API tree represents the parent-child relationships between different parts of the manifest.

[0041] After the parser breaks down the manifest into several individual requests, the constraint checker 210 (at 315) determines whether any of these individual requests violate the policy constraints stored in its constraint memory 215. If so, the framework will return an error to the administrator. Otherwise, the sorter 220 identifies (at 320) the order of execution for implementing these requests. To identify this order of execution, in some embodiments, the sorter constructs a type-specific mapping that identifies each SD resource identified in the manifest according to its type. For this purpose, in some embodiments, the sorter performs a breadth-first traversal of the input API tree constructed by the parser from the manifest, classifies the input into different buckets based on the resource type, and stores the classified input in the type-specific mapping.

[0042] Each key in the type-specific mapping is a resource type, and the value of each key is a list of all resources of a specific type in the input API tree. Each node element is stored together with its parent element. In summary, the input API tree is classified based on resource types, for example, all domains in one bucket, all groups in another bucket, and so on. After generating the type-specific mapping, the sorter defines the execution order for retaining SD resources in the input API tree. In some embodiments, the execution order is a predefined ordered list of resource types. This list controls the order in which resources in the input tree should be retained. If a new type is introduced into the system, the execution order is dynamically updated to include the order of the new element. For example, in some embodiments, a sample execution order would be (1) domains, (2) groups, and (3) communication mappings. This means that domains should be created first, then groups, and then communication mappings.

[0043] Next, the sorter uses the service provider registry to retain SD resources in the constructed API tree. The service provider registry is a mapping from resource types to callback handlers. Each type in the system has a registered callback handler. The responsibility of the callback handler is to retain the type it is registered for. As further described below, in some embodiments, the callback handler is implemented by a deployment plug-in. A deployment plug-in is a module inserted into the API processing system to handle the retention of changes made to received API requests and the deployment of the retained changes.

[0044] Once the sorter has identified the call order and called the callback handlers based on that order to retain deployment data in one or more configuration databases, the coordinator 230 (at 325) interacts with one or more network, compute, and / or service managers 240 to deploy the SD resources 250 based on the configuration data that has been retained in the configuration databases. In some embodiments, the coordinator 230 is implemented by a deployment plug-in that also implements the callback handler for retaining data in the configuration databases.

[0045] In addition, in some embodiments, the SDDC resource manager 240 uses one or more SDDC resource controllers 245 to deploy multi-segment applications and their associated communication profiles on the SDDC resources 250. Examples of such resources include host computers, VMs, containers, software and hardware forwarding elements, software and hardware middlebox service elements, and so on. The resource manager and controllers 240 and 245 include (1) a compute manager and controller for the application segments of the multi-segment applications defined in the deployment and configuration manifest, and (2) a network manager and controller for defining and deploying network forwarding and service rules for implementing the communication profiles for the application segments specified in the manifest.

[0046] In some embodiments, the application segments are deployed in the SDDC as VMs or containers executing on a host computer, and / or are deployed as stand-alone computers. Similarly, in some embodiments, network forwarding and service rules are handled by software forwarding elements (e.g., software switches and routers) and software middlebox service VMs, service containers, and / or service modules executing on the host computers in the SDDC. In some embodiments, these forwarding and / or service rules are also configured on hardware forwarding elements (e.g., top-of-rack switches) in the SDDC, stand-alone hardware or software gateways, and / or stand-alone middlebox devices.

[0047] Figure 4 An example of an application manifest defining a multi-segment application called Slack is shown. The application manifest in this example is a hierarchical API template 400 that can be used to define the actual application manifest to be sent to the manifest processing framework. Such a template provides a mechanism for specifying a common set of requests that are often called in sequence to deploy a multi-segment application. The template API allows an administrator to deploy the common set of requests without having to define a series of APIs from scratch.

[0048] To specify the actual multi-segment application manifest according to the manifest template 400, in some embodiments, the administrator only needs to modify a limited number of fields (referred to as placeholder fields) in a copy of the template that becomes the manifest. From this perspective, the template API is a collection of one or more requests (for one or more resources) with empty fields or placeholders. Examples of placeholder application names, application identifiers (App_IDs), process names, process hashes, user identifiers, or any other key-value pairs used in the multi-segment application template are shown. In some embodiments, the administrator can also modify other components of the copy of the template that becomes the actual manifest (e.g., add segments, add or delete communication rules, modify communication rule parameters, etc.).

[0049] In some embodiments, the API template is a managed resource. It consists of a list of placeholders and is represented as the body of an API object. Figure 4 The API template 400 is used to deploy the Slack application. Figure 5 An exemplary deployment of the Slack application 500 is shown. The application has Figure 6 the data model illustrated in. Both the application 500 and the data model 600 will be further described below to further describe the parts of the application manifest 400.

[0050] The Application Inventory 400 is a hierarchical JSON format equivalent to a tree format. Each node of the tree corresponds to an SDDC resource and has a field that describes the resource type of that node. Each node has the special property of holding all the children of the node that describe the parent-child relationship. The child nodes can in turn have multiple children, and this can go to any depth. Thus, each node can be both a parent and a child (similar to a non-leaf node in a tree).

[0051] In Figure 4 , each node has a property "resource_type" (resource type) that describes the type of the node. In some embodiments, example types include Infra (Infrastructure), Tenant, Domain, Group, CommunicationMap, CommunicationEntry, etc. These are all the different types of resources in a data center. A node can also have a property "Children" that holds all the children of the node. For example, in Figure 4 , the node of type Domain410 is a child of the node of type Infra405 and has eight child nodes 415 - 450 of two different types (namely "Group" and "CommunicationMap"). In some embodiments, Tenant refers to a tenant in a multi-tenant SDDC, Domain is the workload under a tenant, CommunicationMap is a security policy, and CommunicationEntry is a rule under a security policy.

[0052] In some embodiments, each SD resource can be identified by a unique path starting from the root, where all the classification parent nodes are included in the path. For example, / vmware specifies all the resources associated with the tenant VMware. The path / vmware / domains / Outlook specifies all the Outlook workloads of the tenant VMware. The path / vmware / domains / Outlook / communication-maps / web-profile specifies the web-profile of the Outlook workloads of the tenant VMware. The path / vmware / domains / Outlook / communicationmaps / web-profile / communication-entries / open-browser-access specifies the open browser access permission for the Outlook workloads of the tenant VMware. More generally, the format of a security policy path can be specified as: / <tenant-name> / domains / <workload-name> / communication-maps / <security-policy-name> / communication-entries / <rule-name>。

[0053] As Figure 4 shown, the inventory template 400 includes a template header 401 that provides the name 402 and description 403 of the template as well as a list of placeholders 404. The inventory template 400 also includes eleven requests 405 - 480. Request 405 is to create a construct called Infra. This construct has eight children defined by requests 405 - 450. Request 410 defines a Domain called slack_app.

[0054] Requests 415 - 445 define seven application segments of the slack_app multi - segment application. Figure 5 These seven segments are shown. As shown, these seven segments include slack sharing 515 (defined by request 415), slack base 520 (defined by request 420), slack call 525 (defined by request 425), slack edit 530 (defined by request 430), slack download 535 (defined by request 435), slack upload 540 (defined by request 440), and slack file transfer 545 (defined by request 445). Each request 415 - 445 for each segment specifies that the segment will be implemented by a VM tagged with a key set to be equal to the name (identifier) of the segment.

[0055] Figure 5 and Figure 6 shows the communication between these segments through slack base 520. Thus, request 450 defines the communication profile (i.e., communication mapping) between these segments according to six communication rules (i.e., communication entries) regarding the data message exchange between slack base 520 and each of the other segments 515 and 525 - 545. In some embodiments, these six communication rules are implemented by firewall rules in the data plane. Figure 5 It is also shown that in some embodiments, the communication rules (e.g., firewall rules) can be based on any number of different context attributes, such as appID, process name, etc.

[0056] As shown, each communication entry is represented according to the source of the data message (e.g., source group), the destination of the data message (e.g., destination group), the action specifying whether the communication is allowed or denied, and the set of services, ports, and / or protocols used by the data message. The communication mapping also defines a rule 480 (i.e., communication entry) that specifies how slack base can communicate with the active directory service 590, as Figure 5 As shown. In some embodiments, these communication entries 455-480 are converted by the inventory processing framework into firewall rules for controlling communication between different segments of Slack and between these segments and other machines (inside or outside the SDDC).

[0057] In some embodiments, templates can be managed via GET, PATCH, DELETE, and POST commands. For example, in some embodiments, GET / policy / templates returns a list of template identifiers in the database. In some embodiments, GET / policy / templates / <template-id>Returns the template for a specific template identifier. Additionally, in some embodiments, PATCH / policy / templates followed by a template JSON definition creates a new template. In some embodiments, given a specific template identifier, DELETE / policy / templates / <template-id>Delete template.

[0058] In some embodiments, POST / policy / templates / <template-id>?action=deploy is specified to define and invoke hierarchical APIs based on the template API. Given a specific template identifier <template-id>, this command deploys a template. Arguments providing values for placeholders in the template are passed in the body of the POST request. In some embodiments, in response to the POST command and the placeholder arguments, the template manager of the inventory processing framework retrieves the identified template, applies the arguments representing the placeholder values to define a hierarchical API, and then creates one or more request objects to identify each requested operation in the hierarchical API. Such a template manager will be described further below.

[0059] In summary, the inventory template 400 specifies a set of processes defining a multi-segment application and a set of recommended communication profiles. An administrator can modify these definitions based on the administrator's requirements. In other words, the administrator has the option to use this functionality verbatim in the environment or modify it as needed in their data center. Such an example application inventory for Slack can be published as a standard in the industry for easier deployment and micro-segmentation of the application.

[0060] Figure 7 Process 700 is shown which represents an exemplary flow for defining and deploying a multi-segment application based on an inventory template. As shown, process 700 initially (at 705) provides a list of application inventory templates. In some embodiments, the inventory templates are templates for the most commonly used multi-segment applications. In some embodiments, the inventory templates are open source and community-driven, resulting in more exposure and accuracy for these applications.

[0061] Next, at 710, the administrator selects an inventory template from the provided list of inventory templates. The selected template is for the multi-segment application that the administrator wants to deploy. At 715, the administrator validates the inventory based on his intent. The selected inventory shows the compute, network, and security intent using the default configuration defined by the template publisher. The administrator can choose to accept the default configuration or modify it to match the desired intent.

[0062] At 720, the administrator submits the inventory to the inventory processing framework for processing and deployment. Once the inventory is published to the framework, the framework deploys the compute, network, and / or service resources specified in the inventory (at 725). After 725, process 700 ends.

[0063] In some embodiments, the framework uses a new classification engine which is an in-line service that collects different types of context attributes from the deployment environment (such as those used by existing or new workloads) so that the administrator can use these attributes when defining communication entries in the inventory. Figure 8 The architecture of such a new classification engine for some embodiments is shown.

[0064] Applications running on VMs are not inherently ephemeral. Once an administrator installs an application, these applications typically run for long periods of time. This is generally true for both VMs and bare-metal servers. In some embodiments, a context engine running on a hypervisor executing on a host computer periodically sends a list of processes running on its guest VMs to the SDDC management plane. An application discovery engine 805 receives this information and provides visualization of application information and the associated virtual machines.

[0065] In some embodiments, this information is not polled continuously and the process is not automated. Thus, in some embodiments, the new classification vertical on the management plane performs periodic synchronization operations internally to detect the list of processes running / installed on VMs and tag them based on the process information. An inventory vertical 810 obtains a list of VMs in the system and internally creates security groups and enables application discovery for these VMs. Once the list of applications / processes running on a VM is identified, the VM is tagged with that process. A grouping / tagging manager 815 collects security groups and other tagging data for the classification engine 800, while a firewall manager 820 collects context data from and for the deployed firewalls. Based on the collected tags, the intent from policies created at the application level determines the security groups and communication profiles for these processes.

[0066] Figure 9 An example of an API processing system 900 of some embodiments of the present invention is shown. The API processing system 900 implements the inventory processing framework 200 of some embodiments. In this system, each tenant can create an SDDC cluster 902 that includes one or more SDDC instances 905, and these SDDC instances 905 can be considered separate environments. As shown, in some embodiments, each SDDC instance 905 includes an API gateway 920, an API processor 925, a compute manager 910, a network manager 915, a controller 940, a template manager 927, a policy checker 923, a configuration data store 935, and a number of deployment plugins 930.

[0067] In some embodiments, two or more of these components execute on two or more machines (e.g., VMs, containers, stand-alone servers, etc.) in one or more data centers and communicate with each other over a network. In these or other embodiments, each SDDC instance includes multiple instances of each of these components for load distribution and high availability.

[0068] The Compute Manager 910 deploys and manages workload machines (e.g., workload VMs or containers). On the other hand, the Network Manager 915 deploys network resources (e.g., software switches and routers) and middlebox service resources (e.g., service VMs and modules) in the data center. In some embodiments, the Compute and Network Managers 910 and 915 use one or more Controllers 940 to distribute configuration data stored in one or more Configuration Data Stores 935 to the host machines, forwarding elements (e.g., software switches and routers executing on the host machines, or stand-alone switches and routers), service machines (e.g., service VMs, service containers, other service modules, and stand-alone service devices), and other resources in the SDDC.

[0069] The API Gateway 920 redirects all API commands to the API Service Module 925 based on the URL pattern, or in some cases to the UI Manager 922. The UI Manager 922 processes API commands received through the graphical user interface and directs these commands to the API Processor 925. The API Processor 925 executes Figure 2 and Figure 3 the processes shown in to ensure that different requests that are part of the received application manifest are persisted to the (one or more) Configuration Data Stores 935 and deployed in the correct order. The API Processor 925 has the desired state of the user stored in its data memory 932. In some embodiments, the API Processor 925 runs as a VM or a container.

[0070] As shown, in some embodiments, the API Processor 925 uses a Template Manager 927 that can access a number of manifest templates 929 that specify the multi-segment application configuration of the SDDC resources. Through the Template Manager 927, the user can select and modify the templates (e.g., via API commands) to produce a complete manifest. Based on this complete manifest, the API Processor 925 can then deploy or update a previously deployed set of SDDC resources to deploy or adjust a previously deployed multi-segment application.

[0071] To deploy resources or update previously deployed resources, based on the requests in the received manifest or the requests in the manifest completed by invoking the manifest templates with the required inputs, in some embodiments, the API Processor 925 parses the manifest into one or more requests and uses a Policy Check Engine 923 to validate each request (i.e., specify whether each request meets the constraints specified in the policies stored in the Policy Store 924 and applicable to the resources involved in the request).

[0072] In some embodiments, each policy in the policy storage device 924 includes (1) a target that specifies a set of one or more data center resources to which the application policy applies, and (2) an expression that specifies constraints on operations on the specified set of resources. In some embodiments, the policies are represented in a declarative format. Thus, for each request in the inventory, the policy engine compares the set of attributes of the resources of the selected request with the target of the policy to determine whether the policy applies to the resources. After identifying an applicable policy, the policy check engine determines whether the expression of the identified policy specifies constraints that require the selected request to be rejected or allowed.

[0073] By deploying the plug-in 930, the API processor 925 stores the SD resource data in the API call in the configuration database 935. In some embodiments, the deployment plug-in 930 runs as a VM or a container. Each plug-in 930 is responsible for deploying one or more SD resource types. Examples of such types include data computing nodes (e.g., computing machines such as VMs or containers), distributed firewall rules, edge firewall rules, L2 and L3 forwarding elements (software switches and routers), security groups, VPN services, DHCP services, DNS services, load balancing services, etc.

[0074] To deploy these services, the plug-in 930 interacts with the compute manager 910 and the network manager 915, which in turn interact with one or more controllers 940. Through these managers and controllers, the plug-in 930 distributes the configuration data from the persistent database 935 to the host computers and stand-alone network / service devices in the SDDC to direct these computers and devices to deploy the desired SD resources.

[0075] In some embodiments, each SDDC instance has a desired state and a coordination service (i.e., the API processing module). This is a highly available service deployed in the form of a container or a VM in some embodiments. The service accepts the user's intent and performs coordination across different services. The service also has details of the enforcement points (compute and network managers) where policies need to be pushed down.

[0076] The deployment plugin 930 provides the implementation of the intent. As described above, in some embodiments, each of these plugins is deployed as a separate service running in a separate container or VM. In some embodiments, some services are packaged together in a single container but run as separate services in terms of design and communication. Since the coordination is performed by the desired state service, in some embodiments, each plugin service exposes a set of REST API endpoints that will be called. Additionally, in some embodiments, the desired state service acts as a common service that returns the state of the implemented resources across different services. This is the case even in some embodiments where the implemented state data is updated by the plugin service in the data store.

[0077] Thus, the execution of the manifest results in the creation of the desired state in one go. If the system is able to validate and persist the entire intent, a notification is sent to the source of the manifest (e.g., return http status code 200 OK). After the intent is created, a notification is generated. These notifications are consumed asynchronously by the deployment plugin. Then, the deployment plugin is responsible for implementing the intent. The implemented state can be queried from the system using the status API.

[0078] In some embodiments, the API processing system 900 provides the user with the ability to query intents in a hierarchical manner. For example, in some embodiments, the system provides a GET API that facilitates reading the entire intent in one go. A special flag is passed in the URL parameter to request the GET in a hierarchical manner. When this parameter is not passed, in some embodiments, the GET will work as a normal GET and return a single resource. In some embodiments, the hierarchical GET can work on the entire tree or a part of the tree, i.e., it can specify the node from which to retrieve the hierarchical structure since the hierarchical GET can work from any level within the tree.

[0079] In some embodiments, another aspect of the hierarchical GET is filtering. In these embodiments, an administrator can filter out the intent tree to only see the types she is interested in. This filtering can be a simple type-based filtering. For example, the administrator can say GET the intent hierarchical structure for the type "Domain". In an advanced filtering mechanism, the user can choose to retrieve intents based on functionality. For example, the administrator can say GET all the resources in the intent hierarchical structure related to the firewall functionality.

[0080] In some embodiments, a user can perform a hierarchical GET and integrate it with a hierarchical POST. In some embodiments, an administrator can retrieve the intent hierarchical structure, then modify it and POST it back. This will enable the "import / export" use case. In some embodiments, an administrator can also retrieve and store the manifest. Subsequently, the administrator can restore the previously retrieved intent.

[0081] Figure 10 Illustrates how some embodiments enforce context - based firewall rules on a host computer. In some embodiments, the SDDC achieves its desired segmented communication profile by defining and enforcing such context - based rules on the host computer. As described above, the manifest processing framework transforms the communication profile rules defined in the manifest, which are transformed into rules that the network management layer (i.e., the network manager cluster) can process to achieve the micro - segmentation required by the application.

[0082] Figure 10 Illustrates that the network management cluster receives a set of rules through the use of a packet provider, which maps the application segments defined in the manifest to security groups based on the process name / hash. The network management cluster also receives the transformed firewall rules that match these process - based groups based on the communication profile defined in the manifest. Once the process - based groups and firewall rules are created, the firewall manager 1010 of the manager cluster 1005 distributes the rules to the host computers and other enforcement nodes in the SDDC.

[0083] To map files, modules, and other process data to network events, some embodiments use context data captured by a guest introspection (GI) agent 1020 executing on machines 1015 (e.g., host VMs and containers). In some embodiments, the GI agent 1020 captures any guest network connections and file accesses and their associated process context. In some embodiments, all network connections and file accesses are intercepted by the agent and sent to a context service engine 1030 running on the host. In the ESX hypervisor provided by VMware, Inc., the context data is sent to the context engine 1030 through a hypervisor component called Mux 1025, which acts as a pipeline to send network and file events from the GI agent to the context engine executing on the host computer. Using this information, the context engine updates the context table 1035, which contains information about the user, source IP address, source port, protocol, and process information initiated by the guest VM.

[0084] When the data computing machine 1015 subsequently makes a network connection, the firewall module 1040 executing on the host computer examines the outgoing packets, associates the process information with the packet flows from the context table, and matches it against the rules in the firewall table, thereby enforcing effective firewall rules at the process level. This level of fine-grained control over the processes running on the VMs helps the administrator detect unapproved software / applications installed in the environment and further block malicious processes running in the system. The effective rule implementation is transmitted back to the network management cluster, which provides the administrator with the status of the deployed applications and the effective rules. Context-based firewalls and other middlebox service engines are further described in U.S. Patent Application 15 / 650,251, published as 2018-0181423 and incorporated herein by reference.

[0085] In some embodiments, the manifest processing framework has an intent-based learning engine. Using the GI agent installed on the guest machine (e.g., guest VM or container), the manifest processing framework can not only identify the processes involved in the detected network activities, but also identify the installed binaries and the file attributes associated with these activities. Some of the most common attributes include file hashes, publisher information, installation paths, and certificates. In some embodiments, these identified processes and other attributes are collected from the deployment environment (e.g., from the host computer) and analyzed by the learning engine to generate new multi-segment application templates. The collected and analyzed data shows how some administrators typically deploy multi-segment applications (e.g., new multi-segment applications). In some embodiments, the learning engine discerns common deployment attributes from the collected data and recommends new multi-segment manifest templates based on its analysis.

[0086] As described above, the network and file events captured by the GI agent are stored in the context table. From here, the manifest processing framework can collect data about these captured events, as Figure 11 shown. In some embodiments, this data is collected in a separate server cluster or collection of devices because the data can become very large depending on the collection time and application workload. This information is stored at the host level for all processes seen on each VM in the host.

[0087] In some embodiments, the collected network and file event data is then aggregated and modeled to generate application templates customized to obtain the correct segmentation at the process level within the VM. For each network event, the GI agent can obtain the corresponding process, socket, connection rate, and connection type. In some embodiments, the framework has communication channels established to query the libraries used by the process and the files accessed by the process in that context.

[0088] In some embodiments, in addition to round-trip time, time of day, and correlation with other processes, this data is also used to train unsupervised or semi-supervised machine learning models. Some embodiments use a one-class support vector machine (SVM) classifier to identify process information. The SVM module is useful in scenarios where there is a large amount of "normal" data and not many anomalies to detect.

[0089] One-class SVM is an unsupervised algorithm that learns a decision function for novelty detection: classifying new data as similar or different from the training set. SVM is a supervised learning model that can be used for classification tasks. Typically, labeled data that can be mapped into n-d space is provided to the SVM. Different classes are separated by a distinct margin, and the SVM finds the widest possible margin. New data samples are classified based on which side of the margin they fall on. Some embodiments classify or process information based on the new data seen and recommend the correct set of application templates that an administrator needs to secure their network. Using this model, some embodiments are able to predict the running applications and their corresponding processes. In this way, the model can help identify new applications and recommend the correct application templates to secure the application.

[0090] The above embodiments provide several advantages. They provide an intent-based API processing system for deploying multi-segment applications through a hierarchical API data model that allows users to specify their intents (e.g., several application segments and their communication profiles) without worrying about the mechanisms for persisting and implementing these resources. In some embodiments, the intent-based API system allows users to define hierarchical API commands by using a simple declarative language that references a simplified hierarchical data model. Each hierarchical API command can define multiple SD resources at multiple resource levels in the SDDC, without requiring earlier API commands to create certain SD resources before other SD resources. In fact, in some embodiments, a single hierarchical command can be used to define all the SD resources of a user (e.g., a tenant) of the SDDC (e.g., a multi-tenant SDDC).

[0091] The manifest processing framework of some embodiments leverages the hierarchical structure of the data model to provide a process for accepting, validating, and implementing parts or all of the hierarchical structure in a single API call. The system leverages the inherent knowledge of the data model to identify dependencies and call underlying services in the correct order, both for the persistence and implementation of the intent. Additionally, all persistence is done in a single transaction, ensuring that the entire intent is accepted as an atomic unit.

[0092] Once the inventory processing framework determines that the multi-segment application defined in the received inventory is deployable, in some embodiments the API system uses an asynchronous process to automatically deploy resources in the correct order without further input from an administrator. This process works with one or more networks, services, or compute managers to deploy or update one or more network, service, or compute resources based on a work order suitable for the resources being deployed.

[0093] Many of the above features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause the (multiple) processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard disk drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or by wire.

[0094] In this specification, the term "software" means including firmware residing in read-only memory or an application stored in magnetic memory that can be read into memory for processing by a processor. Additionally, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while maintaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement the software inventions described herein are within the scope of the present invention. In some embodiments, when installed to operate on one or more electronic systems, a software program defines one or more specific machine implementations that execute and carry out the operations of the software program.

[0095] Figure 12 Conceptually illustrated is a computer system 1200 for implementing some embodiments of the present invention. The computer system 1200 can be used to implement any of the above-described hosts, controllers, and managers. Thus, it can be used to execute any of the above processes. The computer system includes various types of non-transitory machine-readable media and interfaces for various other types of machine-readable media. The computer system 1200 includes a bus 1205, (multiple) processing units 1210, a system memory 1225, a read-only memory 1230, a permanent storage device 1235, an input device 1240, and an output device 1245.

[0096] The bus 1205 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the computer system 1200. For example, the bus 1205 communicatively connects the (multiple) processing units 1210 with the read-only memory 1230, the system memory 1225, and the permanent storage device 1235.

[0097] (Multiple) processing units 1210 retrieve instructions to be executed and data to be processed from these different storage units in order to execute the processes of the present invention. In different embodiments, the (multiple) processing units may be a single processor or a multi-core processor. The read-only memory (ROM) 1230 stores static data and instructions required by the (multiple) processing units 1210 and other modules of the computer system. On the other hand, the permanent storage device 1235 is a read-write storage device. This device is a non-volatile storage unit that stores instructions and data even when the computer system 1200 is shut down. Some embodiments of the present invention use a mass storage device (such as a magnetic disk or an optical disk and its corresponding disk drive) as the permanent storage device 1235.

[0098] Other embodiments use a removable storage device (e.g., a floppy disk, a flash drive, etc.) as the permanent storage device. Similar to the permanent storage device 1235, the system memory 1225 is a read-write storage device. However, different from the storage device 1235, the system memory is a volatile read-write memory, such as a random access memory. The system memory stores some instructions and data that the processor needs during operation. In some embodiments, the processes of the present invention are stored in the system memory 1225, the permanent storage device 1235, and / or the read-only memory 1230. The (multiple) processing units 1210 retrieve instructions to be executed and data to be processed from these different storage units in order to execute the processes of some embodiments.

[0099] The bus 1205 is also connected to an input device 1240 and an output device 1245. The input device enables a user to transfer information to the computer system and select commands. The input device 1240 includes an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device 1245 displays images generated by the computer system. The output device includes a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some embodiments include a device such as a touch screen that serves as both an input and an output device.

[0100] Finally, as Figure 12 shown, the bus 1205 also couples the computer system 1200 to a network 1265 through a network adapter (not shown). In this way, the computer can be part of a computer network (such as a local area network (LAN), a wide area network (WAN), or an intranet) or a network of networks (such as the Internet). Any or all components of the computer system 1200 can be used in combination with the present invention.

[0101] Some embodiments include electronic components that store computer program instructions in a machine-readable or computer-readable medium (or referred to as a computer-readable storage medium, machine-readable medium, or machine-readable storage medium), such as a microprocessor, a storage device, and a memory. Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROMs), recordable compact discs (CD-Rs), rewritable compact discs (CD-RWs), read-only digital versatile discs (e.g., DVD-ROMs, dual-layer DVD-ROMs), various recordable / rewritable DVDs (e.g., DVD-RAMs, DVD-RWs, DVD+RWs, etc.), flash memories (e.g., SD cards, mini SD cards, micro SD cards, etc.), magnetic and / or solid-state disk drives, read-only and recordable discs, ultra-high density optical discs, any other optical or magnetic medium, and floppy disks. The computer-readable medium can store a computer program that can be executed by at least one processing unit and includes a set of instructions for performing various operations. Examples of computer programs or computer code include machine code such as that produced by a compiler, and files that include high-level code that is executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0102] Although the above discussion mainly relates to microprocessors or multi-core processors that execute software, some embodiments are executed by one or more integrated circuits such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuit itself.

[0103] As used in this specification, the terms "computer", "server", "processor", and "memory" all refer to electronic or other technical devices. These terms do not include a person or group of people. For the purposes of this specification, the term "display" refers to displaying on an electronic device. As used in this specification, the terms "computer-readable medium", "computer-readable media", and "machine-readable medium" are entirely limited to tangible, physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other transient or ephemeral signals.

[0104] Although the present invention has been described with reference to many specific details, those of ordinary skill in the art will recognize that the present invention can be implemented in other specific forms without departing from the spirit of the invention. Thus, those of ordinary skill in the art will understand that the present invention is not limited by the foregoing illustrative details, but rather is defined by the appended claims.

Claims

1. A method for deploying a multi - segmented application in a software - defined data center (SDDC), the method comprises: Receiving a hierarchical application programming interface command that specifies multiple segments of an application and defines multiple rules to control the forwarding of data messages between the segments of the application; Parsing the hierarchical application programming interface command into multiple requests, the multiple requests specifying a set of rules to be deployed and a set of application segments, each of the set of application segments and the set of rules including one or more fields that describe one or more resource types; Identifying an order of execution for implementing the multiple requests based on the one or more resource types in each of the set of application segments and the set of rules; and Based on the multiple requests obtained by parsing the hierarchical application programming interface command, deploying a set of machines in the SDDC to implement the set of application segments, and providing the set of rules to a set of network elements in the SDDC to control the forwarding of the data messages between the application segments.

2. The method according to claim 1, wherein the network element includes a managed forwarding element for forwarding data messages between the application segments and between other machines and the application segments.

3. The method according to claim 1, wherein the network element includes a middle - box service element for performing middle - box service operations on data messages sent to or from the application segments.

4. The method according to claim 3, wherein the middle - box service element includes a middle - box service machine executed on a host computer.

5. The method according to claim 3, wherein the middle - box service element includes a middle - box service filter executed on a host computer.

6. The method according to claim 3, wherein the service operations include at least one of a firewall operation, a load - balancing operation, a network address translation operation, an encryption operation, an intrusion detection operation, and an intrusion prevention operation.

7. The method according to claim 3, wherein the middle - box service element includes a firewall module or device.

8. The method according to claim 1, wherein the multi - segmented application has at least three application segments defined in the hierarchical application programming interface command.

9. The method according to claim 1, wherein the multi - segmented application has more than five application segments defined in the hierarchical application programming interface command.

10. The method according to claim 1, wherein the deployed set of machines includes virtual machines.

11. The method according to claim 1, wherein the deployed set of machines includes containers.

12. The method according to claim 1, wherein the application programming interface command includes a set of parameters for updating an earlier - deployed multi - segmented application, and deploying the set of machines includes updating the earlier - deployed multi - segmented application based on the set of parameters specified in the parsed application programming interface command.

13. The method according to claim 1, wherein the application programming interface command includes a set of parameters for updating an earlier - provided set of rules, and Providing the set of rules includes updating an earlier provided set of rules based on a set of parameters specified in the parsed application programming interface command.

14. The method according to claim 1, wherein at least one subset of the rules is related to a data message flow sent to the application segment from an application other than the multi-segment application.

15. The method according to claim 1, wherein at least one subset of the rules is related to a data message flow sent from the application segment to an application other than the multi-segment application.

16. A method for defining a multi-segment application in a software-defined data center (SDDC), the method comprises: Creating a hierarchical application programming interface command that specifies multiple segments of the application and defines multiple rules to control the forwarding of data messages between the segments of the application. The hierarchical application programming interface command contains multiple requests, which, when processed, deploy the application segments in the SDDC and deploy the multiple rules to control the forwarding of the data messages between the segments of the application. Each of the multiple segments of the application and the multiple rules includes one or more fields describing one or more resource types, wherein the order of execution for implementing the multiple requests is identified based on the one or more resource types in each of the multiple segments of the application and the multiple rules; Storing the hierarchical application programming interface command as a specific template in a plurality of customizable templates for defining multiple multi-segment applications; and Providing a graphical user interface or an application programming interface gateway to allow retrieval and customization of the specific template for defining a manifest that defines a set of segments of the multi-segment application and a set of rules for specifying communication between the segments of the multi-segment application, wherein when the manifest is subsequently processed by a computer, (i) multiple machines on a host computer in the SDDC are deployed to implement the set of segments of the multi-segment application and (ii) the set of rules is deployed to a set of network elements in the SDDC to control the forwarding of the data messages to and from the deployed machines, and the deployed machines execute the segments of the multi-segment application.

17. The method according to claim 16, wherein the network element includes a managed forwarding element for forwarding data messages between the application segments and between the application segments and an application other than the multi-segment application based on the deployed rules.

18. The method according to claim 16, wherein the network element includes a middlebox service element for performing middlebox service operations on data messages sent to or from the application segment based on the deployed rules.

19. The method according to claim 18, wherein the middlebox service element includes a middlebox service machine executed on a host computer.

20. The method according to claim 18, wherein the middlebox service element includes a middlebox service engine executed on a host computer.

21. The method according to claim 18, wherein the service operation includes one of a firewall operation, a load balancing operation, a network address translation operation, an encryption operation, an intrusion detection operation, and an intrusion prevention operation.

22. The method according to claim 18, wherein the middlebox service element includes a firewall machine or device.

23. The method according to claim 16, wherein the multi-segment application has more than three application segments defined in the hierarchical application programming interface command.

24. The method according to claim 16, wherein the multi-segment application has more than five application segments defined in the hierarchical application programming interface command.

25. The method according to claim 16, wherein the plurality of deployed machines include virtual machines or containers.

26. A machine-readable medium storing a program, the program implementing the method according to any one of claims 1-25 when implemented by at least one processing unit.

27. A computing device, comprising: a set of processing units; and a machine-readable medium storing a program, the program implementing the method according to any one of claims 1-25 when implemented by at least one of the processing units.

28. A computing system comprising means for implementing the method according to any one of claims 1-25.

Images